#10358: New interface with OEIS
-------------------------------------+--------------------------------------
Reporter: was | Owner: tmonteil
Type: defect | Status: needs_review
Priority: critical | Milestone: sage-5.11
Component: combinatorics | Resolution:
Keywords: Cernay2012 days49 | Work issues:
Report Upstream: N/A | Reviewers:
Authors: Thierry Monteil | Merged in:
Dependencies: | Stopgaps:
-------------------------------------+--------------------------------------
Comment (by tmonteil):
Here is how i understand the mess. There are three different things
related to OEIS in Sage.
- `sage/databases/sloane.py` (still) contains a class `SloaneEncyclopedia`
that
corresponds to a local partial copy of the OEIS. It is really a
database.
This file used to contain a function `sloane_find()` as well that, given
a
sequence, looked on the web and answered the name, the title, and the
first
terms of the OEIS sequences containing it.
- `sage/databases/oeis.py` (which is created by this patch) contains two
classes,
- `OEIS`, that represents the on-line database, so that you can ask it
questions
like
- give me the sequence whose ID is 'A000040'
- give me 5 sequences whose description deal with "decimals".
- give me 3 sequences that contain `[2,3,5,7]` as a subsequence.
- (todo) : give me the explanation of the keyword 'cofr'
- ...
- `OEISSequence` that represents a sequence, so that you can ask it
questions like
- what is your name ?
- what are your first terms ?
- are you finite ?
- do you have some references, links,... ?
- what is your starting index ?
- which natural Sage object do you represent (continued fraction,
decimal
number, sequence, power series,...) ?
- ...
- `sage/combinat/sloane_functions.py` contains a generic class
`SloaneSequence`,
and a class (that inherits from the generic one) for each implementation
of a
given OEIS sequence. Such a class allows to dynamically give more terms
than
the one stored in OEIS. This functionality could perhaps be redesigned
in
something lighter (like a dictionary of functions), to ease adding new
entries).
Of course `OEIS` and `sloane_find()` are related, which is why i posted
the patch
on this ticket. But, the answers are not of the same type (direct
informations
versus an OEIS sequences that you can ask for informations), hence if i
name
the class `OEIS` as `sloane_find`, old code using `sloane_find()` won't
work either,
hence the deprecation warning instead. Also it would have been harder to
extend the `function sloane_find()`, where it will be easy for the classes
`OEIS`/`OEISSequence`.
Actually, i do not know whether `oeis.py` should stay in the
`sage/databases/`
directory, since is it not an interface to a local database but a tool to
fetch an online website, like `finance/stock.py` and
`interfaces/magma_free.py`
Perhaps should i move it to `sage/combinat/` directory (where
`sloane_functions.py` is), or maybe we should move all three tools to a
`sage/combinat/oeis/` directory (but then `sloane.py` will not be in
`sage/databases/` anymore) ? The current choice is the laziest.
Of course those 3 tools related to OEIS should be interfaced together
(e.g. if
there are too many online queries, suggest the user to install the offline
database ; if there is a Sage implementation of some OEIS sequence, then
use
it when iterating over it once the first terms are exhausted ; and so on).
This is planned but, will take some more tests, and perhaps having 3
different tools for 3 different purposes is a good start. Having the web,
the DB and the
functions interfaced will also allow to be more lazy (e.g an OEIS sequence
could be created with only its ID, without fetching the web as long as
there are local
answers, this could be easily done in the OEIS/OEISSequence framework).
I will change the deprecation messages, and description of broken
functions as you suggested.
Concerning the reference class:`sage.databases.oeis.OEIS`_, i already put
one in the general description of sloane.py (as a SEEALSO::). Should i
also put one in the deprecation warnings as well ?
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/10358#comment:24>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sage-trac.
For more options, visit https://groups.google.com/groups/opt_out.
