Hi
The following generates an exception. 10.0 < -1100000000000000000000000000000000000000 This is because Integer implements #lessFromFloat: as ^aFloat < self asFloat and -1100000000000000000000000000000000000000 cannot be converted to a Float. However, an alternative implementation for large integer will work and executes faster, it is slower for small integer. ^aFloat floor < self Terry =========================================================== Terry Raymond Crafted Smalltalk 80 Lazywood Ln. Tiverton, RI 02878 (401) 624-4517 [hidden email] <http://www.craftedsmalltalk.com> =========================================================== _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
In a similar realm is:
Why don't fixed points implement sqrt? E.g. 3s100 sqrt => 1.73205 But if one implements (maybe it could be implemented more effectively but a simple Newton-Raphson could be implemented in a few minutes): FixedPoint>>sqrt "Answer the square root of the receiver." | xn xold lim | xn := super sqrt asFixedPoint: scale. xold := self. lim := (10 ** xn scale) reciprocal. [(xold - xn) abs > lim] whileTrue: [xold := xn. xn := (xn + (self / xn)) / 2]. ^xn the result is 1.7320508075688772935274463415058723669428052538103806280558069794519330169088000370811461867572485757s. And why not add FixedPoint class>>pi: numberOfDecimals ^(0 to: numberOfDecimals) inject: (0 asFixedPoint: numberOfDecimals) into: [:s :k | | p | p := 8 * k. s + ((4 / (p + 1) - (2 / (p + 4)) - (1 / (p + 5)) - (1 / (p + 6))) / (16 ** k))] Example: FixedPoint pi: 100 3.1415926535897932384626433832795028841971693993751058209749445923078164062862089986280348253421170680s I mean that it would be really nice if arithmetic and mathematical functions were improved a little and return expected results (as returning a fixed point when taking the square root of one). Especially since one could improve a lot by quite simple means, to a great extent thanks to the already present type hierarchy which enable simple improvements on an per type level. Cheers, Björn Extra: if you really want a multitude of decimals to pi try this: | k a b a1 b1 | k := 2. a := 4. b := 1. a1 := 12. b1 := 4. [true] whileTrue: [| p q d d1 a1Old b1Old | p := k * k. q := 2 * k + 1. k := k + 1. a1Old := a1. b1Old := b1. a1 := p * a + (q * a1). b1 := p * b + (q * b1). a := a1Old. b := b1Old. d := a // b. d1 := a1 // b1. [d == d1] whileTrue: [Transcript print: d. a := 10 * (a \\ b). a1 := 10 * (a1 \\ b1). d := a // b. d1 := a1 // b1]] On 2009-07-01 17:52, Terry Raymond wrote: > Hi > > The following generates an exception. > 10.0< -1100000000000000000000000000000000000000 > > This is because Integer implements #lessFromFloat: as > > ^aFloat< self asFloat > > and -1100000000000000000000000000000000000000 cannot be converted to a Float. > > However, an alternative implementation for large integer will work and executes faster, > it is slower for small integer. > > ^aFloat floor< self > > Terry > > =========================================================== > Terry Raymond > Crafted Smalltalk > 80 Lazywood Ln. > Tiverton, RI 02878 > (401) 624-4517 [hidden email] > <http://www.craftedsmalltalk.com> > =========================================================== > > > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Björn, you can probably reuse the integer implementation of sqrtFloor to implement FixedPoint>>sqrt. Something along the lines of...
FixedPoint>>sqrt sqrtValue := ("self integerValue" * (10 ** (self scale * 2))) sqrtFloor. "now sqrtValue has self integerValue sqrtFloor with self scale digit's worth of precision, so create the answer for that" See also Integer>>sqrtRounded for a simpler application of the same principle. Andres. -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of Björn Eiderbäck Sent: Wednesday, July 01, 2009 3:38 PM To: Raymond, Terry Cc: VWNC Subject: Re: [vwnc] Exception comparing LargeNegativeInteger to Float In a similar realm is: Why don't fixed points implement sqrt? E.g. 3s100 sqrt => 1.73205 But if one implements (maybe it could be implemented more effectively but a simple Newton-Raphson could be implemented in a few minutes): FixedPoint>>sqrt "Answer the square root of the receiver." | xn xold lim | xn := super sqrt asFixedPoint: scale. xold := self. lim := (10 ** xn scale) reciprocal. [(xold - xn) abs > lim] whileTrue: [xold := xn. xn := (xn + (self / xn)) / 2]. ^xn the result is 1.7320508075688772935274463415058723669428052538103806280558069794519330169088000370811461867572485757s. And why not add FixedPoint class>>pi: numberOfDecimals ^(0 to: numberOfDecimals) inject: (0 asFixedPoint: numberOfDecimals) into: [:s :k | | p | p := 8 * k. s + ((4 / (p + 1) - (2 / (p + 4)) - (1 / (p + 5)) - (1 / (p + 6))) / (16 ** k))] Example: FixedPoint pi: 100 3.1415926535897932384626433832795028841971693993751058209749445923078164062862089986280348253421170680s I mean that it would be really nice if arithmetic and mathematical functions were improved a little and return expected results (as returning a fixed point when taking the square root of one). Especially since one could improve a lot by quite simple means, to a great extent thanks to the already present type hierarchy which enable simple improvements on an per type level. Cheers, Björn Extra: if you really want a multitude of decimals to pi try this: | k a b a1 b1 | k := 2. a := 4. b := 1. a1 := 12. b1 := 4. [true] whileTrue: [| p q d d1 a1Old b1Old | p := k * k. q := 2 * k + 1. k := k + 1. a1Old := a1. b1Old := b1. a1 := p * a + (q * a1). b1 := p * b + (q * b1). a := a1Old. b := b1Old. d := a // b. d1 := a1 // b1. [d == d1] whileTrue: [Transcript print: d. a := 10 * (a \\ b). a1 := 10 * (a1 \\ b1). d := a // b. d1 := a1 // b1]] On 2009-07-01 17:52, Terry Raymond wrote: > Hi > > The following generates an exception. > 10.0< -1100000000000000000000000000000000000000 > > This is because Integer implements #lessFromFloat: as > > ^aFloat< self asFloat > > and -1100000000000000000000000000000000000000 cannot be converted to a Float. > > However, an alternative implementation for large integer will work and > executes faster, it is slower for small integer. > > ^aFloat floor< self > > Terry > > =========================================================== > Terry Raymond > Crafted Smalltalk > 80 Lazywood Ln. > Tiverton, RI 02878 > (401) 624-4517 [hidden email] > <http://www.craftedsmalltalk.com> > =========================================================== > > > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
In reply to this post by Terry Raymond
You might abuse the fact that floats cannot possibly represent anything
over 2^{Float emax + 1} - 1. Hence, if the integer has 128 bits, you know it cannot be represented as a float... I'll take a quick look at this. You can also skip the check completely for SmallInteger because even on 64 bits, all small integers can be converted to a float. -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of Terry Raymond Sent: Wednesday, July 01, 2009 8:52 AM To: VWNC Subject: [vwnc] Exception comparing LargeNegativeInteger to Float Hi The following generates an exception. 10.0 < -1100000000000000000000000000000000000000 This is because Integer implements #lessFromFloat: as ^aFloat < self asFloat and -1100000000000000000000000000000000000000 cannot be converted to a Float. However, an alternative implementation for large integer will work and executes faster, it is slower for small integer. ^aFloat floor < self Terry =========================================================== Terry Raymond Crafted Smalltalk 80 Lazywood Ln. Tiverton, RI 02878 (401) 624-4517 [hidden email] <http://www.craftedsmalltalk.com> =========================================================== _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Andres
The issue is that you cannot compare two numbers because of their representations. Additionally, an inequality comparison does not have to use generality. It just seems to me that converting a float to an integer and doing an integer comparison is just as valid as converting an integer to a float and doing the comparison, except we know we can always convert a float to the proper integer to do the comparison. Terry =========================================================== Terry Raymond Crafted Smalltalk 80 Lazywood Ln. Tiverton, RI 02878 (401) 624-4517 [hidden email] <http://www.craftedsmalltalk.com> =========================================================== > -----Original Message----- > From: [hidden email] [mailto:[hidden email]] On Behalf Of Valloud, Andres > Sent: Wednesday, July 01, 2009 8:20 PM > To: VWNC > Subject: Re: [vwnc] Exception comparing LargeNegativeInteger to Float > > You might abuse the fact that floats cannot possibly represent anything > over 2^{Float emax + 1} - 1. Hence, if the integer has 128 bits, you > know it cannot be represented as a float... I'll take a quick look at > this. You can also skip the check completely for SmallInteger because > even on 64 bits, all small integers can be converted to a float. > > -----Original Message----- > From: [hidden email] [mailto:[hidden email]] On > Behalf Of Terry Raymond > Sent: Wednesday, July 01, 2009 8:52 AM > To: VWNC > Subject: [vwnc] Exception comparing LargeNegativeInteger to Float > > Hi > > The following generates an exception. > 10.0 < -1100000000000000000000000000000000000000 > > This is because Integer implements #lessFromFloat: as > > ^aFloat < self asFloat > > and -1100000000000000000000000000000000000000 cannot be converted to a > Float. > > However, an alternative implementation for large integer will work and > executes faster, it is slower for small integer. > > ^aFloat floor < self > > Terry > > =========================================================== > Terry Raymond > Crafted Smalltalk > 80 Lazywood Ln. > Tiverton, RI 02878 > (401) 624-4517 [hidden email] > <http://www.craftedsmalltalk.com> > =========================================================== > > > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
However, converting a large floating point number to an integer can be
particularly onerous (e.g.: 1.0d timesTwoPower: 1000). In comparison, just checking aLargeInteger highBit is significantly less expensive for the cases in which the comparison couldn't possibly answer two different values. I am not sure it's worth it for the few cases in which there would be savings... I'd have to check and see what approach is more efficient. -----Original Message----- From: Terry Raymond [mailto:[hidden email]] Sent: Wednesday, July 01, 2009 7:17 PM To: Valloud, Andres; 'VWNC' Subject: RE: [vwnc] Exception comparing LargeNegativeInteger to Float Andres The issue is that you cannot compare two numbers because of their representations. Additionally, an inequality comparison does not have to use generality. It just seems to me that converting a float to an integer and doing an integer comparison is just as valid as converting an integer to a float and doing the comparison, except we know we can always convert a float to the proper integer to do the comparison. Terry =========================================================== Terry Raymond Crafted Smalltalk 80 Lazywood Ln. Tiverton, RI 02878 (401) 624-4517 [hidden email] <http://www.craftedsmalltalk.com> =========================================================== > -----Original Message----- > From: [hidden email] [mailto:[hidden email]] On > Behalf Of Valloud, Andres > Sent: Wednesday, July 01, 2009 8:20 PM > To: VWNC > Subject: Re: [vwnc] Exception comparing LargeNegativeInteger to Float > > You might abuse the fact that floats cannot possibly represent > anything over 2^{Float emax + 1} - 1. Hence, if the integer has 128 > bits, you know it cannot be represented as a float... I'll take a > quick look at this. You can also skip the check completely for > SmallInteger because even on 64 bits, all small integers can be > > -----Original Message----- > From: [hidden email] [mailto:[hidden email]] On > Behalf Of Terry Raymond > Sent: Wednesday, July 01, 2009 8:52 AM > To: VWNC > Subject: [vwnc] Exception comparing LargeNegativeInteger to Float > > Hi > > The following generates an exception. > 10.0 < -1100000000000000000000000000000000000000 > > This is because Integer implements #lessFromFloat: as > > ^aFloat < self asFloat > > and -1100000000000000000000000000000000000000 cannot be converted to a > Float. > > However, an alternative implementation for large integer will work and > executes faster, it is slower for small integer. > > ^aFloat floor < self > > Terry > > =========================================================== > Terry Raymond > Crafted Smalltalk > 80 Lazywood Ln. > Tiverton, RI 02878 > (401) 624-4517 [hidden email] > <http://www.craftedsmalltalk.com> > =========================================================== > > > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Valloud, Andres <avalloud <at> cincom.com> writes: > > However, converting a large floating point number to an integer can be > particularly onerous (e.g.: 1.0d timesTwoPower: 1000). In comparison, > just checking aLargeInteger highBit is significantly less expensive for > the cases in which the comparison couldn't possibly answer two different > values. I am not sure it's worth it for the few cases in which there > would be savings... I'd have to check and see what approach is more > efficient. > Andres, that's http://www.cincomsmalltalk.com/publicRepository/SYSBUG-FloatComparison.html and http://bugs.squeak.org/view.php?id=3374 My (costly) proposition is to convert Float as an exact Fraction. With double dispatching, it would be very easy to implement a fast sign check, then a hightBit check before engaging costly arithmetic, if that matters. It's only an optimization. My own order relationship tells: do it right > do it fast. Nicolas _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
In reply to this post by Andres Valloud-6
(x truncated * (10 ** (x scale * 2))) sqrtFloor gives a LargePositiveInteger
where x is a FixedPoint and it doesn't handle fixed points as 3.5s100 properly since it truncates the number. However the the solution below is (at least in my small tests) faster than my previous solution: FiexdPoint>>sqrt | xn xold lim | xn := self sqrtFloor asFixedPoint: scale. xold := self. lim := (10 ** xn scale) reciprocal. [(xold - xn) abs > lim] whileTrue: [xold := xn. xn := (xn + (self / xn)) / 2]. ^xn But I have not given this particular problem any serious thoughts. However it would be nice if arithmetic operations return "the expected type". //Björn On Thu, Jul 2, 2009 at 2:15 AM, Valloud, Andres <[hidden email]> wrote: Björn, you can probably reuse the integer implementation of sqrtFloor to implement FixedPoint>>sqrt. Something along the lines of... _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
In reply to this post by Andres Valloud-6
AR 58887.
-----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of Valloud, Andres Sent: Wednesday, July 01, 2009 10:26 PM To: VWNC Subject: Re: [vwnc] Exception comparing LargeNegativeInteger to Float However, converting a large floating point number to an integer can be particularly onerous (e.g.: 1.0d timesTwoPower: 1000). In comparison, just checking aLargeInteger highBit is significantly less expensive for the cases in which the comparison couldn't possibly answer two different values. I am not sure it's worth it for the few cases in which there would be savings... I'd have to check and see what approach is more efficient. -----Original Message----- From: Terry Raymond [mailto:[hidden email]] Sent: Wednesday, July 01, 2009 7:17 PM To: Valloud, Andres; 'VWNC' Subject: RE: [vwnc] Exception comparing LargeNegativeInteger to Float Andres The issue is that you cannot compare two numbers because of their representations. Additionally, an inequality comparison does not have to use generality. It just seems to me that converting a float to an integer and doing an integer comparison is just as valid as converting an integer to a float and doing the comparison, except we know we can always convert a float to the proper integer to do the comparison. Terry =========================================================== Terry Raymond Crafted Smalltalk 80 Lazywood Ln. Tiverton, RI 02878 (401) 624-4517 [hidden email] <http://www.craftedsmalltalk.com> =========================================================== > -----Original Message----- > From: [hidden email] [mailto:[hidden email]] On > Behalf Of Valloud, Andres > Sent: Wednesday, July 01, 2009 8:20 PM > To: VWNC > Subject: Re: [vwnc] Exception comparing LargeNegativeInteger to Float > > You might abuse the fact that floats cannot possibly represent > anything over 2^{Float emax + 1} - 1. Hence, if the integer has 128 > bits, you know it cannot be represented as a float... I'll take a > quick look at this. You can also skip the check completely for > SmallInteger because even on 64 bits, all small integers can be > > -----Original Message----- > From: [hidden email] [mailto:[hidden email]] On > Behalf Of Terry Raymond > Sent: Wednesday, July 01, 2009 8:52 AM > To: VWNC > Subject: [vwnc] Exception comparing LargeNegativeInteger to Float > > Hi > > The following generates an exception. > 10.0 < -1100000000000000000000000000000000000000 > > This is because Integer implements #lessFromFloat: as > > ^aFloat < self asFloat > > and -1100000000000000000000000000000000000000 cannot be converted to a > Float. > > However, an alternative implementation for large integer will work and > executes faster, it is slower for small integer. > > ^aFloat floor < self > > Terry > > =========================================================== > Terry Raymond > Crafted Smalltalk > 80 Lazywood Ln. > Tiverton, RI 02878 > (401) 624-4517 [hidden email] > <http://www.craftedsmalltalk.com> > =========================================================== > > > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Valloud, Andres wrote:
> -----Original Message----- > From: Terry Raymond [mailto:[hidden email]] > Sent: Wednesday, July 01, 2009 7:17 PM > To: Valloud, Andres; 'VWNC' > Subject: RE: [vwnc] Exception comparing LargeNegativeInteger to Float > > Andres > > The issue is that you cannot compare two numbers because of their > representations. Additionally, an inequality comparison does not have to > use generality. It just seems to me that converting a float to an > integer and doing an integer comparison is just as valid as converting > an integer to a float and doing the comparison, except we know we can > always convert a float to the proper integer to do the comparison. The ANSI standard is very clear on this point, it says you *do* have to use generality for both equality and inequality numeric comparisons, and specifically that you must convert the integer to a float before comparing an integer and a float. And in my opinion the ANSI committee made the right choice here. However, comparisons of floats with integers that are outside the float range should give correct answers, not fail. Regards, -Martin _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Martin McClure wrote:
> > However, comparisons of floats with integers that are outside the float > range should give correct answers, not fail. I was curious how GemStone handled this. It turns out our code is very similar; something like "self < aNumber asFloat". But in GemStone this works, because for negative integers of very large magnitude "aNumber asFloat" answers the Float -infinity, which compares correctly. I know that in VW VM-level support for infs and NaNs was added a few years back; if you complete the image-level support some of these problems just go away. Regards, -Martin _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
That is a good observation. However, right now we have the constraint
that the image has to work with both regular primitives that fail before answering INF and NaN, and the IEEE primitives that will answer INF and NaN. So, for the time being, the solution to this problem for integers is a highBit check to ensure the conversion to floating point values can be made. -----Original Message----- From: Martin McClure [mailto:[hidden email]] Sent: Friday, December 18, 2009 12:18 PM To: Valloud, Andres Cc: [hidden email] Subject: Re: [vwnc] Exception comparing LargeNegativeInteger to Float Martin McClure wrote: > > However, comparisons of floats with integers that are outside the > float range should give correct answers, not fail. I was curious how GemStone handled this. It turns out our code is very similar; something like "self < aNumber asFloat". But in GemStone this works, because for negative integers of very large magnitude "aNumber asFloat" answers the Float -infinity, which compares correctly. I know that in VW VM-level support for infs and NaNs was added a few years back; if you complete the image-level support some of these problems just go away. Regards, -Martin _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Free forum by Nabble | Edit this page |