Igor Stasenko wrote:
> On 24 April 2010 10:55, Lawson English <lenglish5 at cox.net> wrote:
>   
>> Lawson English wrote:
>>     
>>> Thanks. I had gotten that far with John Dougan's help and tried to save
>>> back to the repository but it wouldn't accept since I lack a password.   I
>>> converted all references of Floats to Fractions just to see if there was an
>>> easy way to give it higher precision but it slowed down to < Apple ][ speeds
>>> when I did that.
>>>
>>>
>>> Obviously the naive way isn't going to work. I gotta think there's some
>>> glitch with what I did, or incompatibility with the algorithm and
>>> Fractions....
>>>
>>>
>>>       
>> Or maybe  things like x^100/y^100   takes a rather long time to calculate...
>>
>>     
>
> you can optimize, rather than multiplying x*x*...*x 100 times in a row,
>
> use a power of two numerics.
> Given that:
> x^y = (x^a)*(x^b)
> where y = a+b
>
> so,
>
> x^100 = (x^64)*(x^32)*(x^4)
>
> then, you can reuse an intermediate results of computation i.e:
>
> x2 := x*x.
> x4 := x2*x2.
> x8 := x4*x4.
> x16 := x8*x8.
> x32 := x16*x16.
> x64 := x32*x32.
>
> result := x64*x32*x4.
>
> so, totally 8 multiplications, instead of 100.
>
>   
>
Interesting. I'm not quite sure if it would work for colorizing the M 
set boundaries though, since that is typically done based on the number 
of iterations before the number goes out of bounds.

I guess a logarithmic index could be used for  the color table instead 
of a linear index...

I worked out a simple way to truncate calculations to an arbitrary 
number of digits.  Unless my algorithm is wrong, I can do 100 recursive 
Complex>>squared calculations at 1000 decimal points of precision in 
only 17 seconds (i.e. 100TimesRepeat: ["z := z^2"]). Which is a tad too 
slow for the M set.
[ b:= b*b. b real: (ScaledDecimal readFrom: (b real)asString).   b 
imaginary: (ScaledDecimal readFrom: (b imaginary) asString)]

where the  real and imaginary  were already set as scaledDecimal: 1000

so a test after each new run would give 7 levels of color for z^128 and 
run 12 times faster.

only 1.4 seconds per pixel. Getting close... ;-)


Lawson