I see this code in fractalp.c: /* type math orbitcalc fnct per_pixel fnct per_image fnct |-----|----|--------------|--------------|--------------| */ struct alternatemathstuff alternatemath[] = { #define USEBN #ifdef USEBN {JULIAFP, 1,JuliabnFractal,juliabn_per_pixel, MandelbnSetup}, {MANDELFP,1,JuliabnFractal,mandelbn_per_pixel, MandelbnSetup}, #else {JULIAFP, 2,JuliabfFractal,juliabf_per_pixel, MandelbfSetup}, {MANDELFP,2,JuliabfFractal,mandelbf_per_pixel, MandelbfSetup}, #endif /* NOTE: The default precision for bf_math=BIGNUM is not high enough for JuliaZpowerbnFractal. If you want to test BIGNUM (1) instead of the usual BIGFLT (2), then set bfdigits on the command to increase the precision. */ {FPJULIAZPOWER,2,JuliaZpowerbfFractal,juliabf_per_pixel, MandelbfSetup }, {FPMANDELZPOWER,2,JuliaZpowerbfFractal,mandelbf_per_pixel, MandelbfSetup}, {-1, 0,NULL, NULL, NULL } }; The cross-reference reports that JuliabfFractal is unused as a result. I looked through the rest of the code and couldn't find any other reference to JuliabfFractal and USEBN isn't used anywhere else either. CVS says Tim added this code on revision 1.3. Tim, is the intention to ultimately remove the bf code in favor of the bn code? -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://www.xmission.com/~legalize/book/download/index.html> Legalize Adulthood! <http://blogs.xmission.com/legalize/>
Rich asked:
I see this code in fractalp.c: ... #define USEBN #ifdef USEBN
The cross-reference reports that JuliabfFractal is unused as a result. I looked through the rest of the code and couldn't find any other reference to JuliabfFractal and USEBN isn't used anywhere else either.
CVS says Tim added this code on revision 1.3.
Heh heh - subversion has a "blame" command that shows you exactly who is responsible for each line of code :-)
Tim, is the intention to ultimately remove the bf code in favor of the bn code?
No. The bf code has a greater dynamic range than bn code and we should keep it. I revisited arbitrary precision last summer after a long hiatus in support of a new fractal type I'm working on. If that define is from last summer and not in any of Jonathan's public developer versions, it's just an experiment that I was doing. I would like that julia bn logic to remain but the USEBN define could be commented out so the logic for the arbitrary precision types reverts to bf math as it was. Tim
In article <45843DB8.6496.CA434@twegner.swbell.net>, "Tim Wegner" <twegner@swbell.net> writes:
CVS says Tim added this code on revision 1.3.
Heh heh - subversion has a "blame" command that shows you exactly who is responsible for each line of code :-)
CVS has "annotate" that shows you line-by-line the revision where that line was modified and who did the commit :-).
No. The bf code has a greater dynamic range than bn code and we should keep it. I revisited arbitrary precision last summer after a long hiatus in support of a new fractal type I'm working on. If that define is from last summer and not in any of Jonathan's public developer versions, it's just an experiment that I was doing. I would like that julia bn logic to remain but the USEBN define could be commented out so the logic for the arbitrary precision types reverts to bf math as it was.
Well, its in the HEAD, so that's the way its "shipping" right now. I'll comment out the #define USEBN on my branch. Thanks. -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://www.xmission.com/~legalize/book/download/index.html> Legalize Adulthood! <http://blogs.xmission.com/legalize/>
Rich,
Well, its in the HEAD, so that's the way its "shipping" right now. I'll comment out the #define USEBN on my branch. Thanks.
If you take a look at the history you'll see that I tried this to make the WinFract code work and it broke the Xfractint code. So I put it back in. We need to understand how each of the different environments are using the AP math routines so that all the environments can use them. Jonathan
In article <1166360272.3539.8.camel@linux.site>, Jonathan Osuch <osuchj@avalon.net> writes:
If you take a look at the history you'll see that I tried this to make the WinFract code work and it broke the Xfractint code. So I put it back in. We need to understand how each of the different environments are using the AP math routines so that all the environments can use them.
Ah, OK. I think in order to tackle that I'll need to understand the arbitrary precision infrastructure that we have now. Currently I've just been ignoring that and anything really to do with the engine as I'm focused on the I/O portions. -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://www.xmission.com/~legalize/book/download/index.html> Legalize Adulthood! <http://blogs.xmission.com/legalize/>
participants (3)
-
Jonathan Osuch -
Richard -
Tim Wegner