Re: Optimizing for fast floating-point numerical code

Alberto Riva <alb@xxxxxxxxxxxxxx> writes:

David A. Ventimiglia wrote:
"Thomas M. Hermann" <tmh.public@xxxxxxxxx> writes:

Another thing you should be careful of when making the comparison of
your lisp code with Fortran is that the difference in the
implementations of RANDOM can be significant since you are calling it
inside your loop. On one hand, it is valid to evaluate this difference
because implementing your own random number generation function would
be pretty annoying. On the other hand, if generating random numbers is
a critical part of your algorithm, it may be worth your time to
research how it is accomplished in the respective languages and
implement a version that better meets your requirements.

This point is interesting to me. Evidently, it'd be unsurprising for an
intrinsic function like `random' in a given Lisp implementation to be
suboptimal, perhaps very much so.

I don't think Thomas meant that the built-in RANDOM is suboptimal in
terms of speed, I think he meant that it's probably going to be
different from the one in your Fortran implementation. There's no such
thing as really random numbers, they're called pseudo-random for a
reason, and they may be "pseudo" in different ways (ie, have different
statistical properties). In other words, you may get slightly
different results, even if the rest of your algorithm is exactly the
same.

Alberto

Hi Alberto,

Maybe I'm wrong, but I inferred that Thomas did indeed mean that the
built-in RANDOM may be suboptimal in terms of speed, given the
significance he attributes to its use inside a loop, and given his
conjecture that re-implementing it may be a way to meet my requirements,
which are execution speed. But again, maybe I mis-interpreted.

On the other hand, I would be very worried if the distributions occupied
by random numbers generated by Lisp and Fortran don't converge in their
statistical properties (like first couple of moments). Does that
actually happen?

Best,
David

--
________________________________________
David A. Ventimiglia
Graduate Student
Michigan State University
.

Relevant Pages

  • Re: Optimizing for fast floating-point numerical code
    ... the closest analogs to Fortran 95's very fast vectorized operations. ... say, however, that in Lisp they don't compete well with looping? ... (defun example (y l) ... (declare (inline attach)) ...
    (comp.lang.lisp)
  • Re: What do you LISPers think of Haskell?
    ... "Lisp is as fast as Fortran for scientific computing" claims economics ... His published software includes a sparse matrix library written in Lisp ...
    (comp.lang.lisp)
  • Lisp as a tool for the mind
    ... "Lisp is as fast as Fortran for scientific computing" claims economics ... His published software includes a sparse matrix library written in Lisp ...
    (comp.lang.lisp)
  • Re: Freepascal rocks!
    ... I've been experimenting with a few programming languages lately: Assembler, Lisp, Forth, Smalltalk. ... A language powerful enough to simply implement another language is damn powerful. ... The other day I joked to my colleagues that we should be writing more stuff in FORTRAN; my contention being that FORTRAN doesn't really do much, so you *have* to keep things simple. ... CurRow, CurCol: Integer; ...
    (comp.lang.pascal.misc)
  • Re: Optimizing for fast floating-point numerical code
    ... statistical properties. ... Common Lisp the Language, 2nd Edition says, "While two implementations ... may produce different series of pseudo-random numbers, the distribution ... This might be true if they implement the same algorithm in largely the ...
    (comp.lang.lisp)