In article <1278637641.1858.22.camel@jonathan-desktop>, Jonathan Osuch <osuchj@avalon.net> writes:

No, the DOS image looks different. Part of the problem with this one is that the formula is not written correctly. There should be a |z| on the last line, otherwise the value of z is not what is expected at the time of bailout. I know the formula looks like it shouldn't make any difference, but the internal workings of the parser (I don't remember the details) makes strange things happen.

I'm not sure what change you're suggesting to the formula. This is what Jim Muth used: frm:Mystic2 {; Jim Muth a=real(p1), b=imag(p1), c=real(p2), d=imag(p2), k=real(p3), f=imag(p3), g=pixel, z=(pixel)^a+(b*(pixel))^c: z=(fn1(z)+(d*(g)))^k+(f*(cos(g))) g=sqr(g), LastSqr <= 100 } Can you post how it should be changed? -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/> Legalize Adulthood! <http://legalizeadulthood.wordpress.com>

In article <1278715250.1718.3.camel@jonathan-desktop>, Jonathan Osuch <osuchj@avalon.net> writes:

I believe that any attempt to "fix" Jim's formula will break any images he has created with it. I look forward to being proven wrong.

OK, well I was just trying to understand more concretely your |z| comment. I tried adding |z| to the last line, but it didn't seem to make any difference in the image. Besides, I thought the whole reset=NNNN thing was designed to handle backwards compatability? -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/> Legalize Adulthood! <http://legalizeadulthood.wordpress.com>

In article <1278856422.2809.29.camel@jonathan-desktop>, Jonathan Osuch <osuchj@avalon.net> writes:

This par has periodicity=0, so the next statements don't matter. Periodicity uses the value of z to determine when to bailout. The Mystic2 formula uses LastSqr for determining when to bailout, which in this instance is g.x^2 + g.y^2. Therefore, periodicity would calculate bailout based on the wrong variable.

Interesting. So why does it render correctly on the DOS parser?

There *is* a problem with the Xfractint formula parser. Try setting inside=zmag with this par. I get a segmentation fault.

What does the DOS version do? Something correct, or just something not crashy?

Also, for some reason the inside= options are not bailing out with the correct iteration count. This ties back to the problem seen in the colors with The_Layered_Look.

This is good; it feels like we are getting closer to understanding the real problem. -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/> Legalize Adulthood! <http://legalizeadulthood.wordpress.com>

In article <1278891483.2809.159.camel@jonathan-desktop>, Jonathan Osuch <osuchj@avalon.net> writes:

Rich,

...

...

This par has periodicity=0, so the next statements don't matter. Periodicity uses the value of z to determine when to bailout. The Mystic2 formula uses LastSqr for determining when to bailout, which in this instance is g.x^2 + g.y^2. Therefore, periodicity would calculate bailout based on the wrong variable.

Interesting. So why does it render correctly on the DOS parser?

Because periodicity is not being used, there is no effect due to this "error" in the design of the formula.

So if I turn periodicity off, I'll get a correct rendering on xfractint? -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/> Legalize Adulthood! <http://legalizeadulthood.wordpress.com>

Rich, No, setting periodicity=0 is what turns it off. Removing the setting sets periodicity checking to its default value of 1. Periodicity checking is always relevant with inside pixels because it determines whether or not we can bailout early, or if we have to wait until maxiter is reached. This is done by comparing orbit values. If the orbits are at the same point or are converging on a point, then the orbits will never escape and we can claim victory and bailout early. In this par, with periodicity=0, no periodicity checking is done and all the inside pixels should have all maxiter (90) orbits calculated. For some reason, the bailout value is reached (or an overflow occurs) after two iterations. Jonathan

...

This par has periodicity=0, so the next statements don't matter.

Removing periodicity=0 doesn't seem to have any effect. I thought the periodicity setting would only be relevant if inside=per? This parset uses inside=bof61.

Rich, If periodicity is used with this formula, it can/will cause a problem. It is not causing the problem we are seeing. I don't really know what is causing the problem yet. It could be that the functions coded in fpu087.c do not have sufficient error checking. Just a guess at this point, although these functions replace the ones used by the C parser in DOS. Jonathan

...

This par has periodicity=0, so the next statements don't matter. Periodicity uses the value of z to determine when to bailout. The Mystic2 formula uses LastSqr for determining when to bailout, which in this instance is g.x^2 + g.y^2. Therefore, periodicity would calculate bailout based on the wrong variable.

Can you reword the above in another way so that I can understand the issue?

When I read the above it seems to be saying that periodicity checking is causing the problem. But periodicity checking is turned off.

Rich, Yes, if periodicity checking is on, there is a technical problem with how the bailout condition as written and how periodicity is checked. Periodicity checking should not change the appearance of an image, it should just speed up the calculation of the image. But with this formula, the periodicity checking could cause the bailout to occur at different pixels. There are other problems, however. See below. Yes, this is documented. Perhaps not enough, and I don't know what the tutorial says about this. Yes, this is also a side-effect of the current parser implementation. No, it is not a bug. It is not possible to force users to always write "technically" correct formulas. The parser puts certain predefined variables into an array of complex pairs of numbers. Some of these variables are pixel, p1-p5, z, LastSqr, pi, e, and rand. The parser always knows where to find these variables. For example, z is v[3]. The location of user defined variables is not set. The parser puts the value of z into the complex variables old and new at the end of the iteration or when the bailout condition is reached. There is no way for the parser to know when z is not being used in the bailout condition. The value of new is then used to calculate the inside and outside colors for options that are not based on the iteration count. This causes the other problems. Since z (new) and the bailout condition are not tied together, the generated image using options other than those based on iteration count is not "technically" correct. However, I don't think it matters if a pleasing image is generated. I don't believe this disconnect between z and the bailout condition is causing the problem we are seeing. Jonathan

Ah, OK, I think the fog is clearing now. If periodicity checking is on, there will be a problem due to the way the bailout condition is written, right?

Is this something that is documented or is it just a side-effect of the current parser implementation?

In other words, is this problem between periodicity checking and the bailout condition a separate bug?

Rich, I would state it in stronger terms. Periodicity checking is always done on the z variable, regardless of the bailout condition. This applies to most of the inside/outside coloring options, also. The inside/outside options always use the z variable, except when the iteration count or a constant value is being used for the inside/outside coloring. Jonathan

Can we say that periodicity checking should always be done on the z variable, regardless of the bailout condition?

Rich, Yes, that is correct. This would fix the formula and probably break any images previously generated with it. Jonathan

So for this particular formula, since it uses LastSqr (of a variable that isn't z) for its bailout, to be compatible with periodicity checking it needs to have the variables renamed so that the bailout condition uses LastSqr of z and not this other variable.

Is that right?

Rich, Periodicity checking is just one of the options affected by "incorrectly" using the z variable. This par is a great example. It uses inside=bof61, which colors the inside pixels based on the value of min_index. The value of min_index is determined by: if (magnitude < min_orbit) { min_orbit = magnitude; min_index = coloriter + 1; } So, anything that changes the value of magnitude, will change the value of min_index. Magnitude is calculated for the formula type with: magnitude = sqr(new.x) + sqr(new.y); Where new.x is obtained from z.x and new.y is obtained from z.y. If the way z is used in the formula is changed, the image is going to change. The only safe options are inside=numb, inside=iter, outside=numb, and outside=iter. All other inside and outside options use new.x and/or new.y. The distance estimator, potential, and biomorph options also use new.x and new.y. So, it is possible to create images that won't be affected by fixing this formula. But for currently existing parameter sets, odds are, more images will be broken than remain the same. Jonathan

...

Yes, that is correct. This would fix the formula and probably break any images previously generated with it.

OK, the first part I understand, but I don't understand why this would break any images previously generated. Or did you mean that it would break any previously generated image that erroneously used periodicity checking? If periodicity checking was off (as it was on this parset for the FOTD), then I would expect the image to be the same.

In article <1279676849.1833.61.camel@jonathan-desktop>, Jonathan Osuch <osuchj@avalon.net> writes:

Periodicity checking is just one of the options affected by "incorrectly" using the z variable.

Is this something we could detect and warn the user about? For instance, detecting formulas that don't use z in the bailout condition and warning about possible improper interaction with periodicity checking, or detecting formulas that interact poorly with other options besides periodicity checking and warning when the uesr attempts to use those options? -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/> Legalize Adulthood! <http://legalizeadulthood.wordpress.com>

In article <1280058870.1753.9.camel@jonathan-desktop>, Jonathan Osuch <osuchj@avalon.net> writes:

This feature should only need to be used by someone writing a formula.

There isn't any way to distinguish between a person writing a formula and a person using a formula.

A user that is just creating an image from someone else's formula should not have to endure messages that the formula could be broken.

Perhaps then the "broken" options should be turned off when such a formula is used? -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/> Legalize Adulthood! <http://legalizeadulthood.wordpress.com>

Rich, The problem appears to be that matherr() is not implemented for Xfractint. Unfortunately, although using matherr() is supported by glibc, it is now obsolete. I've tried to get it running, but have had no luck so far. The DOS version must be catching the math errors, setting the result to a default value, and then continuing with the calculation. This removes the nan's and inf's I'm seeing in Xfractint and allows the calculation to continue until the bailout value is reached. Jonathan

Rich, The nan's and inf's show up when the ComplexPower() routine in mpmath_c.c is called. This is the routine that gets called by dStkPwr() in parser.c. I added a printf() statement to show the inputs and outputs. We have a line in unixscr.c that looks like this: signal(SIGFPE, fpe_handler); The fpe_handler() routine in general.c just sets overflow to 1. This doesn't appear to be working either. The value of overflow in the while loop in StandardFractal() in calcfrac.c is always equal to 0 when running this formula. Jonathan

...

The DOS version must be catching the math errors, setting the result to a default value, and then continuing with the calculation. This removes the nan's and inf's I'm seeing in Xfractint and allows the calculation to continue until the bailout value is reached.

Is it the formula evaluation that results in nan's and inf's?

Rich,

...

We have a line in unixscr.c that looks like this:

signal(SIGFPE, fpe_handler);

Don't you have to do a little extra magic on x86 to have a floating point exception generated by this stuff? Maybe there's a gcc flag to control it. IIRC, the default is *not* to generate FPEs for nan's and inf's.

Yes, you are correct. Our signal() line is doing nothing. I did try compiling with -fexceptions and -fsignaling-nans, but didn't see any difference. OTOH, what I've read online indicates that this signal doesn't actually do what we expect. It seems to deal more with integer exceptions. After implementing matherr(), starting Xfractint with a debugflag set should create a matherr file if any errors are being caught. This file never shows up when running this PAR. So, I tried it with Fractint, and there is no matherr file generated there either. So, I started adding sanity checks in the complex number sin/cos/exp/log functions in fpu087.c using isnan(), islessequal, and isinf() macros (built into gcc). All of the nan's and most of the inf's have been eliminated. What I'm looking at now is coding the builtin exp() function similar to how the FPU has to calculate it FPUcplxexp387() in fpu387.asm. This will slow down the calculation, but should eliminate the errors. Jonathan

Rich,

What I'm looking at now is coding the builtin exp() function similar to how the FPU has to calculate it FPUcplxexp387() in fpu387.asm. This will slow down the calculation, but should eliminate the errors.

Grrr. This didn't work. Don't know why. I did manage to eliminate all the inf's. Unfortunately, the image still does not look like the DOS version. This formula is behaving like the value of z is not getting passed from the parser code to the StandardFractal() code. This doesn't explain why the bottom of the image looks okay, however. Jonathan