On Sun, Nov 30, 2014 at 8:14 PM, rjf <fate...@gmail.com> wrote:
>
>
> On Tuesday, November 18, 2014 1:35:21 PM UTC-8, William wrote:
>>
>> See this interesting document:
>>
>> http://www.maplesoft.com/products/maple/compare/
>> HowMapleComparestoMathematica.pdf
>>
>> Thanks for pointing it out. For a marketing document it is not too bad,
> but
> it is still a marketing document. Maybe that's what you want, but from a
> technical
> standpoint it has some issues.
>
Definitely a marketing document is what I want. That's why I explicitly
list "potential users" as part of the target audience.
>
>
>> It would be valuable to our users (and potential users) if we had a
>> similar document which explains and *argues* for why we believe our
>> approach to mathematical software is better than the ones taken by
>> Mathematica, Magma, Maple, and Matlab.
>>
>
> I think it would be totally confusing to present examples from all those
> programs
> and contrast them with Sage, and all the variants available in Sage.
>
That's easily solved -- e.g., have four versions, one for each Ma. A
prospective reader would only read one of them.
>
>
>
>> Some samples from their document: "About 95% of Maple's functionality
>> is written in the Maple programming language, and every Maple user
>> can freely inspect the source code for any of these predefined Maple
>> library routines. [...]
>
>
> This is true in principle, but the source code so displayed is generally
> not readable because it has been stripped of all comments and frankly
> is in a crummy language.
>
I didn't know they were stripped. Interested.
>
>
>> In Mathematica, the source code for all the
>> predefined library routines written in the Mathematica programming
>> language is hidden from the user." (*)
>>
>> When arguing for Maple's language over the Mathematica language, they
>> say "Functional programs are often opaque; most people, even
>> experienced programmers, find functional-style programs to be
>> significantly harder to write, read, and debug."
>>
>
> It would be interesting to learn how the (anonymous?) author came to
> hold this opinion. The obscurity of the Mathematica code in the example
> has rather little to do with it being in a functional mode, and more of
> it involving obscure function names and syntax. For example,
> where Lisp would define a function as
>
> (lambda(x)(+ x 1)
>
> Mathematica programmers COULD write it readably as
> Function[{x}, x+1]
>
> Or they COULD write,
> #+1&
>
> and that lends a certain je ne sais quoi to the so-called "functional"
> version.
>
:-)
> (defun hailstone (n) (cond ((= n 1) '(1)) ((evenp n) (cons n (hailstone
> (/ n 2)))) (t (cons n (hailstone (+ (* 3 n) 1))))))
> a minor change to this code would allow it to run without using arbitrary
> stack
> space (so-called tail recursion removal).
>
Lisp is so beautiful. (Seriously; no sarcasm)
>
>
>> (*) We had a specific situation a few years ago where an academic
>> wrote a package in maple, and a student at UW wanted to write a
>> similar open source package in Python. We specifically asked
>> Maplesoft if the student could look at the source code of Maple, which
>> is "open" in the sense they list above, then be inspired by it in
>> writing his own Python code. They came back and clearly said "no
>> way; absolutely not!"
>>
>
> I think that you could read your user license, but it looks sort of like
> you were asking if it was OK to use their code to reverse-engineer
> (part of) their system.
>
> I have in the past toyed with the idea of duplicating the functionality
> of the Maple kernel (by writing it in Lisp, naturally) and then being
> able to run all the Maple-language code on top of it. Duplicating
> the Maple kernel might not actually be so challenging because a
> good deal of it is likely to be already in Lisp.
>
Storage management,
> list processing, bignums. And writing a parser /interpreter is
> generally easy, especially for a simple language like Maple.
>
> It would presumably be a violation of something to share
> it with anyone else.
>
Didn't you do exactly the above with Mathematica, but were unable to
continue because of a cease and desist letter from Wolfram?
> Sage has many packages with duplicative routines, but apparently
> disparate treatment of edge problems. The advantage of having
> someone with a Wolfram-like ego, plus a majority ownership of the
> business, is that he can make a decision without reference to a
> Code of Conduct.
>
Having 750 fulltime employees is another advantage...
-- William
> RJF
>
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sage-devel+unsubscr...@googlegroups.com.
> To post to this group, send email to sage-devel@googlegroups.com.
> Visit this group at http://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/d/optout.
>
--
William Stein
Professor of Mathematics
University of Washington
http://wstein.org
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
