[seqfan] Re: Program syntax and the OEIS

Harvey P. Dale hpd1 at nyu.edu
Fri Jun 24 21:41:39 CEST 2011


Al writes " I get the feeling Wolfram will always maintain backwards
compatibility."  This, unfortunately, is not always true.  For example,
what is now IntegerPartitions used to be Partitions.  Programs written
under the older version, using Partitions, will not run properly in the
new version.  The existence of such changes is no doubt what prompted
Wolfram to provide a Mathematica Version Advisory that pops up
automatically whenever an older-version program is loaded.

Harvey

-----Original Message-----
From: seqfan-bounces at list.seqfan.eu
[mailto:seqfan-bounces at list.seqfan.eu] On Behalf Of Alonso Del Arte
Sent: Friday, June 24, 2011 11:22 AM
To: Sequence Fanatics Discussion list
Subject: [seqfan] Re: Program syntax and the OEIS

With Mathematica, I think the only problem is people still using older
versions, I get the feeling Wolfram will always maintain backwards
compatibility.

For example, Zak Seidov's program for A099349 uses NextPrime, which
wasn't
introduced until Mathematica 6.0. I'm sure in Mathematica 10.0 NextPrime
will work as before, as well as older commands like PrimeQ and Range.
For
that sequence, a comment like (* Version 6.0+ *) might be sufficient.
Those
using 5.2 and earlier probably have already cobbled together their own
version of NextPrime.

Al

On Fri, Jun 24, 2011 at 1:05 AM, Charles Greathouse <
charles.greathouse at case.edu> wrote:

> The recent case of A006506 (where a correct program in Maple 5 no
> longer gave correct answers in Maple 6+) has made me think about ways
> to store information on programming language and version into the
> program, maple, and mathematica fields.  (One day, perhaps, simple
> conversion could be done between versions, but in the medium term this
> would at least alert people to the version tested so they could check
> compatibility.)
>
> But in the short term, before any attempt to add hidden markup or
> simply standardize notation, it might seem worthwhile to search code
> for particular snippets known to have changed in meaning.  It's hard
> in this case: the affected operator is "." , which is presumably
> rather common in other uses.
>
> I have recently come across what will be another example.  PARI/GP
> just released a new stable version 2.5.0, and along with this
> deprecated the operators & and | (which have been shorthand for the &&
> and || short-circuit operators).  They continue to work in 2.5 and
> 2.6, but probably the next version will drop support for them.
>
> Russ/David/Neil, is there a way to search for instances of these so
> they can be corrected?  Regular expression like
> /(^|\n)\(PARI\).*[^&]&[^&]/s
> and
> /(^|\n)\(PARI\).*[^|]\|[^|]/s
> would give reasonably accurate matches, but I have no way to run those
> (short of screen-scraping the entire OEIS!).
>
> Charles Greathouse
> Analyst/Programmer
> Case Western Reserve University
>
> _______________________________________________
>
> Seqfan Mailing list - http://list.seqfan.eu/
>

_______________________________________________

Seqfan Mailing list - http://list.seqfan.eu/



More information about the SeqFan mailing list