I came across this example, Rump's problem, used to demonstrate floating
point limitations in languages such a C and Fortran. With Common Lisp using
rationals instead of the floats 333.75 and 5.5 getting the right answer is
simple. I wanted to write the same example in Python and Perl but quickly
discovered that those languages do not implement anything like the number
system of Common Lisp. I guess they still have a ways to go to reinvent the
wheel.
Is there something I am missing to implement Rump's problem (and get right
answers) in Python and/or Perl? I guess there is a module somewhere but so
what.
What other languages basically parallel the Common Lisp number system?
;; With inputs x=77617 and y=33096 right answer is -0.827396 and NOT 1.1726
(defun rump (x y)
(coerce
(+ (* (+ 333 3/4) (expt y 6))
(* (expt x 2) (- (* 11 (expt x 2) (expt y 2)) (expt y 6) (* 121 (expt
y 4)) 2))
(* (+ 5 1/2) (expt y 8))
(/ x 2 y))
'double-float))
John Watton
---------------
"John Watton" <·······@dellepro.com> wrote in message news:<··········@news1.prserv.net>...
> I came across this example, Rump's problem, used to demonstrate floating
> point limitations in languages such a C and Fortran. With Common Lisp using
> rationals instead of the floats 333.75 and 5.5 getting the right answer is
> simple. I wanted to write the same example in Python and Perl but quickly
> discovered that those languages do not implement anything like the number
> system of Common Lisp. I guess they still have a ways to go to reinvent the
> wheel.
Different languages have different goals. I don't expect to see too
much heavy large number crunching in Perl or Python. You had to write
the code differently to get rationals, in Haskell the default default
is double, however the conversion from Rational is enough for the
inferencer to give the proper types, plenty of other languages don't
provide arbitrary precision anything except as a library, if that.
Obviously, most programmer's don't find this a critical requirement.
> Is there something I am missing to implement Rump's problem (and get right
> answers) in Python and/or Perl? I guess there is a module somewhere but so
> what.
>
> What other languages basically parallel the Common Lisp number system?
>
> ;; With inputs x=77617 and y=33096 right answer is -0.827396 and NOT 1.1726
> (defun rump (x y)
> (coerce
> (+ (* (+ 333 3/4) (expt y 6))
> (* (expt x 2) (- (* 11 (expt x 2) (expt y 2)) (expt y 6) (* 121 (expt
> y 4)) 2))
> (* (+ 5 1/2) (expt y 8))
> (/ x 2 y))
> 'double-float))
Any language with arbitrary precision integers will be able to solve
this problem correctly. Alternatively, one can use a library.
As Alex mentioned this can be done quite straightforwardly in Haskell.
However, not being too familiar with Lisp's number system, I'm not
sure how much I'd say Haskell's number system "parallels" Lisp's.
Anyways, as I've said above all you need is arbitrary precision
integers, and a language that provides only those (perhaps in addition
to the other basic types) certainly doesn't parallel Lisp's number
system.
On Mon, Jul 14, 2003 at 01:52:59PM -0700, Darius wrote:
> Obviously, most programmer's don't find this a critical requirement.
Until they find subtle round-off errors in the floating point code, or
they discover that the mysterious values in the results were caused by
overflowing a 32-bit-sized variable ;-)
> > ;; With inputs x=77617 and y=33096 right answer is -0.827396 and NOT 1.1726
> > (defun rump (x y)
> > (coerce
> > (+ (* (+ 333 3/4) (expt y 6))
> > (* (expt x 2) (- (* 11 (expt x 2) (expt y 2)) (expt y 6) (* 121 (expt
> > y 4)) 2))
> > (* (+ 5 1/2) (expt y 8))
> > (/ x 2 y))
> > 'double-float))
>
> Any language with arbitrary precision integers will be able to solve
> this problem correctly. Alternatively, one can use a library.
If you want to implement ratios yourself. But you can implement
``arbitrary precision'' integers in any actual programming language
too.
> However, not being too familiar with Lisp's number system, I'm not
> sure how much I'd say Haskell's number system "parallels" Lisp's.
I do seem to recall reading somewhere that Haskell's number system was
inspired from the numeric towers of Lisp and Scheme systems.
--
; Matthew Danish <·······@andrew.cmu.edu>
; OpenPGP public key: C24B6010 on keyring.debian.org
; Signed or encrypted mail welcome.
; "There is no dark side of the moon really; matter of fact, it's all dark."
The world rejoiced as ·······@hotpop.com (Darius) wrote:
> "John Watton" <·······@dellepro.com> wrote in message news:<··········@news1.prserv.net>...
>> I came across this example, Rump's problem, used to demonstrate
>> floating point limitations in languages such a C and Fortran. With
>> Common Lisp using rationals instead of the floats 333.75 and 5.5
>> getting the right answer is simple. I wanted to write the same
>> example in Python and Perl but quickly discovered that those
>> languages do not implement anything like the number system of
>> Common Lisp. I guess they still have a ways to go to reinvent the
>> wheel.
>
> Different languages have different goals. I don't expect to see too
> much heavy large number crunching in Perl or Python. You had to
> write the code differently to get rationals, in Haskell the default
> default is double, however the conversion from Rational is enough
> for the inferencer to give the proper types, plenty of other
> languages don't provide arbitrary precision anything except as a
> library, if that. Obviously, most programmer's don't find this a
> critical requirement.
Actually, I have heard quite a few reports of people into "scientific
number crunching" very much liking working in Python.
Think of it from the perspective of those that used to use FORTRAN...
- They can get at great gobs of libraries like LINPACK, SPARSPAK, and
such, much as they used to with FORTRAN;
- The "wrapper" code to load data into arrays is I/O bound, and thus
not likely to be massively slowed by interpretive overhead;
- Once the data's in matrices, it can be passed on to the Highly Tuned
Libraries that transform it at breakneck machine code speed.
- Generating pretty output is likely a lot nicer in Python than it
used to be in FORTRAN.
And remember that the traditional FORTRAN style libraries were all FP
stuff, not rational...
The BIG wins are likely to come from using mature numerical libraries,
and they represent already-debugged-for-FP-behaviour code...
--
If this was helpful, <http://svcs.affero.net/rm.php?r=cbbrowne> rate me
http://www3.sympatico.ca/cbbrowne/linuxdistributions.html
"Who is General Failure and why is he reading my hard disk?"
-- <·······@inf.fu-berlin.de>, Felix von Leitner
·······@hotpop.com (Darius) writes:
> Different languages have different goals. I don't expect to see too
> much heavy large number crunching in Perl or Python. You had to write
> the code differently to get rationals, in Haskell the default default
> is double, however the conversion from Rational is enough for the
> inferencer to give the proper types, plenty of other languages don't
> provide arbitrary precision anything except as a library, if that.
> Obviously, most programmer's don't find this a critical requirement.
This is partly true. And most languages probably also have a BCD
library as well. Consider this though. The decimal number 0.1 can
not be represented with a finite number of binary digits anymore than
1/3 can be represented with a finite number of decimal digits.
--
One Editor to rule them all. One Editor to find them,
One Editor to bring them all and in the darkness bind them.
(do ((a 1 b) (b 1 (+ a b))) (nil a) (print a))
> What other languages basically parallel the Common Lisp number system?
Haskell has a Rational data type which is pretty similar to Common Lisp's.
--
Alex Drummond
John Watton wrote:
> I came across this example, Rump's problem, used to demonstrate floating
> point limitations in languages such a C and Fortran. With Common Lisp
> using rationals instead of the floats 333.75 and 5.5 getting the right
> answer is simple. I wanted to write the same example in Python and Perl
> but quickly discovered that those languages do not implement anything like
> the number system of Common Lisp. I guess they still have a ways to go to
> reinvent the wheel.
>
> Is there something I am missing to implement Rump's problem (and get right
> answers) in Python and/or Perl? I guess there is a module somewhere but so
> what.
>
> What other languages basically parallel the Common Lisp number system?
>
> ;; With inputs x=77617 and y=33096 right answer is -0.827396 and NOT
> 1.1726 (defun rump (x y)
> (coerce
> (+ (* (+ 333 3/4) (expt y 6))
> (* (expt x 2) (- (* 11 (expt x 2) (expt y 2)) (expt y 6) (* 121
> (expt
> y 4)) 2))
> (* (+ 5 1/2) (expt y 8))
> (/ x 2 y))
> 'double-float))
>
>
> John Watton
> ---------------