Fractint version 20.04 patch 12 released
Folks, Fractint version 20.04 patch 12 was released today. The executables can be found at: www.fractint.net or www.fractint.org Here is what's new: Fixed buffer overflow in disk video mode when savename was too long. Jonathan
Folks, Fractint version 20.04 patch 13 was released today. The executables can be found at: www.fractint.net or www.fractint.org Here is what's new: Fixed buffer overflow in Xfractint which was causing a segmentation fault when the formula parser tried to load a formula that was too large. Updated formula parser in Xfractint to use the long double type. Fixed sqrt_bf() function. Jonathan
Did the DOS version change to use long doubles or was it just the Xfractint version? Thanks for all the work. -- Mike Frazier www.fracton.org
Mike asked:
Did the DOS version change to use long doubles or was it just the Xfractint version?
Jonathan needs to answer because he knows what he did. In my ignorance I would guess "DOS not Xfractint". Here's a related bit of information, derdged from my memory, so take it for what it's worth. An arcane fact is the math coprocessor in Intel chip did (and I believe, still does) math in 80 bit doubles. Virtually all modern OS's convert the 80 bit doubles to 64 bits when they get them out of the coprocessor, wasting the extra precision that in Fractint we value so highly. The old Microsoft compiler we are using for the DOS fractint has an 80 bit "long double" type which fits the math coprocessor floating point size. That means a fractal type calculation that uses long double gets the extra precision of 80 vs 64 bits with no speed penalty, since the calculation is already done at 80 bits anyway. This is one of the few areas where technology went backwards when the old segmented memory architecture was abandoned. At one point we actually tried to globally change "double" to "long double (meaning 80 bit double), and things kind of worked, but there were too many exceptions. We use typedefs for the types in Fractint so most of the same code can be used for DOS Fractint and Xfractint Somebody correct me if I am wrong, but I don't think the 80 bit double exists in the Linux world except under very unusual circumstances. long double is sometimes no different than double (64 bit). Hence my (guessed) answer to Mike's question. Tim
On Sun, 2015-02-22 at 17:19 -0600, Timothy Wegner wrote:
Somebody correct me if I am wrong, but I don't think the 80 bit double exists in the Linux world except under very unusual circumstances. long double is sometimes no different than double (64 bit). Hence my (guessed) answer to Mike's question.
Take a look at the Wikipedia page for 'long double'. The gcc compiler defaults to using 80-bits for long double. Jonathan
On Sun, 2015-02-22 at 15:52 -0700, Mike Frazier wrote:
Did the DOS version change to use long doubles or was it just the Xfractint version?
The intention was that the long double changes only affect the Xfractint formula parser. This is so the formula images generated with Xfractint will more closely resemble the ones generated by the fast assembly language parser of the DOS version, which already uses the long double type. This does affect other fractal types since the complex type in Xfractint is now defined as two long doubles instead of two doubles. The DOS version did not (knowingly) get changed because of the speed hit and it broke all kinds of things. Jonathan
When I wrote Fracton I used doubles because I had to support Intel and PowerPC processors on the Mac. I wanted both processors to give the exact same result and long doubles were different between the two processors. Now that Mac's have used Intel processors exclusively for almost 10 years I guess I could improve normal math precision by using long doubles. I still have arbitrary precision for all formulas if you want it (and are willing to put up with the huge speed hit) so I don't gain any functionality. This explains why FractInt sometimes had more resolution than Fracton when using normal math. Thanks for taking the time to explain it. -- Mike Frazier www.fracton.org
Am 23.02.2015 um 00:40 schrieb Jonathan Osuch:
The DOS version did not (knowingly) get changed because of the speed hit and it broke all kinds of things. Jonathan, the latest MFR version (14) is shorter then the previous as all commands dealing with function conflicts are not needed anymore. All together about 10 lines and 6 variables. ; But inspite of that I get memory errors using the evolver mode and fractint crashes. That has never happened before. I use XP dos or bootstick. Have you an explanation? Has the fractint code expanded? If there is no fix I will have to stop posting as the evolver is essential for me. Albrecht
On Mon, 2015-02-23 at 23:27 +0100, Niekamp wrote:
But inspite of that I get memory errors using the evolver mode and fractint crashes. That has never happened before. I use XP dos or bootstick. Have you an explanation? Has the fractint code expanded? If there is no fix I will have to stop posting as the evolver is essential for me.
When you run the command "mem" how much conventional, expanded, and extended memory does it show? I tried running your MFR_13 formula with 400 MB of conventional memory and had no problem. I did, however, have plenty of either expanded or extended memory available. Jonathan
Jonathan, ; 655360 Bytes complete conventional memory 655360 Bytes for MS-Dos 627296 for executable program 1048576 Bytes for complete expansion memory 0 Bytes "running" expansion memory 941056 XMS memory MS-Dos resides in the upper memory (HMA) ; The Dos Link shows following info: Complete - automatic protected Initial - automatic Expansion (EMS) none Expanded (XMS) none - Using HMA Initial memory for MS Dos protection mode (DPM) automatic These are the default settings by XP. ; What should I change ? Thanks, Albrecht Am 24.02.2015 um 00:55 schrieb Jonathan Osuch:
On Mon, 2015-02-23 at 23:27 +0100, Niekamp wrote:
But inspite of that I get memory errors using the evolver mode and fractint crashes. That has never happened before. I use XP dos or bootstick. Have you an explanation? Has the fractint code expanded? If there is no fix I will have to stop posting as the evolver is essential for me. When you run the command "mem" how much conventional, expanded, and extended memory does it show?
I tried running your MFR_13 formula with 400 MB of conventional memory and had no problem. I did, however, have plenty of either expanded or extended memory available.
Jonathan
_______________________________________________ Fractint mailing list Fractint@mailman.xmission.com https://mailman.xmission.com/cgi-bin/mailman/listinfo/fractint
On Tue, 2015-02-24 at 08:24 +0100, Niekamp wrote:
655360 Bytes complete conventional memory 655360 Bytes for MS-Dos 627296 for executable program 1048576 Bytes for complete expansion memory 0 Bytes "running" expansion memory 941056 XMS memory MS-Dos resides in the upper memory (HMA) ; The Dos Link shows following info: Complete - automatic protected Initial - automatic
Change one of the following to 16384:
Expansion (EMS) none Expanded (XMS) none - Using HMA
You can do a before and after to see what Fractint is getting by running the command: Fractint debug=10000 Jonathan
participants (5)
-
Jonathan Osuch -
Jonathan Osuch -
Mike Frazier -
Niekamp -
Timothy Wegner