[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: small integers
- To: cassels@cambridge.apple.com
- Subject: Re: small integers
- From: jim@fpr.com (James E. O'Dell)
- Date: Sat, 10 Oct 1992 18:21:52 -4
- Cc: moon@CAMBRIDGE.APPLE.COM, info-dylan@CAMBRIDGE.APPLE.COM
- Organization: Fort Pond Research
- Reply-to: jim@fpr.com
On Sat, 10 Oct 1992, Robert A. Cassels <cassels@cambridge.apple.com>
wrote:
>>whether the compiler is smart enough to figure this out as well. In
>>practice, people just say "fixnum" and then complain about how slow
>>arithmetic is in Lisp. It's infinitely easier just to say, one way or
>>another, that you don't believe overflows will occur in a certain part
of
>>the program, and that you want to get an error signal if you're wrong.
>
>This part succinctly captures the dilemma as I see it. We all agree
that
>we want fast, efficient, robust code. And we want it to be easy for the
>programmer to write such code. Ideally we'd like the compiler and
runtime
>to be simple and easy to implement. A machine that implements integer
>arithmetic "in the instruction set" (c.f. Lisp machines) satisfies the
>constraints nicely. For most special-purpose C/Fortran machines, the
set
>of constraints can't be satisfied, and something has to give.
I see the dillema slightly differently. I'd love to write mathematical
simulations
using "correct" arithmetic. Unfortunately, its impossible, since any" real"
simulation
program that I write runs much too slowly in lisp. For all of its faults,
FORTRAN is still
extremely efficient for writing number crunching code that marches over
large arrays.
Until a Dylan or Lisp implementation can DEMONSTRATE equivalent efficiency,
I don't
believe it will be taken seriously by your target audience.