From: Robert D. <rob...@gm...> - 2007-07-29 16:57:19
|
Hello, Considering (expt b x), it appears that expt returns something other than the x-fold 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.220446049250313d-16 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 Hanche-O. <ha...@ma...> - 2007-07-29 18:34:37
|
+ "Robert Dodier" <rob...@gm...>: | Considering (expt b x), it appears that expt returns something | other than the x-fold 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.220446049250313d-16 | | 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 x-fold 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.220446049250313d-16 - Harald |
From: Robert D. <rob...@gm...> - 2007-07-29 19:28:02
|
On 7/29/07, Harald Hanche-Olsen <ha...@ma...> wrote: > + "Robert Dodier" <rob...@gm...>: > > | Considering (expt b x), it appears that expt returns something > | other than the x-fold 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.220446049250313d-16 > | > | 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 R. <cs...@ca...> - 2007-07-29 19:39:56
|
"Robert Dodier" <rob...@gm...> 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 ill-specified 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 D. <rob...@gm...> - 2007-07-29 19:48:23
|
On 7/29/07, Christophe Rhodes <cs...@ca...> wrote: > I, personally, am not interested Good enough. I'll work around SBCL then. Not a big deal. Robert Dodier |
From: Nikodemus S. <nik...@ra...> - 2007-07-29 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 double-floats. (No comment on the FP accuracy issues here.) Cheers, -- Nikodemus |
From: Nathan F. <fr...@gm...> - 2007-07-30 12:11:21
|
On 7/29/07, Nikodemus Siivola <nik...@ra...> 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 double-floats. (No comment on the FP accuracy > issues here.) Surely the extra boxing and type-checking 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 |