[seqfan] Re: Changes to b-files and the rules

[jonscho at hiwaay.net]

Neil,

Thanks for sharing your thoughts on this.  A few comments:


<<  5) In the rules for b-file formats (see  
http://oeis.org/SubmitB.html) it is recommended to use " # " as a  
marker for lines with non-numerical data. This relies on the notion  
that all programs/uses of the b-file have " # " as a comment marker.  
This is generally not the case. This can be seen by the various ways  
to comment in the program sections.  >>

I see source code files and data files as two very different things.   
I might program in say, Magma, which has its own way of representing a  
comment in source code, but that doesn't mean that I expect data files  
to use that same way of representing comment lines.  Maybe I'm missing  
or not understanding something here.


<< 6) Head information in a submitted file can be avoided if the  
general policy of "If a b-file can be made then the code used can be  
added". This applies to any case where a b-file of a good length is  
added. >>

Perhaps my situation is unusual, but I've sometimes submitted b-files  
that were not neatly generated using a single program, nor even using  
multiple programs written in a single language.  E.g., for a  
particular sequence, it might be that the terms a(n) where n is twice  
a prime tend to be numbers that are 50 or 100 or more digits long but  
are easily calculated using something like Magma to test large numbers  
for primality, while some other terms might be less than 2^96 and  
might be easier to compute using a program I could write in Excel/VBA  
and leave running overnight (or over several nights).  There've been  
b-files I've submitted whose terms I would not be able to obtain using  
any single program that I'd be able to write in any one language and  
run in any one environment.


<<  " Several blank lines should appear after the last term." >>

I understand that a b-file that ends without a newline character or a  
carriage return / line feed pair can cause problems, but -- personally  
-- I really don't like to see a b-file with too many (e.g., several  
dozen) blank lines at the end.  Maybe I'm the only one who is bothered  
by such heavily-padded b-files, but whenever I open one of those (e.g,  
in a browser tab) and go to the end of the file (e.g., by hitting  
Ctrl+PageDown) and all I then see in my browser window is an empty  
page, I then sometimes briefly wonder whether something is wrong with  
the file, or wrong with my browser, and I have to begin scrolling up  
to find the last actual line of text in the b-file, and I find that  
inconvenient.


I don't know whether my comments above are useful or not.  If not, I  
apologize for the inbox clutter!

Best wishes,

-- Jon

Jon E. Schoenfield



Quoting neil greubel <jthomae at gmail.com>:

> Dear SeqFan members,
>
>  After some thought and a couple of discussions with fellow EICs
> (Editor in chief) I'd like to present some points of discussion for
> changes to b-files and their rules.
>
> 1) Core sequences should establish the way other sequences should be  
> presented.
> 2) More than 99% of the b-files encountered do not have information in
> the "head" section .
> 3) B-files should have appealing, and generally "nice", lengths. The
> most often seen lengths are 1000 terms, 2500 in some case when higher
> amount of terms is time consuming, 5000 and 10000 terms. Term lengths
> for triangles, for a typical triangle of anti-diagonal, follow the
> pattern binomial(n+1,2) for n rows. Not-so-nice term lengths may occur
> when the digit length nears 1000 decimal places sooner than a typical
> length of 1000 terms.
> 4) B-files with information in the head section are generally
> unappealing in terms of the Oeis.
> 5) In the rules for b-file formats (see http://oeis.org/SubmitB.html)
> it is recommended to use " # " as a marker for lines with
> non-numerical data. This relies on the notion that all programs/uses
> of the b-file have " # " as a comment marker. This is generally not
> the case. This can be seen by the various ways to comment in the
> program sections.
> 6) Head information in a submitted file can be avoided if the general
> policy of "If a b-file can be made then the code used can be added".
> This applies to any case where a b-file of a good length is added.
> 7) In most cases b-files of length 10000 terms are sufficient. Code is
> typically provided for these sequences and any user of Oeis can use
> those codes to produce any files necessary for their enjoyment. There
> have been select sequences that have had requests for larger b-file
> lengths. These requests are made by a bureaucrat and should remain so.
>
> With these select points I'd like to propose several changes be made
> to the way b-files are ruled and occasionally handled.
> 1) From bulletin 2 of  http://oeis.org/SubmitB.html which says "Lines
> beginning with # are comments lines and are ignored. Blank lines are
> also ignored. " should either be removed or reduced to " Several blank
> lines should appear after the last term."
> 2) From bulletin 9 " So that other people can verify your work, if
> possible please include the program that you used to compute the
> b-file. Put the program at the head of the b-file, with a # at the
> start of each line (so that these lines are ignored by the graph
> command).
>
> If your program is too long for this to be convenient, please include
> it as a separate text file attached to the sequence, with a name like
> a123456_Maple.txt or a234567_Py.txt. "
> should be changed to " Programs should be added in the program(s)
> sections which were used to compute, or verify, terms in the submitted
> b-file. If your program is too long for this to be convenient, please
> include it as a separate text file attached to the sequence, with a
> name like a123456_Maple.txt or a234567_Py.txt. "
>
> ( There are plenty of sequences in Oeis that have codes and not
> b-files. This can be seen more often when a new sequence is approved
> and not having a b-file added until some time later. )
>
> 3) A bulletin should be added which reads (or near to) " B-files of
> length larger than 10000 terms needs to be approved by and EIC unless
> otherwise directed by an EIC or
> bureaucrat.
>
>
> These changes to the rules will help keep and maintain good use and a
> nice appeal to b-files and their operations.
>
> --
> Seqfan Mailing list - http://list.seqfan.eu/