Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo
Close
From: Robert Dodier <robert.dodier@gm...>  20070729 16:57:19

Hello, Considering (expt b x), it appears that expt returns something other than the xfold product of b, even if x is a small integer. Seems to return (exp (* x (log b))) instead, which is OK, I guess, but has the potential to be slightly surprising. E.g. this is what SBCL 1.0 on Linux yields. (let ((a 1.1234567890123456d0)) ( (expt a 5) (* a a a a a))) => 2.220446049250313d16 For comparison, Clisp 2.38, GCL 2.6.7, and Allegro Express 8.0 all return 0.0d0 here. Has expt equivalent to repeated product been considered? Maybe this is ancient history, but I wasn't able to find anything. Thanks for any light you can shed on this. Robert Dodier 
From: Harald HancheOlsen <hanche@ma...>  20070729 18:34:37

+ "Robert Dodier" <robert.dodier@...>:  Considering (expt b x), it appears that expt returns something  other than the xfold product of b, even if x is a small integer.  Seems to return (exp (* x (log b))) instead, which is OK, I guess,  but has the potential to be slightly surprising. Emphasis on slightly here, please.  E.g. this is what SBCL 1.0 on Linux yields.   (let ((a 1.1234567890123456d0)) ( (expt a 5) (* a a a a a)))  => 2.220446049250313d16   For comparison, Clisp 2.38, GCL 2.6.7, and Allegro Express 8.0  all return 0.0d0 here. Why should this be a requirement? Consider the fact that "the xfold product" is hardly a well defined concept, given that * is not associative over floating point numbers: (let* ((a 1.12345678901234d0) (aa (* a a))) ( (* aa aa a) (* a a a a a))) => 2.220446049250313d16  Harald 
From: Robert Dodier <robert.dodier@gm...>  20070729 19:28:02

On 7/29/07, Harald HancheOlsen <hanche@...> wrote: > + "Robert Dodier" <robert.dodier@...>: > >  Considering (expt b x), it appears that expt returns something >  other than the xfold product of b, even if x is a small integer. >  Seems to return (exp (* x (log b))) instead, which is OK, I guess, >  but has the potential to be slightly surprising. > > Emphasis on slightly here, please. What I meant to say was "intensely frustrating". >  E.g. this is what SBCL 1.0 on Linux yields. >  >  (let ((a 1.1234567890123456d0)) ( (expt a 5) (* a a a a a))) >  => 2.220446049250313d16 >  >  For comparison, Clisp 2.38, GCL 2.6.7, and Allegro Express 8.0 >  all return 0.0d0 here. > > Why should this be a requirement? Well, I don't pretend that it could be a requirement. But as a practical matter it seems easier to convince SBCL to behave like some other Lisp implementations, rather than getting the others to behave like SBCL. My own selfish goal here is to patch some numerical code (Maxima) so that it acts the same with different underlying Lisp implementations. As that seems like a useful goal in general, perhaps you'll be interested to further it, perhaps not. I'm writing today just to gauge the interest of the SBCL developers. best Robert Dodier 
From: Christophe Rhodes <csr21@ca...>  20070729 19:39:56

"Robert Dodier" <robert.dodier@...> writes: > I'm writing today just to gauge the interest of the SBCL developers. I, personally, am not interested in twisting the implementation of floating point arithmetic to meet one illspecified and vague notion of what the right answer might be. If you can specify exactly what the behaviour you desire is in all circumstances  not just "do like FooCL", but actual robust descriptions, accumulate a good suite of conformance tests for your specification, and provide a reference implementation, then we can probably discuss whether your particular specification is unambiguously good or whether there is scope for other applications having different needs. Of course, if you do that, then you will also have what you require to insulate yourself not just from SBCL's current idiosyncracies, but also from any other lisp's interpretation of floating point, past, present, or future. It's more work than just saying that something is "intensely frustrating", but it's also what you seem to need. Cheers, Christophe 
From: Robert Dodier <robert.dodier@gm...>  20070729 19:48:23

On 7/29/07, Christophe Rhodes <csr21@...> wrote: > I, personally, am not interested Good enough. I'll work around SBCL then. Not a big deal. Robert Dodier 
From: Nikodemus Siivola <nikodemus@ra...>  20070729 20:40:16

I was going to say something about the payoff of what SBCL does as an optimization, but it turns out that's not the case: on my box inlining repeated multiplication is faster then an EXPT call up to (EXPT X 60) or so for doublefloats. (No comment on the FP accuracy issues here.) Cheers,  Nikodemus 
From: Nathan Froyd <froydnj@gm...>  20070730 12:11:21

On 7/29/07, Nikodemus Siivola <nikodemus@...> wrote: > I was going to say something about the payoff of what SBCL does as > an optimization, but it turns out that's not the case: on my box > inlining repeated multiplication is faster then an EXPT call up to > (EXPT X 60) or so for doublefloats. (No comment on the FP accuracy > issues here.) Surely the extra boxing and typechecking has something to do with this measurement, as the inlined version compiles down to straight machine multiplies, whereas (EXPT X 60) has a bit more work to do...? Nathan 