I've been playing around with the Mandelbrot set and I noticed that the implementation using Float looked somewhat vague. After researching a while, it turns out (corrections welcome) that while Float performs 64-bit FP calculations, only a limited number of decimal places are stored for subsequent calculations. Is there a way around this?
I can work up a "fixed" point Complex number simply by writing over the internal ScaledDecimal representation using using z real: (z real) asString , but this is rather a lot of overhead and for precision less than 15ish decimal places, it would be nice to use hardware.
Any relatively easy way to do this (store native precision floating point)?
is there a faster way to truncate a ScaledDecimal than the above?
Lawson
On Mon, 26 Apr 2010, Lawson English wrote:
I've been playing around with the Mandelbrot set and I noticed that the implementation using Float looked somewhat vague. After researching a while, it turns out (corrections welcome) that while Float performs 64-bit FP calculations, only a limited number of decimal places are stored for subsequent calculations. Is there a way around this?
That's not true, every Float stores 64 bits. Just because some digits are not shown in the printString, it doesn't mean they aren't there:
1.01 printString. "==> '1.01'" 1.01 printShowingDecimalPlaces: 60. "==> '1.010000000000000008881784197001252323389053344726562500000000'"
I can work up a "fixed" point Complex number simply by writing over the internal ScaledDecimal representation using using z real: (z real) asString , but this is rather a lot of overhead and for precision less than 15ish decimal places, it would be nice to use hardware.
Any relatively easy way to do this (store native precision floating point)?
It's done, see above.
is there a faster way to truncate a ScaledDecimal than the above?
Sure, don't convert it to strings. :) I think you shouldn't use ScaledDecimal at all, since it's just a combination of a fraction and scale. You only need the fraction. Use #truncateTo: to truncate a number.
Levente
Lawson
Levente Uzonyi wrote:
On Mon, 26 Apr 2010, Lawson English wrote:
I've been playing around with the Mandelbrot set and I noticed that the implementation using Float looked somewhat vague. After researching a while, it turns out (corrections welcome) that while Float performs 64-bit FP calculations, only a limited number of decimal places are stored for subsequent calculations. Is there a way around this?
That's not true, every Float stores 64 bits. Just because some digits are not shown in the printString, it doesn't mean they aren't there:
1.01 printString. "==> '1.01'" 1.01 printShowingDecimalPlaces: 60. "==> '1.010000000000000008881784197001252323389053344726562500000000'"
I'm not sure what this means:
1.4142135623730950488016887242096980785696718753769480 printShowingDecimalPlaces: 60 '1.414213562373095145474621858738828450441360473632812500000000'
is there a faster way to truncate a ScaledDecimal than the above?
Sure, don't convert it to strings. :) I think you shouldn't use ScaledDecimal at all, since it's just a combination of a fraction and scale. You only need the fraction. Use #truncateTo: to truncate a number.
Still confused, sorry.
Even with 15 decimal places, a Float-based M set generator is going to be inaccurate after a few levels of zoom. Fractions don't truncate the way I need them to.
Lawson
On Mon, 26 Apr 2010, Lawson English wrote:
Levente Uzonyi wrote:
On Mon, 26 Apr 2010, Lawson English wrote:
I've been playing around with the Mandelbrot set and I noticed that the implementation using Float looked somewhat vague. After researching a while, it turns out (corrections welcome) that while Float performs 64-bit FP calculations, only a limited number of decimal places are stored for subsequent calculations. Is there a way around this?
That's not true, every Float stores 64 bits. Just because some digits are not shown in the printString, it doesn't mean they aren't there:
1.01 printString. "==> '1.01'" 1.01 printShowingDecimalPlaces: 60. "==> '1.010000000000000008881784197001252323389053344726562500000000'"
I'm not sure what this means:
1.4142135623730950488016887242096980785696718753769480 printShowingDecimalPlaces: 60 '1.414213562373095145474621858738828450441360473632812500000000'
It means that your number cannot be represented accurately as a Float. Details here: http://en.wikipedia.org/wiki/Floating_point#Representable_numbers.2C_convers...
is there a faster way to truncate a ScaledDecimal than the above?
Sure, don't convert it to strings. :) I think you shouldn't use ScaledDecimal at all, since it's just a combination of a fraction and scale. You only need the fraction. Use #truncateTo: to truncate a number.
Still confused, sorry.
Even with 15 decimal places, a Float-based M set generator is going to be inaccurate after a few levels of zoom. Fractions don't truncate the way I need them to.
How would you like them to truncate?
Levente
Lawson
Levente Uzonyi wrote:
On Mon, 26 Apr 2010, Lawson English wrote:
Levente Uzonyi wrote:
On Mon, 26 Apr 2010, Lawson English wrote:
I've been playing around with the Mandelbrot set and I noticed that the implementation using Float looked somewhat vague. After researching a while, it turns out (corrections welcome) that while Float performs 64-bit FP calculations, only a limited number of decimal places are stored for subsequent calculations. Is there a way around this?
That's not true, every Float stores 64 bits. Just because some digits are not shown in the printString, it doesn't mean they aren't there:
1.01 printString. "==> '1.01'" 1.01 printShowingDecimalPlaces: 60. "==> '1.010000000000000008881784197001252323389053344726562500000000'"
I'm not sure what this means:
1.4142135623730950488016887242096980785696718753769480 printShowingDecimalPlaces: 60 '1.414213562373095145474621858738828450441360473632812500000000'
It means that your number cannot be represented accurately as a Float. Details here: http://en.wikipedia.org/wiki/Floating_point#Representable_numbers.2C_convers...
is there a faster way to truncate a ScaledDecimal than the above?
Sure, don't convert it to strings. :) I think you shouldn't use ScaledDecimal at all, since it's just a combination of a fraction and scale. You only need the fraction. Use #truncateTo: to truncate a number.
Still confused, sorry.
Even with 15 decimal places, a Float-based M set generator is going to be inaccurate after a few levels of zoom. Fractions don't truncate the way I need them to.
How would you like them to truncate?
Levente
a := (14142135623730950488016887242096980785696718753769480 /10000000000000000000000000000000000000000000000000000) asScaledDecimal.
a asFloat ==>1.414213562373095.
b:=a * a. b asScaledDecimal ==> 1.999999999999999999999999999999999999999999999999999.
"b asFraction ==> (124999999999999999999999999999999999999999999999999987064068383137630325081727067987961060813568112169 /62500000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000) "
"The number is stored as a Fraction and all calculations are done on the Fraction."
b := ScaledDecimal newFromNumber: b scale: 51. "b ==> 1.999999999999999999999999999999999999999999999999999s51" "b asFraction ==> (124999999999999999999999999999999999999999999999999987064068383137630325081727067987961060813568112169 /62500000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000)"
b := ScaledDecimal readFrom: b asString. "b ==> 1.999999999999999999999999999999999999999900000000000s51" "b asFraction ==> (19999999999999999999999999999999999999999 /10000000000000000000000000000000000000000)"
So for the M set generator, since I break out of the loop if things get above 2, the calculations are accurate up to 51 decimals (in this case) when I do the last operation above and I don't grow my fraction to 50,000 bytes or whatever.
Its slower than I would like, of course.
Lawson
On Mon, 26 Apr 2010, Lawson English wrote:
Levente Uzonyi wrote:
On Mon, 26 Apr 2010, Lawson English wrote:
Levente Uzonyi wrote:
On Mon, 26 Apr 2010, Lawson English wrote:
I've been playing around with the Mandelbrot set and I noticed that the implementation using Float looked somewhat vague. After researching a while, it turns out (corrections welcome) that while Float performs 64-bit FP calculations, only a limited number of decimal places are stored for subsequent calculations. Is there a way around this?
That's not true, every Float stores 64 bits. Just because some digits are not shown in the printString, it doesn't mean they aren't there:
1.01 printString. "==> '1.01'" 1.01 printShowingDecimalPlaces: 60. "==> '1.010000000000000008881784197001252323389053344726562500000000'"
I'm not sure what this means:
1.4142135623730950488016887242096980785696718753769480 printShowingDecimalPlaces: 60 '1.414213562373095145474621858738828450441360473632812500000000'
It means that your number cannot be represented accurately as a Float. Details here: http://en.wikipedia.org/wiki/Floating_point#Representable_numbers.2C_convers...
is there a faster way to truncate a ScaledDecimal than the above?
Sure, don't convert it to strings. :) I think you shouldn't use ScaledDecimal at all, since it's just a combination of a fraction and scale. You only need the fraction. Use #truncateTo: to truncate a number.
Still confused, sorry.
Even with 15 decimal places, a Float-based M set generator is going to be inaccurate after a few levels of zoom. Fractions don't truncate the way I need them to.
How would you like them to truncate?
Levente
a := (14142135623730950488016887242096980785696718753769480 /10000000000000000000000000000000000000000000000000000) asScaledDecimal.
a asFloat ==>1.414213562373095.
b:=a * a. b asScaledDecimal ==> 1.999999999999999999999999999999999999999999999999999.
"b asFraction ==> (124999999999999999999999999999999999999999999999999987064068383137630325081727067987961060813568112169 /62500000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000) "
"The number is stored as a Fraction and all calculations are done on the Fraction."
b := ScaledDecimal newFromNumber: b scale: 51. "b ==> 1.999999999999999999999999999999999999999999999999999s51" "b asFraction ==> (124999999999999999999999999999999999999999999999999987064068383137630325081727067987961060813568112169 /62500000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000)"
b := ScaledDecimal readFrom: b asString. "b ==> 1.999999999999999999999999999999999999999900000000000s51" "b asFraction ==> (19999999999999999999999999999999999999999 /10000000000000000000000000000000000000000)"
I still don't get it. Why do you convert the number to a String? The following method is ~20x faster:
a := 124999999999999999999999999999999999999999999999999987064068383137630325081727067987961060813568112169 / 62500000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000. b := 10e-50. a truncateTo: b "===> (199999999999999999999999999999999999999999999999999/100000000000000000000000000000000000000000000000000)"
Levente
So for the M set generator, since I break out of the loop if things get above 2, the calculations are accurate up to 51 decimals (in this case) when I do the last operation above and I don't grow my fraction to 50,000 bytes or whatever.
Its slower than I would like, of course.
Lawson
Levente Uzonyi wrote:
I still don't get it. Why do you convert the number to a String? The following method is ~20x faster:
a := 124999999999999999999999999999999999999999999999999987064068383137630325081727067987961060813568112169 / 62500000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000.
b := 10e-50. a truncateTo: b "===> (199999999999999999999999999999999999999999999999999/100000000000000000000000000000000000000000000000000)"
Thanks very much.
Lawson
That's not true, every Float stores 64 bits.
Hi Levente, it does? Does that mean that (Float fromIEEE32Bit: myFloat asIEEE32BitWord) loses information? What would be a more precise method of serialization then?
Just because some digits are not shown in the printString, it doesn't mean they aren't there:
1.01 printString. "==> '1.01'" 1.01 printShowingDecimalPlaces: 60. "==> '1.010000000000000008881784197001252323389053344726562500000000'"
I can work up a "fixed" point Complex number simply by writing over the internal ScaledDecimal representation using using z real: (z real) asString , but this is rather a lot of overhead and for precision less than 15ish decimal places, it would be nice to use hardware.
Any relatively easy way to do this (store native precision floating point)?
It's done, see above.
is there a faster way to truncate a ScaledDecimal than the above?
Sure, don't convert it to strings. :) I think you shouldn't use ScaledDecimal at all, since it's just a combination of a fraction and scale. You only need the fraction. Use #truncateTo: to truncate a number.
Levente
Lawson
2010/4/26 Chris Muller asqueaker@gmail.com:
That's not true, every Float stores 64 bits.
Hi Levente, it does? Does that mean that (Float fromIEEE32Bit: myFloat asIEEE32BitWord) loses information? What would be a more precise method of serialization then?
Float are 64 bits (double precision) FloatArray use 32 bits (single precision)
Nicolas
Just because some digits are not shown in the printString, it doesn't mean they aren't there:
1.01 printString. "==> '1.01'" 1.01 printShowingDecimalPlaces: 60. "==> '1.010000000000000008881784197001252323389053344726562500000000'"
I can work up a "fixed" point Complex number simply by writing over the internal ScaledDecimal representation using using z real: (z real) asString , but this is rather a lot of overhead and for precision less than 15ish decimal places, it would be nice to use hardware.
Any relatively easy way to do this (store native precision floating point)?
It's done, see above.
is there a faster way to truncate a ScaledDecimal than the above?
Sure, don't convert it to strings. :) I think you shouldn't use ScaledDecimal at all, since it's just a combination of a fraction and scale. You only need the fraction. Use #truncateTo: to truncate a number.
Levente
Lawson
"Chris" == Chris Muller asqueaker@gmail.com writes:
Chris> Hi Levente, it does? Does that mean that (Float fromIEEE32Bit: Chris> myFloat asIEEE32BitWord) loses information? What would be a more Chris> precise method of serialization then?
You know, if you aren't going to pay attention to what I was saying in the #squeak channel, why were you even asking.
I *said* this to you. I said "looks like Float is 64 bit, and FloatArray is 32..Maybe mandel is storing things in FloatArray and that's where you're getting your truncation from, and if so one way out of that would be to use real Array instead of FloatArray"
I'm slightly tweaked that you ignored that, and you're now at the same place two days later.
I also told you that Mandel is always a myth, because the point at which the powers exceed 2 depends very much (butterfly effect-ish) on the precision of the representation. A version with 48-bit mantissas will look different than one with 24-bit mantissas, and different again from one with 100-bit mantissas.
Randal L. Schwartz wrote:
"Chris" == Chris Muller asqueaker@gmail.com writes:
Chris> Hi Levente, it does? Does that mean that (Float fromIEEE32Bit: Chris> myFloat asIEEE32BitWord) loses information? What would be a more Chris> precise method of serialization then?
You know, if you aren't going to pay attention to what I was saying in the #squeak channel, why were you even asking.
I *said* this to you. I said "looks like Float is 64 bit, and FloatArray is 32..Maybe mandel is storing things in FloatArray and that's where you're getting your truncation from, and if so one way out of that would be to use real Array instead of FloatArray"
I'm slightly tweaked that you ignored that, and you're now at the same place two days later.
I also told you that Mandel is always a myth, because the point at which the powers exceed 2 depends very much (butterfly effect-ish) on the precision of the representation. A version with 48-bit mantissas will look different than one with 24-bit mantissas, and different again from one with 100-bit mantissas.
I think that you meant to direct that at me...
/me looks sheepish.
Lawson
On 4/26/10, Lawson English lenglish5@cox.net wrote:
Randal L. Schwartz wrote: I think that you meant to direct that at me...
/me looks sheepish.
Lawson
Please don't worry, just go ahead and work on a nice Mandelbrot morph. We need something like that for screenshots of Squeak.
Then Ian pointed out that we need a good screen shot and referred to an example on his blog (which actually shows that the current situation needs improvement ASAP)
http://mecenia.blogspot.com/2010/04/history-of-squeak-in-pictures.html
--Hannes
Hannes Hirzel wrote:
On 4/26/10, Lawson English lenglish5@cox.net wrote:
Randal L. Schwartz wrote: I think that you meant to direct that at me...
/me looks sheepish.
Lawson
Please don't worry, just go ahead and work on a nice Mandelbrot morph. We need something like that for screenshots of Squeak.
Then Ian pointed out that we need a good screen shot and referred to an example on his blog (which actually shows that the current situation needs improvement ASAP)
http://mecenia.blogspot.com/2010/04/history-of-squeak-in-pictures.html
--Hannes
Levente has already done one. I'm trying to figure out how his works with an eye to make one that is etoy-enabled as a prelude to a "simple" [SIC] OGLMorph etoy thingie
http://squeaksource.com/MandelMorph2.html
Lawson
Lawson English wrote:
Hannes Hirzel wrote:
On 4/26/10, Lawson English lenglish5@cox.net wrote:
Randal L. Schwartz wrote: I think that you meant to direct that at me...
/me looks sheepish.
Lawson
Please don't worry, just go ahead and work on a nice Mandelbrot morph. We need something like that for screenshots of Squeak.
Then Ian pointed out that we need a good screen shot and referred to an example on his blog (which actually shows that the current situation needs improvement ASAP)
http://mecenia.blogspot.com/2010/04/history-of-squeak-in-pictures.html
--Hannes
Levente has already done one. I'm trying to figure out how his works with an eye to make one that is etoy-enabled as a prelude to a "simple" [SIC] OGLMorph etoy thingie
http://squeaksource.com/MandelMorph2.html
Lawson
ah, that was Bob Arnings, as repackaged by Torsten Bergmann.
:-)
Lawson
All this talk of Mandelbrot sets prompted me to write a Julia Set morph using my OpenCL framework. Here's how to try it out in a 4.1 image...
First, load the code:
Installer squeak project: 'FFI'; install: 'FFI-Pools'; install: 'FFI-Kernel'. Installer ss project: 'OpenCL'; install: 'OpenCL'.
Once the code has loaded, evaluate: OpenCLJuliaSetMorph new openInHand
You can move through the parameter-space by changing the "real" and "imaginary" components. These are exposed to eToys. I recommend hooking them up to a JoystickMorph. I've attached a screen-shot of the script that I use. The division by 40 is so that I can resize the JoystickMorph to be larger, and thereby move more precisely through the parameter space.
This has been tested on 2 machines: a Win7 box with Nvidia 8800GTS and the latest drivers, and a MacBook Pro with 8600GT running OSX 10.6. Your mileage may vary. If it does, I'd like to hear about it.
BTW, the performance would be much higher if I displayed it using OpenGL instead of reading back into a Squeak Form and displaying using BitBlt. My laptop GPU does the computation (including readback) for a 512x512 in about 5ms; it wouldn't be a problem to render at 200fps with OpenGL.
Cheers, Josh
On Apr 26, 2010, at 2:02 PM, Lawson English wrote:
Lawson English wrote:
Hannes Hirzel wrote:
On 4/26/10, Lawson English lenglish5@cox.net wrote:
Randal L. Schwartz wrote: I think that you meant to direct that at me...
/me looks sheepish.
Lawson
Please don't worry, just go ahead and work on a nice Mandelbrot morph. We need something like that for screenshots of Squeak.
Then Ian pointed out that we need a good screen shot and referred to an example on his blog (which actually shows that the current situation needs improvement ASAP)
http://mecenia.blogspot.com/2010/04/history-of-squeak-in-pictures.html
--Hannes
Levente has already done one. I'm trying to figure out how his works with an eye to make one that is etoy-enabled as a prelude to a "simple" [SIC] OGLMorph etoy thingie
http://squeaksource.com/MandelMorph2.html
Lawson
ah, that was Bob Arnings, as repackaged by Torsten Bergmann.
:-)
Lawson
On 5/1/10 11:04 PM, Josh Gargus wrote:
All this talk of Mandelbrot sets prompted me to write a Julia Set morph using my OpenCL framework. Here's how to try it out in a 4.1 image...
First, load the code:
Installer squeak project: 'FFI'; install: 'FFI-Pools'; install: 'FFI-Kernel'. Installer ss project: 'OpenCL'; install: 'OpenCL'.
Once the code has loaded, evaluate: OpenCLJuliaSetMorph new openInHand
Unfortunately all examples error with subscript is out of bounds:1
higlighting 'first'.
device := OpenCLPlatform allPlatforms first allGPUs first.
Lawson
MacOS X Pro SnowLeopard x.6.3
What kind of GPU does your computer have? Sounds like it might not support OpenCL.
Which 'first' is the problem? The one after #allPlatforms or #allGPUs? I'm guessing the latter.
Cheers, Josh
On May 1, 2010, at 11:28 PM, Lawson English wrote:
On 5/1/10 11:04 PM, Josh Gargus wrote:
All this talk of Mandelbrot sets prompted me to write a Julia Set morph using my OpenCL framework. Here's how to try it out in a 4.1 image...
First, load the code:
Installer squeak project: 'FFI'; install: 'FFI-Pools'; install: 'FFI-Kernel'. Installer ss project: 'OpenCL'; install: 'OpenCL'.
Once the code has loaded, evaluate: OpenCLJuliaSetMorph new openInHand
Unfortunately all examples error with subscript is out of bounds:1
higlighting 'first'.
device := OpenCLPlatform allPlatforms first allGPUs first.
Lawson
MacOS X Pro SnowLeopard x.6.3
On 5/1/10 11:45 PM, Josh Gargus wrote:
What kind of GPU does your computer have? Sounds like it might not support OpenCL.
ATI Radeon HD 2600 XT:
Chipset Model: ATI Radeon HD 2600 Type: GPU Bus: PCIe Slot: Slot-1
Which 'first' is the problem? The one after #allPlatforms or #allGPUs? I'm guessing the latter.
The latter.
Lawson
Bad news, OpenCL requires AMD 4xxx:
http://forums.amd.com/devforum/messageview.cfm?catid=390&threadid=119267...
Cheers, Josh
On May 1, 2010, at 11:47 PM, Lawson English wrote:
On 5/1/10 11:45 PM, Josh Gargus wrote:
What kind of GPU does your computer have? Sounds like it might not support OpenCL.
ATI Radeon HD 2600 XT:
Chipset Model: ATI Radeon HD 2600 Type: GPU Bus: PCIe Slot: Slot-1
Which 'first' is the problem? The one after #allPlatforms or #allGPUs? I'm guessing the latter.
The latter.
Lawson
Hi Randal, since I don't want you to be tweaked at me, I just wanted to clarify that I think you must've mistaken me for someone else.. I have not been in squeak irc chat for years..
On Mon, Apr 26, 2010 at 2:53 PM, Randal L. Schwartz merlyn@stonehenge.com wrote:
"Chris" == Chris Muller asqueaker@gmail.com writes:
Chris> Hi Levente, it does? Does that mean that (Float fromIEEE32Bit: Chris> myFloat asIEEE32BitWord) loses information? What would be a more Chris> precise method of serialization then?
You know, if you aren't going to pay attention to what I was saying in the #squeak channel, why were you even asking.
I *said* this to you. I said "looks like Float is 64 bit, and FloatArray is 32..Maybe mandel is storing things in FloatArray and that's where you're getting your truncation from, and if so one way out of that would be to use real Array instead of FloatArray"
I'm slightly tweaked that you ignored that, and you're now at the same place two days later.
I also told you that Mandel is always a myth, because the point at which the powers exceed 2 depends very much (butterfly effect-ish) on the precision of the representation. A version with 48-bit mantissas will look different than one with 24-bit mantissas, and different again from one with 100-bit mantissas.
-- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 merlyn@stonehenge.com URL:http://www.stonehenge.com/merlyn/ Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion
On Mon, 26 Apr 2010, Chris Muller wrote:
That's not true, every Float stores 64 bits.
Hi Levente, it does? Does that mean that (Float fromIEEE32Bit: myFloat asIEEE32BitWord) loses information? What would be a more precise method of serialization then?
From Float's class comment: "My instances represent IEEE-754 floating-point double-precision numbers." So using the 32-bit format loses 32 bits:
myFloat := 1.234567891234567. "===> 1.234567891234567" newFloat := Float fromIEEE32Bit: myFloat asIEEE32BitWord. "===> 1.234567880630493" newFloat = myFloat. "===> false"
A Float is an "array" of two words (32-bit). You can serialize the two words and create a new Float object from them later:
myFloat := 1.234567891234567. "===> 1.234567891234567" word1 := myFloat basicAt: 1. "===> 1072939210" word2 := myFloat basicAt: 2. "===> 1121498327". newFloat := (Float basicNew: 2) basicAt: 1 put: word1; basicAt: 2 put: word2; yourself. "===> 1.234567891234567" newFloat = myFloat. "===> true"
Levente
Just because some digits are not shown in the printString, it doesn't mean they aren't there:
1.01 printString. "==> '1.01'" 1.01 printShowingDecimalPlaces: 60. "==> '1.010000000000000008881784197001252323389053344726562500000000'"
I can work up a "fixed" point Complex number simply by writing over the internal ScaledDecimal representation using using z real: (z real) asString , but this is rather a lot of overhead and for precision less than 15ish decimal places, it would be nice to use hardware.
Any relatively easy way to do this (store native precision floating point)?
It's done, see above.
is there a faster way to truncate a ScaledDecimal than the above?
Sure, don't convert it to strings. :) I think you shouldn't use ScaledDecimal at all, since it's just a combination of a fraction and scale. You only need the fraction. Use #truncateTo: to truncate a number.
Levente
Lawson
Hi Lawson,
I'm not a Squeak expert, so I could be wrong, but I think the Squeak float array stores floats as 32 bits. I think so they can be passed to external DLLs or other programs that expect 32 bit floats. If they are 32 bit floats, you can see where your precision is going.
You could try regular arrays or collections, which will use pointers to 64 bit floats. This will take more memory and be a little slower than float arrays but will give you 64 bit precision.
You might also try fractions, which are constructed as two integers. A numerator and a denominator, that can be small or large integers. The precision will be as good as you can get and should be faster than scaled decimal.
Lou
I've been playing around with the Mandelbrot set and I noticed that the implementation using Float looked somewhat vague. After researching a while, it turns out (corrections welcome) that while Float performs 64-bit FP calculations, only a limited number of decimal places are stored for subsequent calculations. Is there a way around this?
I can work up a "fixed" point Complex number simply by writing over the internal ScaledDecimal representation using using z real: (z real) asString , but this is rather a lot of overhead and for precision less than 15ish decimal places, it would be nice to use hardware.
Any relatively easy way to do this (store native precision floating point)?
is there a faster way to truncate a ScaledDecimal than the above?
Lawson
----------------------------------------------------------- Louis LaBrunda Keystone Software Corp. SkypeMe callto://PhotonDemon mailto:Lou@Keystone-Software.com http://www.Keystone-Software.com
squeak-dev@lists.squeakfoundation.org
-
Chris Muller -
Hannes Hirzel -
Josh Gargus -
Lawson English -
Levente Uzonyi -
Louis LaBrunda -
merlyn＠stonehenge.com -
Nicolas Cellier