Jonathan, In rectangle orbitdraw mode, using "maintain screen coordinates": The <F6> image coordinates get munged when changing anything at the <F2> screen coordinates prompt, provided the <F6> image coordinates had a non-zero rotation and/or skew angle. The <F6> coordinates "lose" their original angle/skew data, and magnification and x-magnification are grossly different than before. Below I've included the part of the source where (I think) the mistake has been made (unaltered save the four additional comments pointing to the offending lines). Regards, Gerald -------------------------------- 8< ------------------------------------ File: prompts2.c Line: 2347 In: get_screen_corners() svxxmin = xxmin; /* save these for later since cvtcorners modifies them */ svxxmax = xxmax; /* and we need to set them for cvtcentermag to work */ svxx3rd = xxmin; /* <-- xx3rd instead of xxmin ? */ svyymin = yymin; svyymax = yymax; svyy3rd = yymin; /* <-- yy3rd instead of yymin ? */ if (!set_orbit_corners && !keep_scrn_coords) { oxmin = xxmin; oxmax = xxmax; ox3rd = xxmin; /* <-- xx3rd instead of xxmin ? */ oymin = yymin; oymax = yymax; oy3rd = yymin; /* <-- yy3rd instead of yymin ? */ } -------------------------------- 8< ------------------------------------
Gerald,
In rectangle orbitdraw mode, using "maintain screen coordinates":
The <F6> image coordinates get munged when changing anything at the <F2> screen coordinates prompt, provided the <F6> image coordinates had a non-zero rotation and/or skew angle.
The <F6> coordinates "lose" their original angle/skew data, and magnification and x-magnification are grossly different than before.
Below I've included the part of the source where (I think) the mistake has been made (unaltered save the four additional comments pointing to the offending lines).
Thanks, I'll have a look. There is a reason I coded it that way, but I don't recall what it is. Jonathan
Jonathan Osuch wrote:
[...] There is a reason I coded it that way, [...]
I guessed as much, thinking "xx3rd" and "yy3rd" might well be invalid at that point (because possibly modified elsewhere). But an occasional peek into the source is far from enough to know what's really going on. Glad you still find time to maintain Fractint. Regards, Gerald
Gerald,
[...] There is a reason I coded it that way, [...]
I guessed as much, thinking "xx3rd" and "yy3rd" might well be invalid at that point (because possibly modified elsewhere). But an occasional peek into the source is far from enough to know what's really going on.
But sometimes it's good enough. I made the change and it seems to work fine as long as "maintain screen coordinates" is set to yes. I changed the default for this variable to yes, which makes more sense anyway. All I can say is that it made sense at the time. Thanks.
Glad you still find time to maintain Fractint.
I need to make it easier to zoom the screen size, since it has to be done by hand now. I would like to put version 20.5 on the streets as an official release. The docs need a lot of help and I'm sure I messed up the demo files with my last patch and the source restructuring. The release file will look like the current zip file, so if there are any files missing, they need to be added (duh!). Jonathan
Jonathan wrote:
I would like to put version 20.5 on the streets as an official release. The docs need a lot of help and I'm sure I messed up the demo files with my last patch and the source restructuring.
I have been thinking along the same lines. The docs work is not to be underestimated, but maybe we can enlist some help. It's time to get rid of the scrolling initial screen and maybe put the list in the docs with just the names (no emails, they are mostly defunct anyway). I'm willing to put some time on this. Tim
Hi Tim, In doing some exploring between Fractint and Ultrafractal, I have found what I think are some errors in Fractint. The first one involves MarksMandel. The error here is in the documentation. The documentation has the formula as z -> (c^exp-1)*z^2 + c It should actually be z -> c^(exp-1)*z^2 +c This can be readily verified by coding both ways in Ultrafractal and comparing to the built-in MarksMandel formula in Fractint. The other apparent error is for the built-in Hypercomplex formula with the function being sqr. If cj = 0.1 or ck = 0.1 the image agrees with what I get in my UF formula using your hypercomplex code. If BOTH cj = 0.1 and ck = 0.1, the images are different. The built-in Fractint formula forces symmetry around the x axis, and the correct image is not symmetrical. Cheers, Ron Barnett
Hi Tim, I forgot to add, a slight rotation of the Fractint image for hypercomplex with sqr as the function and cj = 0.1, ck = 0.1 will break the symmetry so that now the correct image will be displayed. Ron -----Original Message----- From: fractdev-bounces+fractals=hiddendimension.com@mailman.xmission.com [mailto:fractdev-bounces+fractals=hiddendimension.com@mailman.xmission.c om]On Behalf Of Ron Barnett Sent: Wednesday, July 13, 2005 12:45 PM To: Fractint developer's list Subject: [Fractdev] Couple of probable Fractint errors Hi Tim, In doing some exploring between Fractint and Ultrafractal, I have found what I think are some errors in Fractint. The first one involves MarksMandel. The error here is in the documentation. The documentation has the formula as z -> (c^exp-1)*z^2 + c It should actually be z -> c^(exp-1)*z^2 +c This can be readily verified by coding both ways in Ultrafractal and comparing to the built-in MarksMandel formula in Fractint. The other apparent error is for the built-in Hypercomplex formula with the function being sqr. If cj = 0.1 or ck = 0.1 the image agrees with what I get in my UF formula using your hypercomplex code. If BOTH cj = 0.1 and ck = 0.1, the images are different. The built-in Fractint formula forces symmetry around the x axis, and the correct image is not symmetrical. Cheers, Ron Barnett _______________________________________________ Fractdev mailing list Fractdev@mailman.xmission.com http://mailman.xmission.com/cgi-bin/mailman/listinfo/fractdev
Hi Ron, good to hear from you. Ron wrote:
The first one involves MarksMandel. The error here is in the documentation.
The documentation has the formula as
z -> (c^exp-1)*z^2 + c
It should actually be
z -> c^(exp-1)*z^2 +c
You are correct. I know because I checked the actual code - comparing with ultrafractal (or any other program) isn't a reliable way to know what's right. (I run into this at my work at NASA all the time.) We'll fix the docs.
If cj = 0.1 or ck = 0.1 the image agrees with what I get in my UF formula using your hypercomplex code. If BOTH cj = 0.1 and ck = 0.1, the images are different. The built-in Fractint formula forces symmetry around the x axis, and the correct image is not symmetrical.
Forcing symmetry is an attempt to save a lot of processing tgime, but is not guaranteed to be correct. There are a number of fractals with parameter combinations that break the symmetry. I'd say "it's a feature". The only sure way to get the correct image is to turn off symmetry. I'm sure this disclaimer is documented somewhere, but if not, we should add it Tim
Ron,
The other apparent error is for the built-in Hypercomplex formula with the function being sqr.
If cj = 0.1 or ck = 0.1 the image agrees with what I get in my UF formula using your hypercomplex code. If BOTH cj = 0.1 and ck = 0.1, the images are different. The built-in Fractint formula forces symmetry around the x axis, and the correct image is not symmetrical.
This works fine for me. Symmetry with cj = 0.1 or ck = 0.1, and no symmetry when they are both 0.1. Is it possible you have a symmetry=xaxis statement in your sstools.ini file? Jonathan
Jonathan, I just checked my sstools.ini, and there are no symmetry statements in it. I am running version 20.02 - developers version. Could that be the problem? Ron -----Original Message----- From: fractdev-bounces+fractals=hiddendimension.com@mailman.xmission.com [mailto:fractdev-bounces+fractals=hiddendimension.com@mailman.xmission.c om]On Behalf Of Jonathan Osuch Sent: Wednesday, July 13, 2005 8:41 PM To: Fractint Developer's List Subject: Re: [Fractdev] Couple of probable Fractint errors Ron,
The other apparent error is for the built-in Hypercomplex formula with the function being sqr.
If cj = 0.1 or ck = 0.1 the image agrees with what I get in my UF formula using your hypercomplex code. If BOTH cj = 0.1 and ck = 0.1, the images are different. The built-in Fractint formula forces symmetry around the x axis, and the correct image is not symmetrical.
This works fine for me. Symmetry with cj = 0.1 or ck = 0.1, and no symmetry when they are both 0.1. Is it possible you have a symmetry=xaxis statement in your sstools.ini file? Jonathan _______________________________________________ Fractdev mailing list Fractdev@mailman.xmission.com http://mailman.xmission.com/cgi-bin/mailman/listinfo/fractdev
Ron,
I just checked my sstools.ini, and there are no symmetry statements in it. I am running version 20.02 - developers version. Could that be the problem?
No, that's not the problem. What could be causing the problem is if you are running a PAR that sets symmetry before you run your test. Symmetry is one of those parameters that is very difficult to unset. Using the <INSERT> key, which resets Fractint, is one way. If not the only way, without restarting Fractint. Jonathan
Jonathan, The problem occurs when I start Fractint up fresh and run the built-in hypercomplex formula. There was no PAR involved, and no file saved. Ron -----Original Message----- From: fractdev-bounces+fractals=hiddendimension.com@mailman.xmission.com [mailto:fractdev-bounces+fractals=hiddendimension.com@mailman.xmission.c om]On Behalf Of Jonathan Osuch Sent: Thursday, July 14, 2005 6:55 PM To: Fractint Developer's List Subject: RE: [Fractdev] Couple of probable Fractint errors Ron,
I just checked my sstools.ini, and there are no symmetry statements in it. I am running version 20.02 - developers version. Could that be the problem?
No, that's not the problem. What could be causing the problem is if you are running a PAR that sets symmetry before you run your test. Symmetry is one of those parameters that is very difficult to unset. Using the <INSERT> key, which resets Fractint, is one way. If not the only way, without restarting Fractint. Jonathan _______________________________________________ Fractdev mailing list Fractdev@mailman.xmission.com http://mailman.xmission.com/cgi-bin/mailman/listinfo/fractdev
Ron,
The problem occurs when I start Fractint up fresh and run the built-in hypercomplex formula. There was no PAR involved, and no file saved.
Please create three PARs for me. One with xj = 0.1, one with xk = 0.1, and one with both xj and xk = 0.1. If symmetry has been set, it will show up in the PARs. Thanks. Jonathan
Jonathan Osuch wrote: [...]
Symmetry is one of those parameters that is very difficult to unset. Using the <INSERT> key, which resets Fractint, is one way. If not the only way, without restarting Fractint.
Unless I'm mistaken, "<g> symmetry=none <ENTER>" should work too, right? Gerald
Gerald,
[...]
Symmetry is one of those parameters that is very difficult to unset. Using the <INSERT> key, which resets Fractint, is one way. If not the only way, without restarting Fractint.
Unless I'm mistaken, "<g> symmetry=none <ENTER>" should work too, right?
Actually, that doesn't unset it. It does turn symmetry off for all subsequently generated fractals, but that isn't always what is wanted. To have symmetry function normally, it is necessary to restart Fractint, either with <INSERT> or by exiting and starting fresh. What we should see in the current hypercomplex example is: xj = 0.1 appears symmetrical, but doesn't use symmetry to calculate xk = 0.1 uses symmetry xj = xk = 0.1 is not symmetrical The reason for this is that a value in xj turns off the xaxis symmetry. Jonathan
Jonathan, Gerald, Hitting <INSERT> to reset Fractint does not solve the problem. The only thing that works is to put the line symmetry=none in the sstools.ini file. I then removed the line from the sstools.ini file and the problem came right back. Test4, which should not be symmetrical, is on my system. Here are the pars: test1 { ; Copyright Ron Barnett Jul 2005 t= 0:00:06.32 ; www.hiddendimension.com fractals@hiddendimension.com ; On a Pentium III(667) at 1280 x 1024 reset=2002 type=hypercomplex function=sqr center-mag=0/0/0.6666667 params=0/0/0/0 float=y maxiter=1024 inside=0 periodicity=0 sound=off colors=00000e0e00eee00e0eeL0eeeLLLLLzLzLLzzzLLzLzzzLzzz000555<3>HHHKKKOO\ O<3>ccchhhmmmssszzz00z<3>z0z<3>z00<3>zz0<3>0z0<3>0zz<2>0GzVVz<3>zVz<3>zV\ V<3>zzV<3>VzV<3>Vzz<2>Vbzhhz<3>zhz<3>zhh<3>zzh<3>hzh<3>hzz<2>hlz00S<3>S0\ S<3>S00<3>SS0<3>0S0<3>0SS<2>07SEES<3>SES<3>SEE<3>SSE<3>ESE<3>ESS<2>EHSKK\ S<2>QKSSKSSKQSKOSKMSKK<2>SQKSSKQSKOSKMSKKSK<2>KSQKSSKQSKOSKMS00G<3>G0G<3\
G00<3>GG0<3>0G0<3>0GG<2>04G88G<2>E8GG8GG8EG8CG8AG88<2>GE8GG8EG8CG8AG88G\ 8<2>8GE8GG8EG8CG8AGBBG<2>FBGGBGGBFGBDGBCGBB<2>GFBGGBFGBDGBCGBBGB<2>BGFBG\ GBFGBDGBCG000<6>000 }
test2 { ; Copyright Ron Barnett Jul 2005 t= 0:00:05.72 ; www.hiddendimension.com fractals@hiddendimension.com ; On a Pentium III(667) at 1280 x 1024 reset=2002 type=hypercomplex function=sqr center-mag=0/0/0.6666667 params=0/0/0.1/0 float=y maxiter=1024 inside=0 periodicity=0 sound=off colors=00000e0e00eee00e0eeL0eeeLLLLLzLzLLzzzLLzLzzzLzzz000555<3>HHHKKKOO\ O<3>ccchhhmmmssszzz00z<3>z0z<3>z00<3>zz0<3>0z0<3>0zz<2>0GzVVz<3>zVz<3>zV\ V<3>zzV<3>VzV<3>Vzz<2>Vbzhhz<3>zhz<3>zhh<3>zzh<3>hzh<3>hzz<2>hlz00S<3>S0\ S<3>S00<3>SS0<3>0S0<3>0SS<2>07SEES<3>SES<3>SEE<3>SSE<3>ESE<3>ESS<2>EHSKK\ S<2>QKSSKSSKQSKOSKMSKK<2>SQKSSKQSKOSKMSKKSK<2>KSQKSSKQSKOSKMS00G<3>G0G<3\
G00<3>GG0<3>0G0<3>0GG<2>04G88G<2>E8GG8GG8EG8CG8AG88<2>GE8GG8EG8CG8AG88G\ 8<2>8GE8GG8EG8CG8AGBBG<2>FBGGBGGBFGBDGBCGBB<2>GFBGGBFGBDGBCGBBGB<2>BGFBG\ GBFGBDGBCG000<6>000 }
test3 { ; Copyright Ron Barnett Jul 2005 t= 0:00:12.47 ; www.hiddendimension.com fractals@hiddendimension.com ; On a Pentium III(667) at 1280 x 1024 reset=2002 type=hypercomplex function=sqr center-mag=0/0/0.6666667 params=0/0/0/0.1 float=y maxiter=1024 inside=0 periodicity=0 sound=off colors=00000e0e00eee00e0eeL0eeeLLLLLzLzLLzzzLLzLzzzLzzz000555<3>HHHKKKOO\ O<3>ccchhhmmmssszzz00z<3>z0z<3>z00<3>zz0<3>0z0<3>0zz<2>0GzVVz<3>zVz<3>zV\ V<3>zzV<3>VzV<3>Vzz<2>Vbzhhz<3>zhz<3>zhh<3>zzh<3>hzh<3>hzz<2>hlz00S<3>S0\ S<3>S00<3>SS0<3>0S0<3>0SS<2>07SEES<3>SES<3>SEE<3>SSE<3>ESE<3>ESS<2>EHSKK\ S<2>QKSSKSSKQSKOSKMSKK<2>SQKSSKQSKOSKMSKKSK<2>KSQKSSKQSKOSKMS00G<3>G0G<3\
G00<3>GG0<3>0G0<3>0GG<2>04G88G<2>E8GG8GG8EG8CG8AG88<2>GE8GG8EG8CG8AG88G\ 8<2>8GE8GG8EG8CG8AGBBG<2>FBGGBGGBFGBDGBCGBB<2>GFBGGBFGBDGBCGBBGB<2>BGFBG\ GBFGBDGBCG000<6>000 }
test4 { ; Copyright Ron Barnett Jul 2005 t= 0:00:18.07 ; www.hiddendimension.com fractals@hiddendimension.com ; On a Pentium III(667) at 1280 x 1024 reset=2002 type=hypercomplex function=sqr center-mag=0/0/0.6666667 params=0/0/0.1/0.1 float=y maxiter=1024 inside=0 periodicity=0 sound=off colors=00000e0e00eee00e0eeL0eeeLLLLLzLzLLzzzLLzLzzzLzzz000555<3>HHHKKKOO\ O<3>ccchhhmmmssszzz00z<3>z0z<3>z00<3>zz0<3>0z0<3>0zz<2>0GzVVz<3>zVz<3>zV\ V<3>zzV<3>VzV<3>Vzz<2>Vbzhhz<3>zhz<3>zhh<3>zzh<3>hzh<3>hzz<2>hlz00S<3>S0\ S<3>S00<3>SS0<3>0S0<3>0SS<2>07SEES<3>SES<3>SEE<3>SSE<3>ESE<3>ESS<2>EHSKK\ S<2>QKSSKSSKQSKOSKMSKK<2>SQKSSKQSKOSKMSKKSK<2>KSQKSSKQSKOSKMS00G<3>G0G<3\
G00<3>GG0<3>0G0<3>0GG<2>04G88G<2>E8GG8GG8EG8CG8AG88<2>GE8GG8EG8CG8AG88G\ 8<2>8GE8GG8EG8CG8AGBBG<2>FBGGBGGBFGBDGBCGBB<2>GFBGGBFGBDGBCGBBGB<2>BGFBG\ GBFGBDGBCG000<6>000 }
-----Original Message----- From: fractdev-bounces+fractals=hiddendimension.com@mailman.xmission.com [mailto:fractdev-bounces+fractals=hiddendimension.com@mailman.xmission.c om]On Behalf Of Jonathan Osuch Sent: Thursday, July 14, 2005 9:46 PM To: Fractint Developer's List Subject: Re: [Fractdev] Couple of probable Fractint errors Gerald,
[...]
Symmetry is one of those parameters that is very difficult to unset. Using the <INSERT> key, which resets Fractint, is one way. If not the only way, without restarting Fractint.
Unless I'm mistaken, "<g> symmetry=none <ENTER>" should work too, right?
Actually, that doesn't unset it. It does turn symmetry off for all subsequently generated fractals, but that isn't always what is wanted. To have symmetry function normally, it is necessary to restart Fractint, either with <INSERT> or by exiting and starting fresh. What we should see in the current hypercomplex example is: xj = 0.1 appears symmetrical, but doesn't use symmetry to calculate xk = 0.1 uses symmetry xj = xk = 0.1 is not symmetrical The reason for this is that a value in xj turns off the xaxis symmetry. Jonathan _______________________________________________ Fractdev mailing list Fractdev@mailman.xmission.com http://mailman.xmission.com/cgi-bin/mailman/listinfo/fractdev
Ron,
Hitting <INSERT> to reset Fractint does not solve the problem. The only thing that works is to put the line symmetry=none in the sstools.ini file. I then removed the line from the sstools.ini file and the problem came right back. Test4, which should not be symmetrical, is on my system. Here are the pars:
I am sorry! I finally took the time to look through the changes made since version 20.2. One of the things that I fixed with version 20.3 was the hypercomplex symmetry. That shows how good my memory is! Yikes! Jonathan
Jonathan Osuch wrote:
Actually, that doesn't unset it. It does turn symmetry off for all subsequently generated fractals, but that isn't always what is wanted.
Ah, yes. "Go back to fractal type specific symmetry settings" instead of "skip all symmetry calculations from now on". Gerald
Jonathan, Ron...
Ron,
I just checked my sstools.ini, and there are no symmetry statements in it. I am running version 20.02 - developers version. Could that be the problem?
No, that's not the problem.
Jonathan, this _is_ the problem.
From the current fractint.doc:
"Version 20.3.0 [...] Fixed hypercomplex fractal type to turn off symmetry when a cj parameter is used." I don't have 20.2 installed, but checked old 19.6, which shows exactly the behavior Ron B. has reported. Ron, current developers version is 20.4 patch 2. Gerald
I downloaded 20.4 patch 2, and everything runs fine now - no symmetry problems. Ron -----Original Message----- From: fractdev-bounces+fractals=hiddendimension.com@mailman.xmission.com [mailto:fractdev-bounces+fractals=hiddendimension.com@mailman.xmission.c om]On Behalf Of Gerald K. Dobiasovsky Sent: Friday, July 15, 2005 8:07 PM To: Fractint developer's list Subject: Re: [Fractdev] Couple of probable Fractint errors Jonathan, Ron...
Ron,
I just checked my sstools.ini, and there are no symmetry statements in it. I am running version 20.02 - developers version. Could that be the problem?
No, that's not the problem.
Jonathan, this _is_ the problem.
From the current fractint.doc:
"Version 20.3.0 [...] Fixed hypercomplex fractal type to turn off symmetry when a cj parameter is used." I don't have 20.2 installed, but checked old 19.6, which shows exactly the behavior Ron B. has reported. Ron, current developers version is 20.4 patch 2. Gerald _______________________________________________ Fractdev mailing list Fractdev@mailman.xmission.com http://mailman.xmission.com/cgi-bin/mailman/listinfo/fractdev
Jonathan Osuch wrote:
[...] I made the change and it seems to work fine as long as "maintain screen coordinates" is set to yes. [...]
Are there any problems when it is set to "no"? I thought it was supposed to keep screen and image coordinates synchronised in that case.
I need to make it easier to zoom the screen size, since it has to be done by hand now.
Played around with those screen/image orbit features a bit and tended to do the following: Zooming in with "maintain..." set to no. Finding an interesting place, but wanting to move or zoom in/out the image coordinates alone... Now, switching to yes would revert the screen coordinates I want to keep. So I do <F2> instead, then change one of the numbers in the display(something that's easily remembered like erasing the last digit of, say, Center X). Pushing <Enter> causes "maintain..." to be switched to yes. Again <F2>, and putting that one erased digit back in resets screen coordinates to what they were before, and I can move/zoom the image coordinates alone. (Whew! After rereading the above the few key-presses sound awfully convoluted!) In short, it works for me even in its present form. :-) Regards, Gerald
Gerald,
[...] I made the change and it seems to work fine as long as "maintain screen coordinates" is set to yes. [...]
Are there any problems when it is set to "no"? I thought it was supposed to keep screen and image coordinates synchronised in that case.
No, it seems more logical to me, though, to maintain the screen coordinates while zooming the image coordinates.
I need to make it easier to zoom the screen size, since it has to be done by hand now.
Played around with those screen/image orbit features a bit and tended to do the following:
Zooming in with "maintain..." set to no. Finding an interesting place, but wanting to move or zoom in/out the image coordinates alone...
Now, switching to yes would revert the screen coordinates I want to keep.
Ach! It's not meant to do that. I'll have to take a look to see what has happened. You should be able to switch from one mode to the other without any change in either set of coordinates. I'll have a chance to look at it on Sunday. Jonathan
Gerald,
[...] I made the change and it seems to work fine as long as "maintain screen coordinates" is set to yes. [...]
Are there any problems when it is set to "no"? I thought it was supposed to keep screen and image coordinates synchronised in that case.
No, but I changed it back because it broke the few PAR's I have already made.
I need to make it easier to zoom the screen size, since it has to be done by hand now.
Played around with those screen/image orbit features a bit and tended to do the following:
Zooming in with "maintain..." set to no. Finding an interesting place, but wanting to move or zoom in/out the image coordinates alone...
Now, switching to yes would revert the screen coordinates I want to keep.
I've fixed this. I'm going to take a look at the files included (for an official release) and adjust as necessary, then I'll put out a patch. Should be in the next couple of days. Jonathan
participants (4)
-
Gerald K. Dobiasovsky -
Jonathan Osuch -
Ron Barnett -
Tim Wegner