[seqfan] Re: Offsets of cons sequences
Hagen von Eitzen
hagen at von-eitzen.de
Sun Aug 23 20:20:45 CEST 2009
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).
More information about the SeqFan