[seqfan] Re: offsets of constants

Charles Greathouse charles.greathouse at case.edu
Fri Aug 21 22:57:56 CEST 2009

Good point.  It would be nice to have it work that way.  In a truly
ideal world we could even integrate scripts like
in the same way.

Not entirely unrelated: does the database cache the graphs, or are
those regenerated each time?

Charles Greathouse
Case Western Reserve University

On Fri, Aug 21, 2009 at 4:27 PM, Joseph S. Myers<jsm at polyomino.org.uk> wrote:
> 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
> _______________________________________________
> Seqfan Mailing list - http://list.seqfan.eu/

More information about the SeqFan mailing list