[seqfan] Re: Sequences with very large entries.

[Charles Greathouse]

The limitation on the number of terms in sequences was originally for
technical reasons, as Neil mentioned. But it's still a good idea to keep to
roughly this size for human reasons: it's a pain for the reader to scroll
through lots of terms. But this is intentionally a soft limit, because
there are times when it's worth the slight inconvenience to read through
more terms. For example, just recently I extended a sequence by one or two
lines (beyond the usual maximum) because previously the terms shown for the
sequence were identical to the natural numbers. I extended it until the
first difference to make the distinction clear.

The restriction on b-files isn't so important for human readers, since
b-files are more likely to be read by machines. But there's at least some
kind of argument to be made for limiting terms just for sanity's sake --
there are lots of easy sequences which grow very quickly, and storing and
transferring large files is a pain.

Charles Greathouse
Analyst/Programmer
Case Western Reserve University

On Sun, Sep 20, 2015 at 7:33 AM, Neil Sloane <njasloane at gmail.com> wrote:

> I don't think we need to put a hard limit on the size of numbers in
> b-files.
>
> In these days of "big data", I think we can be flexible.
>
> It may be that some of the display commands (such as "graph")
> will fail if the numbers get too large, but I don't think we should worry
> about that.
>
> This was due to restrictions on how large numbers the R language
> could handle, but hopefully that has changed
> in the ten or 15 years since we first wrote the "graph" program.
>
> I feel the same about the number of terms that are displayed in the DATA
> lines.
> The old limit of a couple of hundred characters was imposed because the
> data was stored on punched cards! I think we can be more flexible now.
>
> We probably do need a limit, but it should be a lot more than 260
> characters,
> and we should not be very strict about enforcing it.
>
> As for the limits on the size of b-files (or a-files), again
> we should be very flexible. I find that I very often need more terms
> than are in the b-files when I'm trying to understand a sequence.
>
> Best regards
> Neil
>
> Neil J. A. Sloane, President, OEIS Foundation.
> 11 South Adelaide Avenue, Highland Park, NJ 08904, USA.
> Also Visiting Scientist, Math. Dept., Rutgers University, Piscataway, NJ.
> Phone: 732 828 6098; home page: http://NeilSloane.com
> Email: njasloane at gmail.com
>
>
> On Sun, Sep 20, 2015 at 1:59 AM, Sidney Cadot <sidney at jigsaw.nl> wrote:
>
> > Hello,
> >
> > Page https://oeis.org/wiki/User:Charles_R_Greathouse_IV/Format gives a
> > strong recommendation that numbers in b-file content lines not exceed
> > 1000 digits.
> >
> > There are currently 344 sequences that do not meet this
> > recommendation; some by a very large margin. For example, these are
> > the sequences that contain single numbers in excess of 100,000 digits:
> >
> > A226050 max digits too large: 465250
> > A226051 max digits too large: 415167
> > A005588 max digits too large: 400663
> > A226052 max digits too large: 374645
> > A226053 max digits too large: 218798
> > A226049 max digits too large: 211068
> > A226058 max digits too large: 165234
> >
> > Would it be useful to have a hard limit for this?
> >
> > Regards Sidney
> >
> > _______________________________________________
> >
> > Seqfan Mailing list - http://list.seqfan.eu/
> >
>
> _______________________________________________
>
> Seqfan Mailing list - http://list.seqfan.eu/
>