[clean-list] Communicating with other programs

[David McClain]

IDL can't scale properly for 2-D FFT's.  They appear to be doing a tree walk
on every butterfly operation... Whereas proper time scaling should go as
O(2*N^2*Log2(N)) theirs goes as O((N*Log2(N))^2). I think it has something
to do with their willingness to accommodate non-power-of-two array sizes.

But aside from FFT's all the math is written in OCaml. In general, I find
that this produces code that runs about 2x times faster than the C-based
internal code of IDL. Add to that the convenience of FPL and uniform
terseness for numerics and non-numeric code alike, I find my NML to be far
preferable. NML is intentionally similar in syntax to OCaml on which it is
based.

But since you are interested mostly in the graphics for plotting scientific
data, why not begin there? The graphics routines all live inside of a C++
library. I use this same library for all of NML, OCaml, Lisp, Scheme, Dylan,
and many other languages (...yes including VBasic and C/C++). It is quite
independent of OCaml except for the type of arguments and return values in
the highest layers of this code. But as I said, I use it routinely from Lisp
as well, so these are not hindrances to the use of the graphics plotting
lib.

Once you have scientific graphics available to you, you might find no
further need to continue the porting of NML to Clean. Why not just stay in
clean?  I wrote NML to be intentionally dynamically typed, so that ad-hoc
computations at the keyboard are not as painful as doing type-correct coding
in OCaml. Also, the math routines are all overloaded to handle vectors as
well as scalars, unlike OCaml.

- David McClain, Sr. Scientist, Raytheon Systems Co., Tucson, AZ

----- Original Message -----
From: "Siegfried Gonzi" <siegfried.gonzi@kfunigraz.ac.at>
To: "David McClain" <barabh@qwest.net>
Cc: <clean-list@cs.kun.nl>
Sent: Friday, November 16, 2001 1:26 AM
Subject: Re: [clean-list] Communicating with other programs


> >NML is currently aimed at image processing for space based missions, and
we
> >do tons of 2-D FFT processing on large images. We utilize the Intel Math
> >Kernel Library 1-D FFT's wrapped in a multithreaded DLL that performs
> >parallelized 2-D FFT's. On my lowly 350 MHz PII with Win/NT 4.0 I get
> >approximately 18 MButterflys/sec from NML (1024x1024 2-D complex FFT in
> >about 1.1 sec.) On our quad Xeon at work we get closer to 200
> >MButterflys/sec.
>
> We should really start the project. I am astonished that IDL is not faster
> (2.2sec). That said. Clean takes for a 2d FFT (a simple
straightforward-code)
> 2.5sec on a 450MHz Mac (according to J. v. Groningen). So there is maybe
the
> opportunity for some improvements. But I think 1.1 or 3sec is not really
> important, at a first glance.
>
> As we talked it privately it is a good idea do have a leader. And David
McClain
> is predistined for that task. First there should be a requirement-schedule
and
> how the work can be sliced. And especially which platform should become
> supported. Is it possible to deliver for the Macintosh, Windows, and Unix?
>
> And the next step? GUI layout? Will it be a good idea to include linAlg C
> functions and hope in turn that when time goes on people will supersede it
with
> their own Clean-native routines?
>
> Or should we concentrate (at first) on the plotting library alone? And
> implementing numerical stuff later?
>
> >So, any takers?
>
> Everybody interested in should take the chance.
>
>
> Whom it may concern: If you are intimidated by the fact that you can also
buy
> Clean commercially and now are wondering why you should contribute to
their
> Porsches and Ferraris, then it is time to take a contemplation (for
yourself)
> and answer honestly the following question:
>
> Do you really believe that Perl or Python (or, or...) addicts do not
contribute
> to industry, if Perl or Python is open source, even? Surely, you can
consult the
> GPL licence terms but without the Perl or Python hype by all this
programmers
> maybe no fortune500-company woul ever thinking on using Perl or Python. In
open
> source you often do not contrubute with source-code but with hype instead.
>
>
> S. Gonzi
>
>
>
> _______________________________________________
> clean-list mailing list
> clean-list@cs.kun.nl
> http://www.cs.kun.nl/mailman/listinfo/clean-list