On 09/22/10 08:01 AM, Johan S. R. Nielsen wrote:
I think this is quite a good idea as a complement to the usual topical
documentation and for luring other math-software users in. The biggest
problem is maintenance, I guess: I don't exactly know how much
Mathematica, Maple etc. change in each vers
I think this is quite a good idea as a complement to the usual topical
documentation and for luring other math-software users in. The biggest
problem is maintenance, I guess: I don't exactly know how much
Mathematica, Maple etc. change in each version, but for the more
obscure functions, there will
> > How about "close analogue".
>
> No, I don't like that. If nothing else, it will be more confusing to those
> whose
> first language is not English, and even though mine is, I don't like that
> term.
Tom Boothby can "inventor" a word. I do like "analogues" though.
m-w.com: "1:something tha
On 09/21/10 09:49 PM, mda_ wrote:
On Sep 21, 10:39 am, "Dr. David Kirkby"
wrote:
On 09/21/10 06:12 PM, Niles wrote:
I'd just like to comment that, if the wording "nearest Mathematica
equivalent" is going to be an essential part of this, then it should
be very carefully chosen, and probably imp
On Sep 21, 10:39 am, "Dr. David Kirkby"
wrote:
> On 09/21/10 06:12 PM, Niles wrote:
>
> > I'd just like to comment that, if the wording "nearest Mathematica
> > equivalent" is going to be an essential part of this, then it should
> > be very carefully chosen, and probably implemented through some
On 09/21/10 06:12 PM, Niles wrote:
I'd just like to comment that, if the wording "nearest Mathematica
equivalent" is going to be an essential part of this, then it should
be very carefully chosen, and probably implemented through some
Maybe "nearest" is not appropriate. Perhaps "similar" or som
I'd just like to comment that, if the wording "nearest Mathematica
equivalent" is going to be an essential part of this, then it should
be very carefully chosen, and probably implemented through some
function, so that typos are avoided.
e.g.
def doc_equiv_command(sage_command, other_command, syst
Hello !!!
> If it was possible to put the equivalent commands in the docstrings, and
> then use some code to extract them in a logical way, it would be helpful.
>
> If it was done done in a very consistent way, then generating a list from
> grep and awk would be trivial:
I like very long bash lin
On 09/21/10 02:50 PM, Nathann Cohen wrote:
Hello !!!
Nathann and I started a few months ago to make such a list for graph theory:
I don't remember if we discussed it already Minh, but what about
putting all these informations INSIDE of the docstrings instead ? We
could then generate the list
> I don't remember if we discussed it already Minh, but what about
> putting all these informations INSIDE of the docstrings instead ? We
> could then generate the list of corespondances... It would be way
> easier to maintain, and users could find the Sage equivalents to the
> commands they know t
Hello !!!
> Nathann and I started a few months ago to make such a list for graph theory:
I don't remember if we discussed it already Minh, but what about
putting all these informations INSIDE of the docstrings instead ? We
could then generate the list of corespondances... It would be way
easier t
I think the greatest value of this would be that new users who are
used to other systems could find equivalent commands by searching for
what they already know. For example, a Mathematica user might search
for NDSolve and be led to ode_solver.
Perhaps we need a new official docstring title for th
12 matches
Mail list logo
