[seqfan] Re: offsets of constants

[Joseph S. Myers]

My view regarding the b-file issue is not so much that the format is 
necessarily optimal in all cases, as that the database should store "the 
terms of a sequence" (a sequence of integers with an associated starting 
offset) and whether they are stored as %S %T %U %V %W %X lines, or in a 
b-file, or in some other format for constants, or in multiple formats, 
should be considered an implementation detail, and should be independent 
of the forms in which you can view and download the terms of that 
sequence, and of the operations available for editing the sequence (one of 
which should be changing the offset without changing the terms 
themselves).  Having additional formats in which you can upload and 
download constants seems a perfectly good idea to me if OEIS deals with 
the conversions required automatically.

-- 
Joseph S. Myers
jsm at polyomino.org.uk

On Fri, 21 Aug 2009, Charles Greathouse wrote:

> I'm not entirely sure that the b-file format is best for constants.
> First, it's hard to read (by computers as well as people).  Why are we
> converting to a format that's not easy to use?  Pretty much every
> program out there natively reads and writes to one or both of
> 123456789
> or
> 1234\
> 5678\
> 9
> 
> Second, it's space-inefficient: it takes 3n + A058183(n) bytes on
> *nix-based systems, and 4n + A058183(n) bytes on Windows, to store the
> digits through n.  Granted, that's only 67 kB per sequence (or 770 kB
> for constant important enough to merit 100,000 digits).
> 
> Of course if there are good reasons I'm missing, please bring them up.
>  Before someone mentions it, I don't think that
> http://www.research.att.com/~njas/sequences/table?a=796&fmt=5
> is particularly compelling.
> 
> But whatever is decided, I'd be happy to pitch in on the conversion
> effort.  Maybe someone can compile a list and split up the work so
> there's no duplication?
> 
> Charles Greathouse
> Analyst/Programmer
> Case Western Reserve University