As a lisp newbie, I'm sorry if this one is obvious. However, I'm a
bit puzzled by the
following executed from the prompt:
* (- 1234.56 4.57)
1229.9901
I tried this with several installations of this (ubuntu, compiled from
src, and
precompiled binary). Any ideas?
Thanks,
Steve
On Oct 30, 8:07 pm, ···············@gmail.com wrote:
> As a lisp newbie, I'm sorry if this one is obvious. However, I'm a
> bit puzzled by the
> following executed from the prompt:
>
> * (- 1234.56 4.57)
>
> 1229.9901
>
> I tried this with several installations of this (ubuntu, compiled from
> src, and
> precompiled binary). Any ideas?
If you're wondering about the lack of perfection, other posts have
addressed that. If you're wondering about the lack of precision, the
following may provide some insight:
CLisp 2.41
[1]> (- 1234.56 4.57)
1229.9901
[2]> (- 1234.56d0 4.57d0)
1229.99d0
[3]> (- 1234.56l0 4.57l0)
1229.9900000000000001L0
[4]> (- 1234.56f0 4.57f0)
1229.9901
I just looked that up on p. 118 of Practical Common Lisp. Are there
other ways to indicate to the compiler which precision one wants?
Brian Adkins
BA> I just looked that up on p. 118 of Practical Common Lisp. Are there
BA> other ways to indicate to the compiler which precision one wants?
compiler has nothing to do with it -- it's about data types used, and that
happens on stage of reading.
On Oct 31, 4:44 am, "Alex Mizrahi" <········@users.sourceforge.net>
wrote:
> BA> I just looked that up on p. 118 of Practical Common Lisp. Are there
> BA> other ways to indicate to the compiler which precision one wants?
>
> compiler has nothing to do with it -- it's about data types used, and that
> happens on stage of reading.
The compiler/interpreter certainly has something to do with data
types, but, more importantly, since the relevant part of the question
concerned ways of indicating precision, and not at which stage a data
type is selected, a more helpful response could have included the
information that Richard Kreuter provided:
(setf *read-default-float-format* 'double-float)
"Alex Mizrahi" <········@users.sourceforge.net> writes:
> BA> I just looked that up on p. 118 of Practical Common Lisp. Are there
> BA> other ways to indicate to the compiler which precision one wants?
>
> compiler has nothing to do with it -- it's about data types used, and that
> happens on stage of reading.
>
>
Hi,
I think that this section:
http://www.lisp.org/HyperSpec/Body/sec_2-3-2-2.html
might be helpful.
The magic specifiers are s, f, d, and l for short, single, double, and
long float.
The specs are:
Short 13 bits 5 bits
Single 24 bits 8 bits
Double 50 bits 8 bits
Long 50 bits 8 bits
Keep in mind in all of this that many, most, all? lisp systems, given
that they work on systems with FPUs in hardware, use said FPU. This
may not always give one the results one expects (hopes for, prays
for, what ever) ...
http://blogs.sun.com/jag/entry/transcendental_meditation
The cute quote is: 'I've never been a fan of "fast, but wrong" when
"wrong" is roughly random().'
Someone has already mentioned the what you need to know about floating
point math. It's well worth ones time to read it. No, I'm not
kidding. FP math does not behave the way you wish it to, even if you
don't have to contend with implimentation errors.
I will not even start the rant on how bit errors in the lowest bit of
a FP number can propigate up until you get different branches taken.
Boy is that fun on different implimentations of the same arch, let
alone different archs.
cheers
bruce
--
The Brave New World of privatized digitally rights managed data sounds
good, but when you combine complex business strategies with today's
incompetent programmers, the result is that customers probably won?t
get what they paid for. In an airplane, in the clouds, this is not
comforting. - Phil Greenspun
http://www.pckswarms.ch
In article <························@o80g2000hse.googlegroups.com>,
···············@gmail.com wrote:
> As a lisp newbie, I'm sorry if this one is obvious. However, I'm a
> bit puzzled by the
> following executed from the prompt:
>
> * (- 1234.56 4.57)
>
> 1229.9901
>
> I tried this with several installations of this (ubuntu, compiled from
> src, and
> precompiled binary). Any ideas?
>
> Thanks,
> Steve
What would you expect as a result? Think about it.
What Every Computer Scientist Should Know About Floating-Point Arithmetic
http://www.physics.ohio-state.edu/~dws/grouplinks/floating_point_math.pdf
Rainer Joswig wrote:
> In article <························@o80g2000hse.googlegroups.com>,
> ···············@gmail.com wrote:
>
>> As a lisp newbie, I'm sorry if this one is obvious. However, I'm
>> a bit puzzled by the following executed from the prompt:
>>
>> * (- 1234.56 4.57)
>>
>> 1229.9901
>
> What would you expect as a result? Think about it.
>
> What Every Computer Scientist Should Know About Floating-Point
> Arithmetic
> http://www.physics.ohio-state.edu/~dws/grouplinks/floating_point_math.pdf
>
I'm gonna disagree with your claim; it feels like an error in how SBCL
prints floats. IEEE 754's single float has 24 (23+1 hidden) fraction
bits; log10(2^24)=7.2 digits.
So single floats have "7 decimal digits" of precision.
According to the paper you linked, 9 digits are required for perfect
reconstruction (pdf page 66, theorem 15).
How did SBCL and CLisp (and others?) end up printing 8 digits? Its
enough to be confusing, but not enough for reconstruction...
- Daniel
On Oct 30, 11:10 pm, D Herring <········@at.tentpost.dot.com> wrote:
> I'm gonna disagree with your claim; it feels like an error in how SBCL
> prints floats. IEEE 754's single float has 24 (23+1 hidden) fraction
> bits; log10(2^24)=7.2 digits.
>
> So single floats have "7 decimal digits" of precision.
> According to the paper you linked, 9 digits are required for perfect
> reconstruction (pdf page 66, theorem 15).
>
> How did SBCL and CLisp (and others?) end up printing 8 digits? Its
> enough to be confusing, but not enough for reconstruction...
No, it is enough for reconstruction. 9 digits is a worst-case figure;
you obviously only need 1 digit to print 1 (1.0000...) perfectly.
These CL implementations only print just enough digits to accurately
reconstruct the numbers; that might even be explicitly specified in
the standard.
Paul Khuong
D Herring wrote:
> How did SBCL and CLisp (and others?) end up printing 8 digits? Its
> enough to be confusing, but not enough for reconstruction...
Or are they cleverly optimized to print the minimum number of digits
needed for perfect reconstruction of a given float?
- Daniel
From: Kent M Pitman
Subject: Re: Floating point issue in sbcl 1.0.10?
Date:
Message-ID: <uabq0t13q.fsf@nhplace.com>
Rainer Joswig <······@lisp.de> writes:
> In article <························@o80g2000hse.googlegroups.com>,
> ···············@gmail.com wrote:
>
> > As a lisp newbie, I'm sorry if this one is obvious. However, I'm a
> > bit puzzled by the
> > following executed from the prompt:
> >
> > * (- 1234.56 4.57)
> >
> > 1229.9901
> >
> > I tried this with several installations of this (ubuntu, compiled from
> > src, and
> > precompiled binary). Any ideas?
> >
> > Thanks,
> > Steve
>
> What would you expect as a result? Think about it.
>
>
> What Every Computer Scientist Should Know About Floating-Point Arithmetic
> http://www.physics.ohio-state.edu/~dws/grouplinks/floating_point_math.pdf
FWIW, LispWorks for WIndows (LWW) 4.4.5 yields 1229.99 but LWW 5.0.1
yields 1229.9901. I didn't have time to bit-decode this to see if it
was the usual floating point issue, though my initial expectation is
that it probably is. But I found it interesting that there'd been a
change between two versions of LWW 4.4.5 and 5.0.1. Maybe the
LispWorks maintainers know what they changed and why...?
From: Richard M Kreuter
Subject: Re: Floating point issue in sbcl 1.0.10?
Date:
Message-ID: <877il398uq.fsf@progn.net>
Kent M Pitman <······@nhplace.com> writes:
> FWIW, LispWorks for WIndows (LWW) 4.4.5 yields 1229.99 but LWW 5.0.1
> yields 1229.9901. I didn't have time to bit-decode this to see if it
> was the usual floating point issue, though my initial expectation is
> that it probably is. But I found it interesting that there'd been a
> change between two versions of LWW 4.4.5 and 5.0.1. Maybe the
> LispWorks maintainers know what they changed and why...?
From the LispWorks Release Notes and Installation Guide available at
[1]:
| 12.6.7 More float types implemented on x86 platforms
|
| LispWorks now implements 3 disjoint ANSI Common Lisp float types:
| short-float, single-float and double-float.
|
| long-float is the same type as double-float.
|
| Note: In versions 4.4 and previous of LispWorks for Windows and
| LispWorks for Linux all floats are double-float.
[1] http://www.lispworks.com/documentation/index.html
> What would you expect as a result? Think about it.
Well, I would expect 1229.99, wouldn't you? This is the result every
other language I've used would return. (I just checked several to
confirm -- C, Fortran, perl, R, APL). Even my free piece-of-junk
solar calculator can get the "correct" answer. If this is a floating
point nuance as you claim, and is the expected answer, then perhaps I
need to reevalulate learning lisp -- it may not be suitable for my
needs.
(sorry if this is a repeat -- original reply seemed to get lost...)
<···············@gmail.com> wrote:
> > What would you expect as a result? Think about it.
>
> Well, I would expect 1229.99, wouldn't you?
Not really.
> This is the result every other language I've used would return. (I just
> checked several to confirm -- C, Fortran, perl, R, APL).
int main (int argc, const char * argv[])
{
float n1 = 1234.56;
float n2 = 4.57;
printf("%f\n", n1 - n2);
return 0;
}
prints: 1229.990112
> Even my free piece-of-junk solar calculator can get the "correct" answer.
What precision floating-point does it use? Might it be using BCD?
> If this is a floating point nuance as you claim, and is the expected
> answer, then perhaps I need to reevalulate learning lisp -- it may not be
> suitable for my needs.
The problem doesn't appear to be with Lisp.
From: Richard M Kreuter
Subject: Re: Floating point issue in sbcl 1.0.10?
Date:
Message-ID: <87ejfc7zy7.fsf@progn.net>
···············@gmail.com writes:
>> What would you expect as a result? Think about it.
>
> Well, I would expect 1229.99, wouldn't you? This is the result
> every other language I've used would return. (I just checked
> several to confirm -- C, Fortran, perl, R, APL).
In C, floating point constants without a terminal F or L parse into
doubles (for a reference, see K&R, section 2.3, paragraph 2). If you
do the subtraction on single floats, you'll find that C will give the
same answer as you're seeing from Lisp:
$ cat float.c
#include <stdio.h>
main () {
printf("%f\n", (float)1234.56-(float)4.57);
printf("%f\n", (double)1234.56-(double)4.57);
}
$ cc -o float float.c
$ ./float
1229.990112
1229.990000
In Lisp, floating point constants without exponent markers parse
according to *READ-DEFAULT-FLOAT-FORMAT*, whose initial value is
SINGLE-FLOAT. If you ensure that your floating point numbers are
doubles, either by explicitly writing them that way, or by altering
*READ-DEFAULT-FLOAT-FORMAT*, you'll get the results you're after:
CL-USER> (- 1234.56d0 4.57d0)
1229.99d0
CL-USER> (setf *read-default-float-format* 'double-float)
DOUBLE-FLOAT
CL-USER> (- 1234.56 4.57)
1229.99
Note that the *READ-DEFAULT-FLOAT-FORMAT* also controls how the
printer prints floating point numbers. For more information, see
http://www.lisp.org/HyperSpec/Body/var_stread-de_oat-formatst.html
--
RmK
> In Lisp, floating point constants without exponent markers parse
> according to *READ-DEFAULT-FLOAT-FORMAT*, whose initial value is
> SINGLE-FLOAT. If you ensure that your floating point numbers are
> doubles, either by explicitly writing them that way, or by altering
> *READ-DEFAULT-FLOAT-FORMAT*, you'll get the results you're after:
>
> CL-USER> (- 1234.56d0 4.57d0)
> 1229.99d0
> CL-USER> (setf *read-default-float-format* 'double-float)
> DOUBLE-FLOAT
> CL-USER> (- 1234.56 4.57)
> 1229.99
>
> Note that the *READ-DEFAULT-FLOAT-FORMAT* also controls how the
> printer prints floating point numbers. For more information, see
>
> http://www.lisp.org/HyperSpec/Body/var_stread-de_oat-formatst.html
Richard,
I think this post of yours is my missing link. I assumed lisp was
using doubles (as I always do), and I think this was leading to my
confusion. Your information about the default setting should get me
going back on track. Thanks for the useful bit of knowledge.
A few comments to the other posters in general as someone new to this
forum:
1. Thanks for taking the time to answer my question. Many of you went
to considerable effort and I appreciate it.
2. Yes, I'm sure this information is already out there somewhere in
some hyperspec, but after searching in vain for an hour, a forum like
this is a much better alternative than beating my head against a wall.
3. I never ceased to be amazed how (what I thought was) a simple
question leads off to all kinds of tangents.
Steve
On 31 Oct, 01:01, ···············@gmail.com wrote:
> > What would you expect as a result? Think about it.
>
> Well, I would expect 1229.99, wouldn't you? This is the result every
> other language I've used would return. (I just checked several to
> confirm -- C, Fortran, perl, R, APL). Even my free piece-of-junk
> solar calculator can get the "correct" answer. If this is a floating
> point nuance as you claim, and is the expected answer, then perhaps I
> need to reevalulate learning lisp -- it may not be suitable for my
> needs.
>
> (sorry if this is a repeat -- original reply seemed to get lost...)
Were you using doubles in the other languages?
CL-USER> (- 1234.56d0 4.57d0)
1229.99d0
In comparison:
#include "stdio.h"
main(){
float x=1234.56- 4.57;
printf ("%f",x);}
prints 1229.98990 on my laptop.
swl> Well, I would expect 1229.99, wouldn't you? This is the result every
swl> other language I've used would return. (I just checked several to
swl> confirm -- C, Fortran, perl, R, APL). Even my free piece-of-junk
swl> solar calculator can get the "correct" answer. If this is a floating
swl> point nuance as you claim, and is the expected answer, then perhaps I
swl> need to reevalulate learning lisp -- it may not be suitable for my
swl> needs.
you already got answer about difference between single and double precision.
what you should understand is that programming languages typically do not
implement FP arithmetics themselves -- typically they do it via CPU
instructions, that are same for all, and yield same results -- only
reading/printing routines might be different, but typically not that much.
From: Kamen TOMOV
Subject: Re: Floating point issue in sbcl 1.0.10?
Date:
Message-ID: <uy7dk6rg0.fsf@cybuild.com>
On Wed, Oct 31 2007, ···············@gmail.com wrote:
> As a lisp newbie, I'm sorry if this one is obvious. However, I'm a
> bit puzzled by the following executed from the prompt:
>
> * (- 1234.56 4.57)
>
> 1229.9901
Your question is ambiguous - are you asking about the floating point
precision or about multiplication not happening?
Rainer answered in the former question so I will answer the latter:
The following:
* (- 1234.56 4.57)
when written in the REPL:
1. Evaluates the variable *
2. Evaluates the provided FP form
3. Prints the result of the last form
If you want to do multiplication you should use the function * this
way:
(* (- 1234.56 4.57) 3)
The symbol * is a variable. You can learn about it here:
http://www.lisp.org/HyperSpec/Body/var_stcm_ststcm_ststst.html
--
�����
> Your question is ambiguous - are you asking about the floating point
> precision or about multiplication not happening?
Sorry about the confusion -- the asterisk was just the sbcl prompt,
not part of my expression. My question was about the "incorrect"
subtraction.
<···············@gmail.com> wrote in message
····························@d55g2000hsg.googlegroups.com...
>> Your question is ambiguous - are you asking about the floating point
>> precision or about multiplication not happening?
>
> Sorry about the confusion -- the asterisk was just the sbcl prompt,
> not part of my expression. My question was about the "incorrect"
> subtraction.
Why would any Lisp implementation use an asterisk as a prompt? The <*> already
has a special symbolic meaning in the REPL in addition to denoting the
multiplication operator and being part of the format directive ~*. Talk about
graphic overload.
Carl Taylor
On Oct 30, 6:05 pm, "Carl Taylor" <··········@att.net> wrote:
> Why would any Lisp implementation use an asterisk as a prompt?
Reasonable question, but this practice goes at least as far back as
Maclisp in the late 1970s, and could be much older than that for all I
know.
-- Scott
Scott Burson wrote:
> On Oct 30, 6:05 pm, "Carl Taylor" <··········@att.net> wrote:
>> Why would any Lisp implementation use an asterisk as a prompt?
>
> Reasonable question, but this practice goes at least as far back as
> Maclisp in the late 1970s, and could be much older than that for all I
> know.
I dunno; if the prompt is *, then (+ * ** ***) makes a whole lot more
sense to me than if the prompt was something else. Just count how
many prompts back you want...
- Daniel
···············@gmail.com writes:
> As a lisp newbie, I'm sorry if this one is obvious. However, I'm a
> bit puzzled by the
> following executed from the prompt:
>
> * (- 1234.56 4.57)
>
> 1229.9901
You may already know this, but if not (being a newbie): You can do
arithmetic using rationals in Common Lisp, if that fits your
application.
CL-USER 6 > (+ 1234 (/ 56 100))
30864/25
CL-USER 7 > (+ 4 (/ 57 100))
457/100
CL-USER 8 > (- ** *)
122999/100
CL-USER 9 > (floor **)
1229
99/100
On Oct 31, 3:07 am, ···············@gmail.com wrote:
Let's try it with other CL implementatins - I have a bunch of them
installed.
[2]> (lisp-implementation-type)
"CLISP"
[3]> (lisp-implementation-version)
"2.41 (2006-10-13) (built on ATGRZWN502840.avl01.avlcorp.lan
[127.0.0.1])"
[4]> *features*
(:READLINE :REGEXP :SYSCALLS :I18N :LOOP :COMPILER :CLOS :MOP :CLISP :ANSI-
CL :COMMON-LISP
:LISP=CL :INTERPRETER :SOCKETS :GENERIC-STREAMS :LOGICAL-
PATHNAMES :SCREEN :FFI :GETTEXT :UNICODE
:BASE-CHAR=CHARACTER :PC386 :UNIX :CYGWIN)
[5]> (- 1234.56 4.57)
1229.9901
* (lisp-implementation-type)
"SBCL"
* (lisp-implementation-version)
"1.0.9"
* *features*
(:ANSI-CL :COMMON-LISP :SBCL :UNIX :SB-DOC :SB-TEST :SB-LDB :SB-
PACKAGE-LOCKS
:SB-UNICODE :SB-EVAL :SB-SOURCE-LOCATIONS :IEEE-FLOATING-
POINT :X86 :WIN32
:GENCGC :STACK-GROWS-DOWNWARD-NOT-UPWARD :C-STACK-IS-CONTROL-STACK
:COMPARE-AND-SWAP-VOP :UNWIND-TO-FRAME-AND-CALL-VOP
:STACK-ALLOCATABLE-CLOSURES :ALIEN-CALLBACKS :LINKAGE-TABLE
:OS-PROVIDES-DLOPEN :OS-PROVIDES-PUTWC)
* (- 1234.56 4.57)
1229.9901
*
CL-USER(1): (lisp-implementation-type)
"Armed Bear Common Lisp"
CL-USER(2): (lisp-implementation-version)
"0.0.10"
CL-USER(3): *features*
(:X86 :JAVA-1.6 :ARMEDBEAR :ABCL :COMMON-LISP :ANSI-CL :WINDOWS)
CL-USER(4): (- 1234.56 4.57)
1229.9901
CL-USER(5):
CL-USER 12 > (lisp-implementation-type)
"LispWorks"
CL-USER 13 > (lisp-implementation-version)
"4.4.5"
CL-USER 14 > *features*
(:DBCS-ENV :COMPILE-REVERSE :BYTE-INSTRUCTIONS HARP::PC386 :COMMON-
LISPWORKS :COMMON-DEFSYSTEM :CAP
I-TOOLKIT :CAPI :LW-EDITOR :COMMON-FFI :NEW-PATCH-
SYSTEM :DBCS :UNICODE :WIN32 :IAPX386 :FLOAT :CLO
S :ANSI-CL :COMMON-
LISP :LATIN-1 :LISPWORKS :LISPWORKS4.4 :LISPWORKS4 :HARLEQUIN-COMMON-
LISP :HARLE
QUIN-PC-LISP :NEW-PC-COMPILER :COMPILER :REVERSE :LITTLE-ENDIAN :CLASS-
SHAKE-USING-GATES :SUPPORTS-
CONS-BLOCKS :IEEE-FLOATING-POINT :FLI-REGISTER-MODULE)
CL-USER 15 > (- 1234.56 4.57)
1229.99
In all implementaions *read-default-float-format* was SINGLE-FLOAT.
So at least this is not so SBCL-specific.
From: Joost Diepenmaat
Subject: Re: Floating point issue in sbcl 1.0.10?
Date:
Message-ID: <87k5n7vifn.fsf@zeekat.nl>
···············@gmail.com writes:
> As a lisp newbie, I'm sorry if this one is obvious. However, I'm a
> bit puzzled by the
> following executed from the prompt:
>
> * (- 1234.56 4.57)
>
> 1229.9901
>
> I tried this with several installations of this (ubuntu, compiled from
> src, and
> precompiled binary). Any ideas?
Floating point numbers aren't exact, they're binary approximations, and
binary approximations aren't exact for every number that's simple to
represent in decimal notation (and vice versa). This is a problem in all
languages that use finite binary representation for floats (which is more or
less all of them, at least by default). See:
http://www2.hursley.ibm.com/decimal/decifaq1.html#inexact
If you want exact results, you should use rational numbers. In most
situations you can get away with appropriate rounding.
HTH,
Joost.