[seqfan] Re: Java implementations update
Sean A. Irvine
sairvin at gmail.com
Wed Jun 19 23:50:06 CEST 2019
Actually in the jOEIS we do have wrappers that achieve what you suggest.
In particular, there is a factory that is able to generate terms for any
sequence having an implementation and this is indeed how I usually runs the
For example, from an installation of the jOEIS, you can run
joeis A000045 | head
This works precisely because all the sequences implement exactly the same
interface. For sure, there is still room for improvement here. There
isn't yet a convenient way to generate b-files because most of the
implementations don't actually know what the correct offset is.
I would certainly welcome further efforts along the lines you suggest in
other languages. Each such effort is another chance at detecting and
correcting mistakes in the OEIS. Admittedly such efforts will never be
completely independent, for example the jOEIS is only able to have as many
implementations as it does because it has borrowed extensively from
existing programs in other languages and/or formulas in the entries.
On Thu, 20 Jun 2019 at 06:13, M. F. Hasler <oeis at hasler.fr> wrote:
> this jOEIS approach is certainly interesting, but I would like to propose a
> different approach aloready mentioned years ago here and on the wiki.
> As proof of concept, I make available an example OEIS_js web page at
> https://github.com/m-f-h/OEIS.js which you can download on your computer.
> This page looks exactly like any random page of OEIS.org search results,
> with two major differences:
> - it has two buttons: [EXTEND] in the DATA section and [PARI] in the
> PROGRAM section
> - the HTML source is 250 lines instead of 550 lines (and the main content
> is in less then 100 lines as opposed to about 400 lines in the original).
> The main feature are the [EXTEND] and [PARI] buttons, which can be clicked
> to add terms to the DATA section, resp. to add PARI/GP code in the PROG
> function is *completely independent* of the sequence and will work with NO
> CHANGE for any other sequence (for the moment "only" for the 30 000+ linear
> recurrent sequences -- but it is just a quick hack written in 1-2 hours).
> It fetches the signature of the recurrence from the LINKS section and uses
> this to extend the DATA or to produce the PARI code (using the minimal
> number of initial values from DATA).
> Obviously, extending the DATA term by term is just meant to show that it
> The main use would be to produce a b-file (or some more practical format,
> on request) of arbitrary (user-defined) size.
> I insist on the main characteristic (as opposed to the jOEIS approach)
> which is to have one single, *sequence-independent* function.
> Also, this improvement would greatly reduce server load and traffic. (The
> script works on the user's computer, and could be put as separate file on
> the server (as could/should the CSS) so it would be cached by the users'
> brower and make the HTML page even 100 more lines smaller.)
> See the REAME file on github for more information and possible extensions.
> I'd be glad if this could find interest by others to be developed.
> In particular, I remember that Charles knows how to add a script as
> extension to your browser, which would make it possible to use this extra
> functionality even without waiting for it to get officially added to the
> main OEIS -- but I hope this could be done sooner or later.
> Among many others, one major advantage would be to get rid of the many
> submissions of trivial PARI, MAGMA, Mmca, ... scripts, g.f.'s and
> recurrence formulas: these (the trivial ones!) could and should be produced
> on-the-fly, allowing to make improvements in one single place that would
> immediately have site-wide effect.
> The script could/should also make consistency checks w.r.t. existing
> FORMULAs etc. and in that way contribute to consolidation of the OEIS.
> A word to those who'd object that it's only useful for linear recurrences:
> that's the case for this proof-of-concept quick hack, but obviously it can
> be extended to many other classes, and actually there's an easy way to
> extend the functionality to theoretically /any/ sequence, namely, by adding
> JS (or other suitable) code in the PROG section, which the script could
> recognize and use.
> Last not least, I should also say that the goal is not to get rid of user
> contributions, but on the contrary, to be able to focus on *nontrivial*,
> interesting contributions, and to dedicate the required care and time to
> (This approach could also benefit from work already done in the jOEIS
> framework: code written for these implementations could help to extend
> functionality to "nontrivial" cases.)
> - Maximilian
> On Tue, Jun 18, 2019 at 6:00 PM Sean A. Irvine wrote:
> > Thanks to recent contributions by Georg Fischer, the collection of Java
> > programs for OEIS sequences (jOEIS) now has implementations for over
> > sequences, especially concentrated in A-numbers less than A024000. We
> > currently covering about 1/6 of all sequences.
> > The main aim of the project is to validate sequence data in the OEIS.
> > The entire project is available on github:
> > https://github.com/archmageirvine/joeis
> > To the extent possible, these implementations are regularly tested
> > the data lines in the corresponding sequences. Georg has done extensive
> > testing against b-files, leading to numerous corrections in the OEIS (and
> > to be fair, in the implementations as well).
> > Georg and I are looking for additional contributors of Java code or of
> > other algorithms which cover some number of sequences. The following
> > is those A-numbers below A024000 for which we do not currently have an
> > implementation:
> > Some of these are inherently hard, but in many cases it is lack of
> > information that prevents implementation. Many currently have no useful
> > program (or formula) in any language and are thus good candidates for
> > general improvement in the OEIS.
> Seqfan Mailing list - http://list.seqfan.eu/
More information about the SeqFan