Talk About Network

Google


Register and Login
Nick
Password
Register create new account Sign up is FREE and you can post replies, new topics, bookmark posts and more!
Recover lost password


Programming > Functional > Re: the necessi...
Latest [ Topics | Posts ] Archive Post A New Topic Post a Reply
<< Topic < Post Post 6 of 33 Topic 2757 of 2912
Post > Topic >>

Re: the necessity of Lisp's Objects?

by Jon Harrop <usenet@[EMAIL PROTECTED] > Feb 10, 2008 at 10:27 AM

Robert Maas, see http://tinyurl.com/uh3t
wrote:
>> From: Jon Harrop <use...@[EMAIL PROTECTED]
>
>> During my PhD I needed to convolve two "lists" and I found a
>> serious bug in Mathematica's ListConvolve function where it was
>> silently destroying its input (my data!).
> 
> Does the do***entation clearly say it's a destructive operation? If
> not, I agree it's a *horrible* bug, so that function needs to be
> avoided (until the bug is fixed). But ...

Exactly. The do***entation explicitly states that it is a non-destructive
operation but it was destroying its input.

>> I also wanted to use Mathematica's Compile function to improve
>> the performance of a function but discovered that it hung on
>> recursive functions (!). Mathematica 6 addresses this problem by
>> rejecting all recursive definitions. Can you imagine if Lisp's EVAL
>> hung on or rejected recursive functions?!
> 
> IMO that's a showstopper, a complete language rejector! The only
> language I ever used that didn't sup****t recursion was FORTRAN
> ("with format" and "2d") circa 1964-67 and possibly also FORTRAN IV
> a few years later. The reason was that it stored the return address in
> an impure cell contiguous with the function instead of on a separate
> stack, so each function had only one such place to hold *its* *own*
> return address. (First *-* for emphasis, like bold. Second *-* to
> denote computer science jargon "own variables" which are privately
> accessible but static bound.) FORTRAN IV on VM/CMS (as recently as
> 1991 when I last worked at Stanford) had a similar problem: IBM
> linkage, used by FORTRAN, has all registers saved and restored by
> means of a block of memory, one such block per function. (Note that
> even if a function actually changes only a couple registers, all
> sixteen of them are saved and restored, for simplicity, not
> efficiency.)

To be fair, this only affects compiled anonymous functions. Mathematica
can
still interpret recursive functions but it is very slow (~1,000x slower
than a compiled language in general).

>> My PhD was largely on wavelets so I obtained Wolfram Research's
>> own ($595!) WaveletExplorer add-on only to discover that they deal
>> solely with discrete wavelets and completely ignore continuous
>> wavelets.
> 
> Why didn't you ask around on newsgroups for consumer feedback, like
> the book reviews o Amazon.com, before making such a significant
> purchase for which you'd need a requisition rather than take
> (shake?) out of the petty cash jar (piggy bank?)?

Probably wouldn't have done much good, as it happens. Computer scientists
seem to be blissfully unaware of continuous wavelets and often teach and
learn that only discrete wavelets are significant.

>> Also, I needed textbook data structures and algorithms during my
>> PhD and found that Mathematica not only lacked them but could not
>> be used to implement them efficiently. Given that an efficient set
>> union is impossible for Mathematica users, for example, I would not
>> say that its standard library is comprehensive even in the context
>> of mathematics, let alone general-purpose computing.
> 
> If what you say is true, that's pretty awful. What low-level
> primitive is missing such that you can't even efficiently roll your
> own?

Compilation. :-)

I ****ted my ray tracer benchmark to Mathematica for a laugh and it runs
30x
slower than OCaml's interpreted bytecode, let alone its optimizing
native-code compiler.

> What do you classify as "efficient" for set union? Do you have 
> in mind using lists (with duplicates already eliminated) for
> emulating each set, and a hash table for registering all the
> elements in each set, and thereby being able to efficiently detect
> which elements are in both sets (for example by mapping down the
> elements of the smaller set checking if they are also in the
> hashtable of the larger set), hence need to be put just once in the
> union?

I would copy the OCaml implementation and use immutable balanced binary
trees.

> I take it from what you say that Mathematica has only one name
> space and no way to incrementally load new files as it's discovered
> that some function/method within them is needed for the task in
> progress (triggered by encountering an undefined function) or even
> the next task to start (invoked by the user manually)?

Mathematica does have something like that: hierarchical namespaces and it
can recognise packages when they're stored in the correct location on
disk.
That's how our wavelet transform package integrates neatly into
Mathematica. Look at our examples:

  http://www.ffconsultancy.com/products/CWT/HTML/tutorial.html

However, Mathematica lacks a decent number of third party packages (Debian
has ~100,000 packages but Mathematica has more like 100) and repository
for
them.

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?u
 




 33 Posts in Topic:
Re: the necessity of Lisp's Objects?
rem642b@[EMAIL PROTECTED]  2008-02-04 10:37:38 
Re: the necessity of Lisp's Objects?
Jon Harrop <usenet@[EM  2008-02-06 17:14:18 
Re: the necessity of Lisp's Objects?
"John Thingstad"  2008-02-06 19:42:31 
Re: the necessity of Lisp's Objects?
Jon Harrop <usenet@[EM  2008-02-07 00:07:54 
Re: the necessity of Lisp's Objects?
rem642b@[EMAIL PROTECTED]  2008-02-09 15:14:09 
Re: the necessity of Lisp's Objects?
Jon Harrop <usenet@[EM  2008-02-10 10:27:07 
Re: the necessity of Lisp's Objects?
rem642b@[EMAIL PROTECTED]  2008-02-15 23:12:34 
Re: the necessity of Lisp's Objects?
Jon Harrop <usenet@[EM  2008-02-16 21:02:03 
Re: the necessity of Lisp's Objects?
rem642b@[EMAIL PROTECTED]  2008-02-09 15:21:54 
Re: the necessity of Lisp's Objects?
"John Thingstad"  2008-02-10 01:48:39 
Re: the necessity of Lisp's Objects?
rem642b@[EMAIL PROTECTED]  2008-02-11 23:29:33 
Re: the necessity of Lisp's Objects?
Jon Harrop <usenet@[EM  2008-02-12 16:37:06 
Re: the necessity of Lisp's Objects?
rem642b@[EMAIL PROTECTED]  2008-02-07 22:25:25 
Re: the necessity of Lisp's Objects?
Jon Harrop <usenet@[EM  2008-02-08 21:06:41 
Re: the necessity of Lisp's Objects?
rem642b@[EMAIL PROTECTED]  2008-02-09 15:24:21 
Re: the necessity of Lisp's Objects?
Jon Harrop <usenet@[EM  2008-02-10 10:26:42 
Re: the necessity of Lisp's Objects?
"David Formosa (aka   2008-02-10 11:23:32 
Re: the necessity of Lisp's Objects?
George Neuner <gneuner  2008-02-10 23:54:27 
Re: the necessity of Lisp's Objects?
rpw3@[EMAIL PROTECTED] (  2008-02-11 02:56:22 
Re: the necessity of Lisp's Objects?
George Neuner <gneuner  2008-02-11 20:53:12 
Re: the necessity of Lisp's Objects?
Jon Harrop <usenet@[EM  2008-02-12 02:17:33 
Re: the necessity of Lisp's Objects?
"John Thingstad"  2008-02-12 04:48:24 
Re: the necessity of Lisp's Objects?
Jon Harrop <usenet@[EM  2008-02-12 16:35:17 
Re: the necessity of Lisp's Objects?
George Neuner <gneuner  2008-02-12 15:18:23 
Re: the necessity of Lisp's Objects?
Jon Harrop <usenet@[EM  2008-02-12 20:16:55 
Re: the necessity of Lisp's Objects?
rpw3@[EMAIL PROTECTED] (  2008-02-12 05:34:01 
Re: the necessity of Lisp's Objects?
Jon Harrop <usenet@[EM  2008-02-11 10:41:47 
Re: the necessity of Lisp's Objects?
Barb Knox <see@[EMAIL   2008-02-11 09:52:26 
Re: the necessity of Lisp's Objects?
rem642b@[EMAIL PROTECTED]  2008-02-15 23:17:07 
Re: the necessity of Lisp's Objects?
Jon Harrop <usenet@[EM  2008-02-16 20:46:11 
Re: the necessity of Lisp's Objects?
Pascal Bourguignon <pj  2008-02-08 22:33:21 
Re: the necessity of Lisp's Objects?
rem642b@[EMAIL PROTECTED]  2008-02-20 15:25:52 
Re: the necessity of Lisp's Objects?
rem642b@[EMAIL PROTECTED]  2008-02-20 17:12:43 

Post A Reply:
  Go here to Signup

AddThis Feed Button


About - Advertising - Contact - Frequently Asked Questions - Privacy Policy - Terms of Use - Signup

Contact
tan12V112 Sat Jul 26 4:15:16 CDT 2008.