knighty
Fractal Iambus
Posts: 819
|
|
« Reply #30 on: April 10, 2014, 07:03:45 PM » |
|
Thanks a lot. recently had this error when increasing zoom past E-2023
------------------------------ *** MPROUN: Exponent overflow. *** mpabrt: execution terminated, error code =69 Segmentation fault ------------------------------
Maybe because the number of digits is set to 2048 in main.cpp
|
|
|
Logged
|
|
|
|
3dickulus
|
|
« Reply #31 on: April 10, 2014, 07:15:43 PM » |
|
anticipated that and set it to 3192 @ around E-1800
I suspect it's in FillInCubic()
|
|
|
Logged
|
|
|
|
knighty
Fractal Iambus
Posts: 819
|
|
« Reply #32 on: April 10, 2014, 09:52:29 PM » |
|
Ok! Finally, it compiled successfully using Qt5.2. I used QOpenGLFunctions for OpenGL extensions. Nice application!
|
|
|
Logged
|
|
|
|
3dickulus
|
|
« Reply #33 on: April 10, 2014, 11:46:15 PM » |
|
cool re: FillInCubic() extra_exponent normally ticks down to 0 and all is well, the problem is when converting from AP number to DOUBLE number, ARPRECs mp_real::mpmdc(); function is supposed to take care of this... /// from mp_real to double source code /** * This procedure takes the mp_real A, and splits it into * a double, b, and a exponent, n. * * On exit, the following should be roughly true: * * a ==(roughly) b*2^n */ /// from mp_real to double source code for some reason "n" = -21474836481 when extra_exponent reaches around 101 before this "n" fluctuates between 0 and -720 I also had used mp_real::n_digits instead of mp_real::n_precwords in the mpmdc() but that didn't seem to have any effect, should be "1" erroneous values ignored?
|
|
« Last Edit: April 11, 2014, 12:04:50 AM by 3dickulus »
|
Logged
|
|
|
|
3dickulus
|
|
« Reply #34 on: April 12, 2014, 08:16:57 AM » |
|
cool re: FillInCubic() extra_exponent normally ticks down to 0 and all is well, the problem is when converting from AP number to DOUBLE number, ARPRECs mp_real::mpmdc(); function is supposed to take care of this... ... it was the Repeater test in CalculationManager class
|
|
|
Logged
|
|
|
|
3dickulus
|
|
« Reply #35 on: April 16, 2014, 04:24:45 PM » |
|
I see Pauldebrot has come up with something re:glitches that looks really interesting, in the mean time, here's some of my results, partial glitch solving. (gawdy colors accentuate blobs)
|
|
|
Logged
|
|
|
|
3dickulus
|
|
« Reply #36 on: May 14, 2014, 09:02:04 PM » |
|
I think I might be on to something... this is DD's "Flake" location rendered in 309.6 sec with my C++ port of SFT, reference point picked automagically. I have been working on getting the engine as tight as I can before I start playing with a CUDA version, it might be a while and may be abandoned for a whack at porting kallesfraktaler2 to Qt/linux I haven't posted the latest version of this code yet but if you want to play with it let me know and I'll make some time to zip it up.
|
|
|
Logged
|
|
|
|
3dickulus
|
|
« Reply #37 on: June 09, 2014, 12:57:04 AM » |
|
In porting SFT Java to C++ I'm reasonably sure that it's good because the C++ version reproduces all of the same glitches that the Java version shows. But before trying to implement glitch detection and correction I thought I would try a slightly different approach, that is, glitch avoidance through improved accuracy... This code computes the magnitude of a complex number and avoids overflow, returns between 0 and inf, I have used this routine to replace (x*x)+(y*y) in the Details class and the Approximation class. ( in theory this shouldn't work??? because it returns sqrt(x*x+y*y) but I'll let the result speak for itself ) /// compute the magnitude of a complex number. double Approximation::cMag(double re, double im) { double r;
re = fabs(re); im = fabs(im);
if (re > im) { r = fabs(im/re); return re*sqrt(1.0+r*r); }
if (im == 0.0) return 0.0;
r = fabs(re/im); return im*sqrt(1.0+r*r); }
I also replaced (x*x)-(y*y) with (x-y)*(x+y) because... "The expression x*x - y*y is more accurate when rewritten as (x - y)*(x + y) because a catastrophic cancellation is replaced with a benign one." These two changes allow rendering of "Flake" (above) and "Polished Emerald" (below) much more accurately when compared with the original SFT code. I wish I had more time and brains to dedicate to this but so far so good Edit: yes I know it's not perfect but it's better than the blob that the java code rendered
|
|
« Last Edit: July 25, 2014, 09:18:46 AM by 3dickulus »
|
Logged
|
|
|
|
3dickulus
|
|
« Reply #38 on: August 19, 2014, 02:12:58 PM » |
|
for the latest installment in the Y.A.M.Z. file I would like to thank knighty for the win version of arprec lib and help with getting the QtCreator project to compile and run on windows finally have Pauldebrot's glitch thing working, well, my version of it at least. SFTC63 yeah that's right, it took me 63 versions to go from the original java to Qt C++ and add auto glitch detection, still needs a few more incarnations but I'm very happy with it so far.
|
|
|
Logged
|
|
|
|
knighty
Fractal Iambus
Posts: 819
|
|
« Reply #39 on: August 19, 2014, 09:17:29 PM » |
|
You are welcome. And thank you for the new version. I think it would be nice to provide a compiled version for those who don't want to install Qt and compile the project by themselves.
|
|
|
Logged
|
|
|
|
3dickulus
|
|
« Reply #40 on: August 20, 2014, 12:53:32 AM » |
|
@knighty: I do understand that everyone can't just throw together a dev box to compile and run this code so I have posted your win bin version on my website. I don't usually like to distribute Windows binaries created with Qt because of the required DLLs, mine may not be the same as yours so they must be included in the zip. I would much rather encourage all to figure out how to compile the Qt project so each has a version that is optimized for their machine/arch/OS. The thing is, that the code changes soooo fast that there are tweaks (yes already) that are not in the win bin vers, like, adjusted the glitch detection range (will probably add a menu/option for user adjustment) because as a value bound to the screen size it gets sloppy with small 256x192 or large images > 2048x1536 Another reason for preferring a source only dist is that it encourages hacking cheers mate!
|
|
|
Logged
|
|
|
|
3dickulus
|
|
« Reply #41 on: August 20, 2014, 04:48:11 AM » |
|
for anyone hacking the source... 1. in file calculationmanager.cpp line 309 the count vs screensize test is working nicely like this... if(cnt > (mBuffer->GetWidth() >> 8)+1 ) { newXOffset=x; newYOffset=y; break; }
at a screen width of 256 this is checking for 2 adjacent pixels flagged in the previous pass as failed, any less and we get no change. edit:better but still not quite right, logic:blob on 512 screen would be twice as wide as on a 256 screen... 2. in file approximation.cpp line 409 the glitch flag test is working nicely @ < 1.0E-12 and > 1.0E6 I also changed it so that the next search for a reference starts looking where the last search found one... the possibilities are endless
|
|
« Last Edit: August 20, 2014, 03:51:20 PM by 3dickulus, Reason: still testing... »
|
Logged
|
|
|
|
knighty
Fractal Iambus
Posts: 819
|
|
« Reply #42 on: August 20, 2014, 09:43:30 PM » |
|
Ooops! I forgot to include "imageformats" and "platforms" directories to the package. I'll send you the updated package ASAP.
|
|
|
Logged
|
|
|
|
3dickulus
|
|
« Reply #43 on: August 20, 2014, 10:18:53 PM » |
|
Ooops! I forgot to include "imageformats" and "platforms" directories to the package. I'll send you the updated package ASAP.
...and that's why I like to encourage windows users to install Qt+MinGW, with that you can just load the project, compile it and make any adjustments you want to the GUI or source code. a real bonus is the tool kit that comes with Qt, Creator is a good IDE (handles other languages too) and Designer is really awesome for building GUIs, hardly have to type anything the "imageformats" and "platforms" that I have installed on the Win7 box probably won't work so if you are up for putting together the Windows package I'll host it on my server. I am currently fiddling with glitch detection, peanuts, large antlers and kidneys are easy but tiny antlers and single pixels are a bit more involved, v63 (currently on web site) is pretty good but needs improvement. Sometimes find a single pixel and re-render only find it's still there, I think it's because the x,y coords of a pixel are too coarse to nail the reference that may be at a sub-pixel level when working with lower screen resolutions, maybe need to try a couple of locations within a pixel to get the right ref. hack hack hack...
|
|
|
Logged
|
|
|
|
3dickulus
|
|
« Reply #44 on: August 21, 2014, 11:52:59 AM » |
|
The latest is SFTC64 with much improved glitch detection/correction... hack hack hack edit: I just finished running the comparison tests and v64 is a little faster than v63 I think in the CUDA version I will be able to use double double type in place of long double as GPU only does 64 bit math and not 80 bit, but that just means it will have more range before going to higher precision functions, fortunately GArPrec has DD and QD types for running on the GPU. GCC also has libquadmath.a that has __float128 and __complex128 types. some values from quadmath.h... #define FLT128_MAX 1.18973149535723176508575932662800702e4932Q #define FLT128_MIN 3.36210314311209350626267781732175260e-4932Q #define FLT128_EPSILON 1.92592994438723585305597794258492732e-34Q #define FLT128_DENORM_MIN 6.475175119438025110924438958227646552e-4966Q #define FLT128_MANT_DIG 113 #define FLT128_MIN_EXP (-16381) #define FLT128_MAX_EXP 16384 #define FLT128_DIG 33 #define FLT128_MIN_10_EXP (-4931) #define FLT128_MAX_10_EXP 4932
...adds the "Q" designation for using this type of number.
|
|
« Last Edit: August 21, 2014, 09:28:35 PM by 3dickulus, Reason: comparisons »
|
Logged
|
|
|
|
|