Am Montag, den 11.02.2008, 23:29 -0800 schrieb Robert Maas, see
http://tinyurl.com/uh3t:
> > From: "John Thingstad" <·······@online.no>
> > Mathematica does have recursion.
> > The problem comes when you try to compile the code.
> > But compiling code in Mathematica is unusual.
>
> Somebody said if the code isn't compiled, it runs a thousand times
> slower.
That sounds like Jon overgeneralizing again.
> For any major program component, it would seem essential to
> compile it to give anywhere near decent speed.
Probably not. It all depends what you do. If you're just sticking
together predefined functions, Mathematica should have decent speed
because the interpreter is just providing the glue. I suspect that's the
kind of use that Mathematica was designed for.
If, on the other hand, you use Mathematica to implement an algorithm
from the ground up, then performance will probably suck. Seems to be a
case of felling trees using a hammer. (I think the real criticism that
can be levelled at Mathematica is that it *could* run much, much faster
if the designers had paid a little bit of attention to the issue,
witness all those fast FPL interpreters that are around. OTOH I know
that every additional design constraints can massively complicate a
system, increase development time and developer load, and damage
reliability, so I'd probably take the same design choices as Wolfram
did, and I certainly won't blame Wolfram Research for building a slow
but reliable interpreter.)
Of course, simply crashing on a recursive function instead of emitting a
decent error message is a bug.
> How would we feel
> about Lisp if the compiler didn't work on anything recusrive, for
> example READ had to always be run interpreted? Would Lispers
> tolerate that??
Apples and oranges.
If the standard mode of operation were interpretive, then probably yes.
In practice, Lisp programs don't drop down to another language to do
those things that need to be fast (like Mathematica does), so the
standard mode of operation must be compiling. Under these constraints,
the compiler must be able to deal with anything that the programmer
throws at it.
> > Compile is primarily meant to speed up numerical calculations.
>
> So if you define a function that performs some sort of butterfly to
> efficiently perform arithmetic such as modular exponentiation on
> very large integers, and of course it's recursive, you lose???
I guess you'd ask Wolfram to implement modular exponentiation.
Remember that most users of Mathematica are researchers, not
programmers. They'd be unable to implement a solid algorithm anyway, and
not even interested in doing so (unless they also happen to be
programmers, in which case Mathematica sucks for them, of course - but
these are the exception and not Wolfram's target audience anyway, I
think).
> Does Mathematica provide support for (unix) inter-process streams
> (pipes), so that you could have a Lisp sitting alongside it to
> perform calcuations that required recursion?
Don't know, but it would be a neat feature for those who are both
programmers and researchers.
Of course, it would also reduce Wolfram's business model, because adding
new algorithms can make an upgrade attractive to their existing user
base. So it's unlikely that Wolfram have done or will do that, unless
some serious competition provides such a mechanism. (There's a market
niche; any takers?)
Regards,
Jo
Joachim Durchholz wrote:
> Am Montag, den 11.02.2008, 23:29 -0800 schrieb Robert Maas, see
> http://tinyurl.com/uh3t:
>> For any major program component, it would seem essential to
>> compile it to give anywhere near decent speed.
>
> Probably not. It all depends what you do. If you're just sticking
> together predefined functions, Mathematica should have decent speed
> because the interpreter is just providing the glue. I suspect that's the
> kind of use that Mathematica was designed for.
I think it fell out of history. Mathematica was originally designed as a
computer algebra system. Only after its release did the authors realise
that there is vastly more money in numerics and graphics than symbolics, so
they started tacking on all sorts of numerical methods and a GUI to turn it
into the "integrated technical computing environment" that it is today.
> If, on the other hand, you use Mathematica to implement an algorithm
> from the ground up, then performance will probably suck. Seems to be a
> case of felling trees using a hammer. (I think the real criticism that
> can be levelled at Mathematica is that it *could* run much, much faster
> if the designers had paid a little bit of attention to the issue,
> witness all those fast FPL interpreters that are around. OTOH I know
> that every additional design constraints can massively complicate a
> system, increase development time and developer load, and damage
> reliability, so I'd probably take the same design choices as Wolfram
> did, and I certainly won't blame Wolfram Research for building a slow
> but reliable interpreter.)
Except that Mathematica is based upon term rewriting rather than an
interpreter. This is why Mathematica is so slow: 30x slower than
*interpreted* OCaml.
>> How would we feel
>> about Lisp if the compiler didn't work on anything recusrive, for
>> example READ had to always be run interpreted? Would Lispers
>> tolerate that??
>
> Apples and oranges.
> If the standard mode of operation were interpretive, then probably yes.
> In practice, Lisp programs don't drop down to another language to do
> those things that need to be fast (like Mathematica does), so the
> standard mode of operation must be compiling. Under these constraints,
> the compiler must be able to deal with anything that the programmer
> throws at it.
I disagree. Lisp functions often make FFI calls to C for performance and
interoperability. Moreover, there is no reason to avoid compilation to an
internal bytecode to improve performance.
>> > Compile is primarily meant to speed up numerical calculations.
>>
>> So if you define a function that performs some sort of butterfly to
>> efficiently perform arithmetic such as modular exponentiation on
>> very large integers, and of course it's recursive, you lose???
>
> I guess you'd ask Wolfram to implement modular exponentiation.
> Remember that most users of Mathematica are researchers, not
> programmers. They'd be unable to implement a solid algorithm anyway, and
> not even interested in doing so (unless they also happen to be
> programmers, in which case Mathematica sucks for them, of course - but
> these are the exception and not Wolfram's target audience anyway, I
> think).
Again, I disagree. Many Mathematica users are excellent programmers. I
recently met some of the guys at Barclays Capital in London who use
Mathematica and they do great work in a wide variety of programming
languages (including Haskell).
Mathematica has stopped evolving not because its users are researchers but
because its authors are millionaires.
>> Does Mathematica provide support for (unix) inter-process streams
>> (pipes), so that you could have a Lisp sitting alongside it to
>> perform calcuations that required recursion?
>
> Don't know, but it would be a neat feature for those who are both
> programmers and researchers.
> Of course, it would also reduce Wolfram's business model, because adding
> new algorithms can make an upgrade attractive to their existing user
> base. So it's unlikely that Wolfram have done or will do that, unless
> some serious competition provides such a mechanism. (There's a market
> niche; any takers?)
We thought about it but we had previously found that there's no money in
making Mathematica add-ons:
http://www.ffconsultancy.com/products/CWT/
If anything, we'll turn F# for Visualization into a complete technical
computing environment based around F# with integrated visualization and go
for wholesale replacement of Mathematica.
I think a technical computing environment with integrated visualization is
worth maybe �100, so I'm quite sure we can compete with Mathematica's
�2,000! :-)
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?u