[seqfan] Re: Offsets of cons sequences

[Hagen von Eitzen]

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