Float storage as Double?

>
>
> 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'"
>

> 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.

> 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_conversion_and_rounding 
>
>
>>
>>
>>>
>>>>
>>>> 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
>

> 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_conversion_and_rounding 
>>
>>>
>>>
>>>>
>>>>>
>>>>> 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
>
>
>
>

>
> 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)"
>
>

>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
>
>
>
>
>

> 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
>>
>>
>>
>>
>>
>>
>
>

>
>> 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 <[hidden email]> 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.
>
>  

> On 4/26/10, Lawson English <[hidden email]> 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 <[hidden email]> 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
>
>

>>>>>> "Chris" == Chris Muller <[hidden email]> 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
> <[hidden email]> <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
>

> 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
>
>