PAUL: As you said some time ago,, Fractint and Winfract personnel are only involved in changing environment and 'gadgets' and not implementing new fractals or having any other 'growing attitude', or really upgrading those programs, That´s how and when begins their senescence, and the obsolescence we are sorrow to feel. Marcus De: Timothy Wegner <tim@tswegner.net> Para: "Fractint developer's list" <fractdev@mailman.xmission.com> Data: 07/03/2014 12:19 Assunto: Re: [Fractdev] [Fractint] Fractint under FREEDOS from USB drive Paul, I'm interested. What development environment are you using? Tim On Fri, Mar 7, 2014 at 1:12 AM, Paul <pdeleeuw@deleeuw.com.au> wrote: Dear Friends, I have been doing a lot of work on ManpWIN. Let me know if there is any interest. I’m happy to share source code if anyone is interested. The basic engine is based on Winfract. http://www.deleeuw.com.au/download/SetupManpWIN.exe 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 ---------------------------------------------------------- From: fractdev-bounces@mailman.xmission.com [mailto: fractdev-bounces@mailman.xmission.com] On Behalf Of Timothy Wegner Sent: Friday, 7 March 2014 10:17 AM To: Fractint and General Fractals Discussion; fractdev@mailman.xmission.com Subject: Re: [Fractdev] [Fractint] Fractint under FREEDOS from USB drive Occurs to me that this thread is more appropriate for the fractdev mailing list than fractint, so I will crosspost this to fractdev, then follow up there. I'm not saying that there shouldn't be ANY discussion of booting fractint from USB here, but if we get into lengthy discussions of arcane hardware issues (which I certainly enjoy), we may be getting a little off topic for this list. We'll see how it goes. Anyone interested in sharing technical information about running fractint on various platforms please join me in Fractdev. When I have something to share with end users, I will report here. Please understand I am not trying to shush anyone up, so if you'd like to see this discussion here, by all means say so. Paul wrote: I have found that it depends on the level of USB that you have installed on the computer, as well as the pluggin drive itself. Some thumb drives work on some of my older machines, and some do not. The puzzle is that I have three self-built machines of different ages that all have Gigabyte motherboards, AMD chips, and Award bioses. The oldest and youngest boot USB and CF, but the middle machine does not. The point is that these are not dissimilar, just different ages. Doesn't worry me that one doesn't work, I guess I am just compulsive. I'll compare the bios settings, and see if there's some setting causing different behavior. I really want to try the middle machine because it is the only one with NVIDIA (non-motherboard) graphics, which some folks have suggested might have better VESA support. I do have a plan B. I found a 2.5 inch 80gb SATA drive in my junk drawer that came out of a Dell E1505 Laptop when I upgraded the drive. I'll blow away the XP on it and format with FreeDOS. That should certainly work in a dual boot configuration on the middle machine. Followups to fractdev please. Tim _______________________________________________ Fractdev mailing list Fractdev@mailman.xmission.com http://mailman.xmission.com/cgi-bin/mailman/listinfo/fractdev _______________________________________________ Fractdev mailing list Fractdev@mailman.xmission.com http://mailman.xmission.com/cgi-bin/mailman/listinfo/fractdev Este e-mail e seus anexos são de responsabilidade do emissor e para uso exclusivo do destinatário. Se você receber este e-mail por engano, por favor, notifique o emissor e apague-o imediatamente. O conteúdo pode conter informações confidenciais e/ou legalmente privilegiadas que não podem ser parcial ou totalmente reproduzidas sem o consentimento do autor. Portanto, qualquer divulgação ou uso não autorizado é proibido e protegido por lei. This e-mail and its attachments are responsibility of the sender and for exclusive use of the recipient. If you receive this e-mail by mistake, please notify the sender and delete it immediately. Contents may contain confidential and/or legally privileged information that can not be partially or totally reproduced without the author's consent. Therefore, any disclosure or unauthorized use is prohibited and protected by law.

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.

Nick, I well remember you! I've had a whole software development career since my main work on Fractint, and of course it is easy to imagine a different project. But for all kinds of reasons, Fractint became very full featured on it's original architecture. There were some really significant ports sorted according to how well synched they are to the DOS version: 1. Xfractint, a Linux port, which was done so literally that we were able to merge and maintain it with the DOS code base. 2. Winfract, a Windows 3.1 port, that also was (mostly) kept synch with DOS. It lagged behind finally, but Jonathan got it close to synched again a few years ago. Now, of course, windows 3.1 is just as obsolete as DOS. Winfract still uses the same medium memory model as Fractint! 3. Rich Thomson's Windows windows version was an amazing port to a more modern Windows. He began with a literal port, but began (understandably) refactoring code so it was less ugly, and it forked from Fractint. Much to Rich's dismay, Jonathan and I weren't ready to cut loose from the DOS version. I'm not sure if this program ever got a following, but it successfully incorporated nearly all of the DOS Fractint's features, although it doesn't have Mouse support. If someone wanted to continue toward a modern version still closely tied to Fractint's original features, this would be the version to start with. By the way, we all owe Rich a huge debt because through his Xmission contacts, these mailing lists have been hosted for many years. Rich and Xmission are the best! 4. ManPWin by Paul. Pretty much a brand new program, but many features incorporated from Fractint. There are others, such as Ultrafractal that started out as a Fractint workalike, then moved in other directions. Many years ago we answered all kinds of questions posed by the author, then he turned around and released his software as closed source. Many of our former users love it. The situation is complex, but that's one view of it. Somewhere in there we raised a families and had careers! Tim

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? Secondly "double doubles" and "quad doubles" (such as http://web.mit.edu/tabbott/Public/quaddouble-debian/qd-2.3.4-old/docs/qd.pdf) may be faster than arbitrary precision and they cover a very useful range of magnification for the Mandelbrot set. (Trying double long doubles and triple things may also be fruitful.) 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.) Kind regards, Rupert

On 7 Mar 2014, at 20:53, Nicholas Wilt <nicholas_wilt@hotmail.com> wrote:

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

---

Fractdev mailing list Fractdev@mailman.xmission.com http://mailman.xmission.com/cgi-bin/mailman/listinfo/fractdev

Synchronous orbit iteration is a technique for speeding up computation of escape time fractals. Came in version 20 - activated by an option. It would be extremely helpful for deep zooms. If you want to do arbitrary precision fractals in your software, I would recommend a library like GMP, which is being maintained and targets modern processors. But I would probably try QD first. As you have said the obvious way to do it is to have selectable types single, double, long double, double double, ?double long double, ?triple double, ?triple long double, quad double, ?quad long double, and finally arbitrary precision for very deep zooms.

On 9 Mar 2014, at 01:20, "Paul" <pdeleeuw@deleeuw.com.au> wrote:

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

From: fractdev-bounces@mailman.xmission.com [mailto:fractdev-bounces@mailman.xmission.com] On Behalf Of Rupert Millard Sent: Sunday, 9 March 2014 12:56 AM To: Fractint developer's list Cc: Fractint developer's list Subject: Re: [Fractdev] Sorry, but Fractint is not slowing, but rapidly dying

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?

Secondly "double doubles" and "quad doubles" (such as http://web.mit.edu/tabbott/Public/quaddouble-debian/qd-2.3.4-old/docs/qd.pdf) may be faster than arbitrary precision and they cover a very useful range of magnification for the Mandelbrot set. (Trying double long doubles and triple things may also be fruitful.)

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

Kind regards,

Rupert

...

On 7 Mar 2014, at 20:53, Nicholas Wilt <nicholas_wilt@hotmail.com> wrote: 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

---

Fractdev mailing list Fractdev@mailman.xmission.com http://mailman.xmission.com/cgi-bin/mailman/listinfo/fractdev

---

Fractdev mailing list Fractdev@mailman.xmission.com http://mailman.xmission.com/cgi-bin/mailman/listinfo/fractdev

Hi Rupert, I am keen to put in a moderate precision step between double and full arbitrary precision. Quad double sounds like a great solution. I downloaded the quad double library but struggle to get it to compile under Windows. The main issue is to get the windows definition for things like: QD_ISFINITE, QD_ISINF and QD_ISNAN. These may be defined for Linux, but not for Windoze. Have you been able to build a library for Windows? Please advise. Thanks, Paul. ---------------------------------------------------------- Paul de Leeuw Computers NSW Central Coast, Australia Email: <mailto:pdeleeuw@deleeuw.com.au> pdeleeuw@deleeuw.com.au www: < <http://www.deleeuw.com.au/> http://www.deleeuw.com.au> ABN 72 360 822 562 ---------------------------------------------------------- _____ From: fractdev-bounces@mailman.xmission.com [mailto:fractdev-bounces@mailman.xmission.com] On Behalf Of Rupert Millard Sent: Sunday, 9 March 2014 10:15 PM To: Fractint developer's list Cc: Fractint developer's list Subject: Re: [Fractdev] Sorry, but Fractint is not slowing, but rapidly dying Synchronous orbit iteration is a technique for speeding up computation of escape time fractals. Came in version 20 - activated by an option. It would be extremely helpful for deep zooms. If you want to do arbitrary precision fractals in your software, I would recommend a library like GMP, which is being maintained and targets modern processors. But I would probably try QD first. As you have said the obvious way to do it is to have selectable types single, double, long double, double double, ?double long double, ?triple double, ?triple long double, quad double, ?quad long double, and finally arbitrary precision for very deep zooms. On 9 Mar 2014, at 01:20, "Paul" <pdeleeuw@deleeuw.com.au> wrote: 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 :-) 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 :-) Best regards, Paul. ---------------------------------------------------------- Paul de Leeuw Computers NSW Central Coast, Australia Email: <mailto:pdeleeuw@deleeuw.com.au> pdeleeuw@deleeuw.com.au www: < <http://www.deleeuw.com.au/> http://www.deleeuw.com.au> ABN 72 360 822 562 ---------------------------------------------------------- _____ From: fractdev-bounces@mailman.xmission.com [mailto:fractdev-bounces@mailman.xmission.com] On Behalf Of Rupert Millard Sent: Sunday, 9 March 2014 12:56 AM To: Fractint developer's list Cc: Fractint developer's list Subject: Re: [Fractdev] Sorry, but Fractint is not slowing, but rapidly dying 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? Secondly "double doubles" and "quad doubles" (such as http://web.mit.edu/tabbott/Public/quaddouble-debian/qd-2.3.4-old/docs/qd.pdf ) may be faster than arbitrary precision and they cover a very useful range of magnification for the Mandelbrot set. (Trying double long doubles and triple things may also be fruitful.) 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.) Kind regards, Rupert On 7 Mar 2014, at 20:53, Nicholas Wilt <nicholas_wilt@hotmail.com> wrote: 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

_______________________________________________ Fractdev mailing list Fractdev@mailman.xmission.com http://mailman.xmission.com/cgi-bin/mailman/listinfo/fractdev _______________________________________________ Fractdev mailing list Fractdev@mailman.xmission.com http://mailman.xmission.com/cgi-bin/mailman/listinfo/fractdev

Rather than building the library and linking to it, try using the headers that provide inlinable functions. That's what I did on Linux.

On 25 Mar 2014, at 08:00, Rupert Millard <rupert@rupertmillard.net> wrote:

I haven't tried and I don't have a compiler. (I may have Visual Studio 6 on CDs somewhere, but would it work on Windows 7?) Would you like to email me your compiler output and I'll take a look. It sounds like those definitions should be in the QD library. Are you sure you're including everything that you need?

...

On 25 Mar 2014, at 06:41, "Paul" <pdeleeuw@deleeuw.com.au> wrote:

Hi Rupert,

I am keen to put in a moderate precision step between double and full arbitrary precision. Quad double sounds like a great solution.

I downloaded the quad double library but struggle to get it to compile under Windows. The main issue is to get the windows definition for things like:

QD_ISFINITE, QD_ISINF and QD_ISNAN. These may be defined for Linux, but not for Windoze.

Have you been able to build a library for Windows?

Please advise.

Thanks,

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

From: fractdev-bounces@mailman.xmission.com [mailto:fractdev-bounces@mailman.xmission.com] On Behalf Of Rupert Millard Sent: Sunday, 9 March 2014 10:15 PM To: Fractint developer's list Cc: Fractint developer's list Subject: Re: [Fractdev] Sorry, but Fractint is not slowing, but rapidly dying

Synchronous orbit iteration is a technique for speeding up computation of escape time fractals. Came in version 20 - activated by an option. It would be extremely helpful for deep zooms.

If you want to do arbitrary precision fractals in your software, I would recommend a library like GMP, which is being maintained and targets modern processors. But I would probably try QD first. As you have said the obvious way to do it is to have selectable types single, double, long double, double double, ?double long double, ?triple double, ?triple long double, quad double, ?quad long double, and finally arbitrary precision for very deep zooms.

...

On 9 Mar 2014, at 01:20, "Paul" <pdeleeuw@deleeuw.com.au> wrote:

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

From: fractdev-bounces@mailman.xmission.com [mailto:fractdev-bounces@mailman.xmission.com] On Behalf Of Rupert Millard Sent: Sunday, 9 March 2014 12:56 AM To: Fractint developer's list Cc: Fractint developer's list Subject: Re: [Fractdev] Sorry, but Fractint is not slowing, but rapidly dying

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?

Secondly "double doubles" and "quad doubles" (such as http://web.mit.edu/tabbott/Public/quaddouble-debian/qd-2.3.4-old/docs/qd.pdf) may be faster than arbitrary precision and they cover a very useful range of magnification for the Mandelbrot set. (Trying double long doubles and triple things may also be fruitful.)

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

Kind regards,

Rupert

...

On 7 Mar 2014, at 20:53, Nicholas Wilt <nicholas_wilt@hotmail.com> wrote: 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

---

Fractdev mailing list Fractdev@mailman.xmission.com http://mailman.xmission.com/cgi-bin/mailman/listinfo/fractdev

---

Fractdev mailing list Fractdev@mailman.xmission.com http://mailman.xmission.com/cgi-bin/mailman/listinfo/fractdev

---

Fractdev mailing list Fractdev@mailman.xmission.com http://mailman.xmission.com/cgi-bin/mailman/listinfo/fractdev

On 2014-03-07 1:27 PM, Paul N. Lee wrote:

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. :-) It will be around in source code fragments longer than that. A version of UltraFract featured an error identical to a fractint error: 180 colours in outside=atan. I didn't buy UltraFract, because the author said he wuzn't willing to support fractint formulas. I don't believe him, and by the same token, I did not buy.

Hi Marcus, They are performing a different process than we are. They are updating the magnificent product FRACTINT. It is still a classic bit of software and the inspiration for much of ManpWIN code. I am indebted to the authors of that program for ideas. I chose a different pathway. Both are valid. Best regards, Paul. ---------------------------------------------------------- Paul de Leeuw Computers NSW Central Coast, Australia Email: <mailto:pdeleeuw@deleeuw.com.au> pdeleeuw@deleeuw.com.au www: < <http://www.deleeuw.com.au/> http://www.deleeuw.com.au> ABN 72 360 822 562 ---------------------------------------------------------- _____ From: fractdev-bounces+pdeleeuw=deleeuw.com.au@mailman.xmission.com [mailto:fractdev-bounces+pdeleeuw=deleeuw.com.au@mailman.xmission.com] On Behalf Of Marcus Rezende Sent: Saturday, 8 March 2014 5:03 AM To: Fractint developer's list Subject: [Fractdev] Sorry, but Fractint is not slowing, but rapidly dying PAUL: As you said some time ago,, Fractint and Winfract personnel are only involved in changing environment and 'gadgets' and not implementing new fractals or having any other 'growing attitude', or really upgrading those programs, That´s how and when begins their senescence, and the obsolescence we are sorrow to feel. Marcus De: Timothy Wegner <tim@tswegner.net> Para: "Fractint developer's list" <fractdev@mailman.xmission.com> Data: 07/03/2014 12:19 Assunto: Re: [Fractdev] [Fractint] Fractint under FREEDOS from USB drive _____ Paul, I'm interested. What development environment are you using? Tim On Fri, Mar 7, 2014 at 1:12 AM, Paul <pdeleeuw@deleeuw.com.au> wrote: Dear Friends, I have been doing a lot of work on ManpWIN. Let me know if there is any interest. I’m happy to share source code if anyone is interested. The basic engine is based on Winfract. <http://www.deleeuw.com.au/download/SetupManpWIN.exe> http://www.deleeuw.com.au/download/SetupManpWIN.exe Regards, Paul. ---------------------------------------------------------- Paul de Leeuw Computers NSW Central Coast, Australia Email: pdeleeuw@deleeuw.com.au www: <http://www.deleeuw.com.au <http://www.deleeuw.com.au/> > ABN 72 360 822 562 ---------------------------------------------------------- _____ From: <mailto:fractdev-bounces@mailman.xmission.com> fractdev-bounces@mailman.xmission.com [mailto: <mailto:fractdev-bounces@mailman.xmission.com> fractdev-bounces@mailman.xmission.com] On Behalf Of Timothy Wegner Sent: Friday, 7 March 2014 10:17 AM To: Fractint and General Fractals Discussion; <mailto:fractdev@mailman.xmission.com> fractdev@mailman.xmission.com Subject: Re: [Fractdev] [Fractint] Fractint under FREEDOS from USB drive Occurs to me that this thread is more appropriate for the fractdev mailing list than fractint, so I will crosspost this to fractdev, then follow up there. I'm not saying that there shouldn't be ANY discussion of booting fractint from USB here, but if we get into lengthy discussions of arcane hardware issues (which I certainly enjoy), we may be getting a little off topic for this list. We'll see how it goes. Anyone interested in sharing technical information about running fractint on various platforms please join me in Fractdev. When I have something to share with end users, I will report here. Please understand I am not trying to shush anyone up, so if you'd like to see this discussion here, by all means say so. Paul wrote: I have found that it depends on the level of USB that you have installed on the computer, as well as the pluggin drive itself. Some thumb drives work on some of my older machines, and some do not. The puzzle is that I have three self-built machines of different ages that all have Gigabyte motherboards, AMD chips, and Award bioses. The oldest and youngest boot USB and CF, but the middle machine does not. The point is that these are not dissimilar, just different ages. Doesn't worry me that one doesn't work, I guess I am just compulsive. I'll compare the bios settings, and see if there's some setting causing different behavior. I really want to try the middle machine because it is the only one with NVIDIA (non-motherboard) graphics, which some folks have suggested might have better VESA support. I do have a plan B. I found a 2.5 inch 80gb SATA drive in my junk drawer that came out of a Dell E1505 Laptop when I upgraded the drive. I'll blow away the XP on it and format with FreeDOS. That should certainly work in a dual boot configuration on the middle machine. Followups to fractdev please. Tim _______________________________________________ Fractdev mailing list Fractdev@mailman.xmission.com http://mailman.xmission.com/cgi-bin/mailman/listinfo/fractdev _______________________________________________ Fractdev mailing list Fractdev@mailman.xmission.com <http://mailman.xmission.com/cgi-bin/mailman/listinfo/fractdev> http://mailman.xmission.com/cgi-bin/mailman/listinfo/fractdev Este e-mail e seus anexos são de responsabilidade do emissor e para uso exclusivo do destinatário. Se você receber este e-mail por engano, por favor, notifique o emissor e apague-o imediatamente. O conteúdo pode conter informações confidenciais e/ou legalmente privilegiadas que não podem ser parcial ou totalmente reproduzidas sem o consentimento do autor. Portanto, qualquer divulgação ou uso não autorizado é proibido e protegido por lei. This e-mail and its attachments are responsibility of the sender and for exclusive use of the recipient. If you receive this e-mail by mistake, please notify the sender and delete it immediately. Contents may contain confidential and/or legally privileged information that can not be partially or totally reproduced without the author's consent. Therefore, any disclosure or unauthorized use is prohibited and protected by law.

Dear Friends, I have been working feverishly to get ManpWIN in some sort of state where I could share the source with you. I have released ManpWIN v3.02 this evening. Please find the latest source at: http://www.deleeuw.com.au/download/ManpWINSrc.zip <http://www.deleeuw.com.au/download/SetupManpWIN.exe> and the installation file at: http://www.deleeuw.com.au/download/SetupManpWIN.exe It's a bit rough but it works well. I want to acknowledge Marcus for all his enthusiasm and suggestions that have really added a lot of new ideas to ManpWIN. Have a play with Chaotic Oscillators, especially real time animation along the axes. Note that not all of them rotate. Any comments, suggestions and ideas are welcome. Best regards, Paul. ---------------------------------------------------------- Paul de Leeuw Computers NSW Central Coast, Australia Email: <mailto:pdeleeuw@deleeuw.com.au> pdeleeuw@deleeuw.com.au www: < <http://www.deleeuw.com.au/> http://www.deleeuw.com.au> ABN 72 360 822 562 ---------------------------------------------------------- _____ From: fractdev-bounces@mailman.xmission.com [mailto:fractdev-bounces@mailman.xmission.com] On Behalf Of Timothy Wegner Sent: Saturday, 8 March 2014 2:18 AM To: Fractint developer's list Subject: Re: [Fractdev] [Fractint] Fractint under FREEDOS from USB drive Paul, I'm interested. What development environment are you using? Tim On Fri, Mar 7, 2014 at 1:12 AM, Paul <pdeleeuw@deleeuw.com.au> wrote: Dear Friends, I have been doing a lot of work on ManpWIN. Let me know if there is any interest. I'm happy to share source code if anyone is interested. The basic engine is based on Winfract. http://www.deleeuw.com.au/download/SetupManpWIN.exe Regards, Paul. ---------------------------------------------------------- Paul de Leeuw Computers NSW Central Coast, Australia Email: <mailto:pdeleeuw@deleeuw.com.au> pdeleeuw@deleeuw.com.au www: < <http://www.deleeuw.com.au/> http://www.deleeuw.com.au> ABN 72 360 822 562 ---------------------------------------------------------- _____ From: fractdev-bounces@mailman.xmission.com [mailto:fractdev-bounces@mailman.xmission.com] On Behalf Of Timothy Wegner Sent: Friday, 7 March 2014 10:17 AM To: Fractint and General Fractals Discussion; fractdev@mailman.xmission.com Subject: Re: [Fractdev] [Fractint] Fractint under FREEDOS from USB drive Occurs to me that this thread is more appropriate for the fractdev mailing list than fractint, so I will crosspost this to fractdev, then follow up there. I'm not saying that there shouldn't be ANY discussion of booting fractint from USB here, but if we get into lengthy discussions of arcane hardware issues (which I certainly enjoy), we may be getting a little off topic for this list. We'll see how it goes. Anyone interested in sharing technical information about running fractint on various platforms please join me in Fractdev. When I have something to share with end users, I will report here. Please understand I am not trying to shush anyone up, so if you'd like to see this discussion here, by all means say so. Paul wrote: I have found that it depends on the level of USB that you have installed on the computer, as well as the pluggin drive itself. Some thumb drives work on some of my older machines, and some do not. The puzzle is that I have three self-built machines of different ages that all have Gigabyte motherboards, AMD chips, and Award bioses. The oldest and youngest boot USB and CF, but the middle machine does not. The point is that these are not dissimilar, just different ages. Doesn't worry me that one doesn't work, I guess I am just compulsive. I'll compare the bios settings, and see if there's some setting causing different behavior. I really want to try the middle machine because it is the only one with NVIDIA (non-motherboard) graphics, which some folks have suggested might have better VESA support. I do have a plan B. I found a 2.5 inch 80gb SATA drive in my junk drawer that came out of a Dell E1505 Laptop when I upgraded the drive. I'll blow away the XP on it and format with FreeDOS. That should certainly work in a dual boot configuration on the middle machine. Followups to fractdev please. Tim _______________________________________________ Fractdev mailing list Fractdev@mailman.xmission.com http://mailman.xmission.com/cgi-bin/mailman/listinfo/fractdev

Paul wrote:

I have been doing a lot of work on ManpWIN. Let me know if there is any interest. I'm happy to share source code if anyone is interested. The basic engine is based on Winfract.

http://www.deleeuw.com.au/download/SetupManpWIN.exe

I have tried to keep up with all of your modifications over the years, and have made sure that most of the forums which I have frequented are aware of your application. You have given several people an alternative when they are unable to use FractInt on their more modern machines. Thank you for keeping it going, and hope you will continue with the upgrades when you have the time to devote to it. Sincerely, P.N.L.

Hi Rupert, Thanks for responding. Did you try the program? It's free. Of course there's a need for arbitrary precision, but not in the iteration loop. However, the speed seems almost independent of depth of zoom. I am currently running a zoom over 10^10000. You said: So how would I do it, if I had the required product of programming skill and free time? A recursive algorithm, like SOI. You'd need to pass the coordinates for a rectangle and incomplete arbitrary precision iteration data for a (hopefully) central point. Complete iteration of central point until bailout / maxit / or possibly periodicity check positive. (I suspect periodicity checking would be more of a hindrance.) Calculate other key points in turn, recursing when the approximation breaks down. Are you able to express this as an algorithm that I could code to? I just can't visualise what the code would look like. I appreciate any help you can give. Here are some comments that may be useful: Perturbation <http://dinkydauset.deviantart.com/journal/Perturbation-for-the-Mandelbrot-s et-450766847> for the Mandelbrot set * by DinkydauSet <http://dinkydauset.deviantart.com/> , Apr 28, 2014, 3:46:13 PM * Journals <http://www.deviantart.com/journals/> / Personal <http://www.deviantart.com/journals/personal/> Perturbation for the Mandelbrot set Perturbation for rendering the Mandelbrot set has been around for a while. I would have written a journal before because it's very awesome, but right from the start there was a fundamental problem: reliability. A recent discovery by Pauldelbrot on fractalforums.com indicates that perturbation can now be used to render the Mandelbrot set reliably. Is the project approaching completion? "Correctness" now appears to be achieved. Discovery Roughly a year ago, Kevin Martin published a relatively short document <http://www.deviantart.com/users/outgoing?http://www.superfractalthing.co.nf /sft_maths.pdf> about the Mandelbrot set, containing some equations that staggered everyone. His idea was to apply the principle of perturbation to rendering the Mandelbrot set, and combining that with something he called series approximation. Perturbation allows the iteration count of a pixel to be derived from a different, fully calculated pixel "nearby" (to be called a reference pixel). In practice this means that it's possible to calculate just one single pixel in an image, and derive the rest using perturbation. At great depths with millions of iterations, this saves an enormous amount of render time, which is the main result. Series approximation allows large number of iterations of pixels to be skipped entirely, good for another enormous speed-up, but it doesn't stop there. In addition, no arbitrary precision calculations are required to do the "deriving" work. Floating point calculations, which are much faster to perform, are sufficient. Martin concludes his document with the following statement: Using [the equations] means that the time taken rendering Mandelbrot images is largely independent of depth and iteration count, and mainly depends on the complexity of the image being created. The implications of this are enormous and such a theory is of course yelling to be implemented. Along with the mathematics, Martin also published a simple software implementation of the theory dubbed SuperFractalThing, so that everyone could see that it works. Since then, more software developers have started working on their own implementations. The simple equation of the Mandelbrot set has long been famous of being so computationally intensive that it can bring any supercomputer to it's knees, as long as you zoom in deep enough. Although that is still the case even with perturbation, the barrier has been shifted significantly. Fractal extreme has been the fastest software to calculate the Mandelbrot set for a long time, using traditional optimizations. If the deviation above were to be rendered in Fractal extreme, the render would take roughly 6 months. The actual image was rendered in 6 hours using an implementation of perturbation by Botond Kosa. What you're looking at right there is something that, without perturbation, would have been totally out of reach for many years, no matter how optimized the software is. As Bruce Dawson, the man behind Fractal extreme, commented on fractalforums.com: good algorithms beat optimized code. Glitches Although there is no doubt that perturbation is a "good algorithm", it came with severe problems right from the start, that Kevin Martin couldn't solve himself. If you have been paying attention, you may have noticed the requirement of a reference pixel to be "nearby". More specifically, usage of floating point numbers to do the calculations requires some numbers in the perturbation equation to be "small". Mathematically, this is completely useless, because there's no exact definition of what "small" is. Indeed, the results of the calculations were shown to be unreliable in many cases. It turned out that the results were correct "most of the time", but sometimes not. Incorrect parts of renders have since been called glitches. I tried to look at the source code and got totally lost. I hope we can get something going here. Thanks, Paul. ---------------------------------------------------------- Paul de Leeuw Computers NSW Central Coast, Australia Email: <mailto:pdeleeuw@deleeuw.com.au> pdeleeuw@deleeuw.com.au www: < <http://www.deleeuw.com.au/> http://www.deleeuw.com.au> ABN 72 360 822 562 ---------------------------------------------------------- _____ From: Fractdev [mailto:fractdev-bounces@mailman.xmission.com] On Behalf Of Rupert Millard Sent: Sunday, 18 January 2015 7:04 PM To: Fractint developer's list Subject: Re: [Fractdev] Perturbation Theory Implementation You've said that it only uses the double float in the deep zooming code, but where does it get X0....Xn from? There must be arbitrary precision code somewhere.

From that two page PDF, the algorithm looks simple, doesn't it? However we know Δn gets "large" (< 4, mins) for sufficiently large n. That's chaos theory for you, and it wouldn't look like a fractal if Δn remained of the order of 10^-100 all the time. So it must do something when the approximation breaks down - I expect it starts calculating at arbitrary precision. (Although as we're working with floating point types, it would be quite elegant to use that double-double / quad-double datatype here.)

So how would I do it, if I had the required product of programming skill and free time? A recursive algorithm, like SOI. You'd need to pass the coordinates for a rectangle and incomplete arbitrary precision iteration data for a (hopefully) central point. Complete iteration of central point until bailout / maxit / or possibly periodicity check positive. (I suspect periodicity checking would be more of a hindrance.) Calculate other key points in turn, recursing when the approximation breaks down. Hope this helps. I can take a look at the source code too if that would help.