Hi Rupert,
I see no advantage to using arbitrary
precision in chaotic oscillators as there is never a need to zoom in that far.
Actually, I wish there was someone who
could assemble the original ASM code for arbitrary precision for the 32 and 64
bit platforms. I don’t know 80*86 assembler and hve no idea how to port
it. Winfract is still about 2 – 3 times faster than ManpWIN once the precision
of double is exceeded. However, ManpWIN has been able to zoom to far greater
depth 10^ 1000 or so. However, it took hours to create a single pixel on my
little laptop J
Maybe double double and quad double will
give a far better compromise between depth of zoom and speed. Maybe we could
add staged precision using different modes. If one was really keen, we could
create a library of complex arithmetic functions that automatically selected
the correct precision and was transparent to the fractal functions.
I like your youthful enthusiasm. I would
love to see the old team up and running again.
One thing I would love to see is
modularisation of FRACTINT. I get horribly confused with all the globals that
hound my code. I would love to see libraries of functions that virtually stand
alone. Let’s keep screen co-ordinates separate from the float values of
plotted variables. Let’s define our libraries so we can use them in other
applications. I really struggle with the megalithic functions in FRACTINT. Just
a Paulian idea J
Best regards,
Paul.
----------------------------------------------------------
Paul de Leeuw Computers NSW Central Coast,
Australia
Email:
pdeleeuw@deleeuw.com.au
www:
<http://www.deleeuw.com.au>
ABN
72 360 822 562
----------------------------------------------------------
Synchronous orbit iteration isn't well exploited either. It should be
"easy" to port it to arbitrary precision on Xfractint. Having said
that I tried, and couldn't figure out how to begin - are the viewing
coordinates passed around as strings?
I think there's some scope for further optimising the SOI algorithm
itself. The interpolation is not conformal. I have no proof but I think
conformal interpolation would be more efficient - after all iteration of a
complex function is conformal.
Finally, SOI would play well with arbitrary precision / double doubles
/ quad doubles because the most significant bits may be the same and their
products/sums may only need to be calculated once.
If I could just get started, I think I'd have lots of fun, trying this
stuff out in Xfractint.
(I wonder if I used to be the youngest user of Fractint? Back in 1996,
aged 10, using version 19.6 on a 486. It takes me back! I was happy looking at
the pretty pictures. Never realised how much more there was to it - C
programming, complex analysis, etc.)
It saddens me, a bit,
that Fractint hasn't "kept up with the times." The technological
landscape certainly has changed since I sent in my contributions 20+ years ago.
(I optimized Lyapunov and L-systems. My L-systems optimization took advantage
of the way integer code never touched the FP stack, so I could load the engine
state into the FP registers and leave it there as the L-system parser happily
indirected pointers-to-function.) Companies are often willing to subsidize open
source development if the project is aligned with their business interests, but
I guess the economics of open source don't translate to rendering pretty
pictures!
I have very little time these days, what with the family, working a demanding
job at Amazon, and continuing a part-time life as an author (The CUDA Handbook,
June 2013). But every once in a while, I get to wondering, What's up with
Fractint?, find a copy of the source code, unpack it, and start looking around,
and say Man, This code needs a LOT of work. I wouldn't even know where to
start!
The name of the project is dated, of course - there are still reasons to use
fixed point here and there, but performance isn't one of them. An optimized CPU
implementation of a fractal generator would use SSE (or now AVX), have separate
single and double precision implementations, and leverage multicore hardware.
Fractals are extremely computationally dense, so are a good fit both for GPU
computing and for clustering. It's getting a bit far afield from my own
expertise, but open source compiler technology (LLVM etc.) has advanced to the
point where the custom fractal engines likely could take advantage.
A modern project would put clear divisions of labor between the fractal
processing, translating the iteration counts to images, and the user interface.
It might be more efficient to start from scratch and migrate code (or ideas)
from Fractint a bit at a time. But with the limited time I could invest in such
a project, I feel a bit like one of the mice from The Bell and the Cat. http://en.wikipedia.org/wiki/Belling_the_cat
If it isn't already in bitbucket or github or some other open source
repository, I'd encourage migration of the "latest" (such as it is)
code base to one of those.
> Date: Fri, 7 Mar 2014 14:27:14 -0600
> From: Paul.N.Lee@att.net
> To: fractdev@mailman.xmission.com
> Subject: Re: [Fractdev] Sorry, but Fractint is not slowing, but rapidly
dying
>
> Timothy Wegner wrote:
> >
> > No need to feel any sorrow about one
> > of the oldest and longest-maintained
> > open source projects, which by rights,
> > was obsolete a decade ago. Mystery
> > of mysteries, it's life continues on.
> >
>
> They said the same thing about COBOL decades ago, but I still see
> companies all the time looking for some of those old programmers (like
> me) that really know how to work with legacy applications.
>
> FractInt will be around until the last of the old users have finally
> died, which hopefully will be a few more decades for some of us. :-)
>
>
> Sincerely,
> P.N.L.
>
> _______________________________________________
> Fractdev mailing list
> Fractdev@mailman.xmission.com
> http://mailman.xmission.com/cgi-bin/mailman/listinfo/fractdev