[seqfan] Re: Offsets of cons sequences

[Charles Greathouse]

I like the redundancy for ordinary b-files.  It's convenient to be
able to type "Ctrl+F 2 5 6 space" to find that there are 56092 groups
of order 256.  It's also good if you don't know the offset, or if
there are comments in the b-file (though I don't think there are, at
least at the moment). But I think it's rare enough to want to find,
say, the 7000th decimal digit of some constant.  It's not
automatically useful even for A098321-style sequences, because then
the number of digits you need is so large that you need a more
compressed format anyway...

Charles Greathouse
Analyst/Programmer
Case Western Reserve University

On Sun, Aug 23, 2009 at 2:20 PM, Hagen von Eitzen<hagen at von-eitzen.de> wrote:
> Richard Mathar schrieb:
>> cg> But whatever is decided, I'd be happy to pitch in on the conversion
>> cg> effort.  Maybe someone can compile a list and split up the work so
>> cg> there's no duplication?
>>
>> Once there is a defined format, one can essentially run a pair of
>>
>>  read("transforms3") ;
>>  L := BFILETOLIST("bxxxxx.txt") ;   # read file into a list
>>  LISTTOBFILE("bxxxx.txt",L,newoffsethere) ; # create file from list with offset
>>
>> in Maple for each file to be converted.  transforms3 is
>> the library in http://www.strw.leidenuniv.nl/~mathar/progs/transforms3 .
>>
>> Another point: the first column in each b-file (for constants and also for the
>> other sequences) is of course redundant, as long as these files contain
>> only consecutive values. To store that information is not needed if
>> the offset (a single number) is easily available. Each ASCII editor
>> has some sort of line enumeration capability. (vi users will use the "j"
>> or ":" to move to relative or absolute line numbers, for example. less -N
>> will enumerate lines by default. I suspect that even on Gate's systems such
>> a thing exists.) The current b-file format with explicit
>> tagging of each value makes only sense if "holes" are allowed, such as in
>> http://www.strw.leidenuniv.nl/~mathar/progs/b007504+.txt or
>> as in the recent tabulations of solutions to some modular equations.
>>
>
> Redundance is not bad per se.
> Even the trivial math involved in "I want to find a(1000) and this
> sequence has offset 17, so I should type '9 8 3 downarrow' in vi ..." is
> a small but existing source of error (in fact in writing this mail I had
> almost typed '982' ...), especially as it is necessary to combine
> information from different places (the b-file itself and the %O entry).
> A typical (esp. non-"cons") sequence grows fast enough to make the space
> wasted with those line numbers irrelevant.
> If saving bytes were really that important, the numbers should be
> gzipped or stored using binary digits with 8 bits per character instead
> of just  3.3 bits per character while at the same time rendering the
> data completely useless for human readers - *shudder*!
> I agree though that having both a gappy file (a-file) and a b-file that
> is simply the a-file up to the first gap is yet another source of
> redundance (and this time hardly a very useful one).
>
> Hagen
>
>
> _______________________________________________
>
> Seqfan Mailing list - http://list.seqfan.eu/
>