From: Richard C. Wagner <drsavage@q.com>  20100604 00:38:02

Hi All: Has anyone here made much use of MinGW with scientific or floating point calculations? I've written a Mandelbrot generator, and I'm seeing truncation errors at values far above where I expect them. Specifically, I'm taking an integer pixel coordinate from 0 to 640, converting it to a floating point number, dividing it by a floating point 640, and multiplying that result by another small float, in this case, 9.0e6. And the answer doesn't change with each increment of the first number. I've written a standalone test program doing just this calculation and here are the results: Pixel_x = 100 Domain_x = 1.00000143051147460000 Pixel_x = 101 Domain_x = 1.00000143051147460000 Pixel_x = 102 Domain_x = 1.00000143051147460000 Pixel_x = 103 Domain_x = 1.00000143051147460000 Pixel_x = 104 Domain_x = 1.00000143051147460000 Pixel_x = 105 Domain_x = 1.00000143051147460000 Pixel_x = 106 Domain_x = 1.00000154972076420000 Pixel_x = 107 Domain_x = 1.00000154972076420000 Pixel_x = 108 Domain_x = 1.00000154972076420000 Pixel_x = 109 Domain_x = 1.00000154972076420000 Pixel_x = 110 Domain_x = 1.00000154972076420000 Pixel_x = 111 Domain_x = 1.00000154972076420000 Pixel_x = 112 Domain_x = 1.00000154972076420000 Pixel_x = 113 Domain_x = 1.00000154972076420000 Pixel_x = 114 Domain_x = 1.00000154972076420000 Pixel_x = 115 Domain_x = 1.00000166893005370000 Pixel_x = 116 Domain_x = 1.00000166893005370000 Pixel_x = 117 Domain_x = 1.00000166893005370000 Pixel_x = 118 Domain_x = 1.00000166893005370000 Pixel_x = 119 Domain_x = 1.00000166893005370000 If you're interested, I can post the code. These results are far grainier, numerically, than they hardware can provide. Does anyone understand what's going on? Rich Wagner 
From: KHMan <keinhong@gm...>  20100604 01:58:39

Richard C. Wagner wrote: > Has anyone here made much use of MinGW with scientific or floating point > calculations? I've written a Mandelbrot generator, and I'm seeing > truncation errors at values far above where I expect them. Specifically, > I'm taking an integer pixel coordinate from 0 to 640, converting it to a > floating point number, dividing it by a floating point 640, and multiplying > that result by another small float, in this case, 9.0e6. And the answer > doesn't change with each increment of the first number. I've written a > standalone test program doing just this calculation and here are the > results: > [edited below] > Pixel_x = 100 Domain_x = 1.00000143051147460000 ... > Pixel_x = 106 Domain_x = 1.00000154972076420000 ... > Pixel_x = 115 Domain_x = 1.00000166893005370000 ... A float has about 7 decimal digits of precision. For whatever reasons, your result has a 1 plus 'a very small number'. So, taking 8 digits of displayed result (since the '1' at the front doesn't 'contribute' a full 1 digits of precision): 1.0000014 1.0000015 1.0000017 Nothing wrong with the compiler or the machine. No point using floats unless you're on a GPU. Worse, you can't zoom much with floats. Most serious Mandelbrot implementations need multiple precision numbers for deep zooms.  Cheers, KeinHong Man (esq.) Kuala Lumpur, Malaysia 
From: Ben Ross <Ben.R<oss@sc...>  20100604 10:52:02

There is something very wrong somewhere because if you are performing x / 640.0 * 9e6 For 0.0 <= x <= 640.0 Your results should be way less than 1. For x = 640 the result is 9e6 and for anything else it is less. I tried int value; for(value = 100; value < 120; value ++) { std::cout << value << ": " << (double(value)/640.0*9e6) << std::endl; } and got 100: 1.40625e006 101: 1.42031e006 102: 1.43438e006 Using >g++ version g++ (GCC) 4.4.0 Copyright (C) 2009 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. >From the mingw project. What you are getting is more than a truncation error, the result is not even in the right ball park I would want to see further evidence before I started questioning the compiler. Original Message From: Richard C. Wagner [mailto:drsavage@...] Sent: 04 June 2010 01:38 To: MinGW Users Subject: [Mingwusers] MinGW and Floating Point Hi All: Has anyone here made much use of MinGW with scientific or floating point calculations? I've written a Mandelbrot generator, and I'm seeing truncation errors at values far above where I expect them. Specifically, I'm taking an integer pixel coordinate from 0 to 640, converting it to a floating point number, dividing it by a floating point 640, and multiplying that result by another small float, in this case, 9.0e6. And the answer doesn't change with each increment of the first number. I've written a standalone test program doing just this calculation and here are the results: Pixel_x = 100 Domain_x = 1.00000143051147460000 Pixel_x = 101 Domain_x = 1.00000143051147460000 Pixel_x = 102 Domain_x = 1.00000143051147460000 Pixel_x = 103 Domain_x = 1.00000143051147460000 Pixel_x = 104 Domain_x = 1.00000143051147460000 Pixel_x = 105 Domain_x = 1.00000143051147460000 Pixel_x = 106 Domain_x = 1.00000154972076420000 Pixel_x = 107 Domain_x = 1.00000154972076420000 Pixel_x = 108 Domain_x = 1.00000154972076420000 Pixel_x = 109 Domain_x = 1.00000154972076420000 Pixel_x = 110 Domain_x = 1.00000154972076420000 Pixel_x = 111 Domain_x = 1.00000154972076420000 Pixel_x = 112 Domain_x = 1.00000154972076420000 Pixel_x = 113 Domain_x = 1.00000154972076420000 Pixel_x = 114 Domain_x = 1.00000154972076420000 Pixel_x = 115 Domain_x = 1.00000166893005370000 Pixel_x = 116 Domain_x = 1.00000166893005370000 Pixel_x = 117 Domain_x = 1.00000166893005370000 Pixel_x = 118 Domain_x = 1.00000166893005370000 Pixel_x = 119 Domain_x = 1.00000166893005370000 If you're interested, I can post the code. These results are far grainier, numerically, than they hardware can provide. Does anyone understand what's going on? Rich Wagner   ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeekpromo _______________________________________________ MinGWusers mailing list MinGWusers@... This list observes the Etiquette found at http://www.mingw.org/Mailing_Lists. We ask that you be polite and do the same. Disregard for the list etiquette may cause your account to be moderated. _______________________________________________ You may change your MinGW Account Options or unsubscribe at: https://lists.sourceforge.net/lists/listinfo/mingwusers SciSys UK Limited. Registered in England and Wales No. 4373530. Registered Office: Methuen Park, Chippenham, Wiltshire SN14 0GB, UK. * Before printing, please think about the environment. 
From: Earnie <earnie@us...>  20100604 11:16:06

Ben Ross wrote: > There is something very wrong somewhere because if you are performing > Do not TOP POST[2] in this list. Google[1] has some interesting tidbits about mingw and floating point. [1] http://www.google.com/search?q=mingw+floating+point [2] http://www.google.com/search?q=mingw+top+post  Earnie  http://www.formykids.com 
From: KHMan <keinhong@gm...>  20100604 11:46:44

Ben Ross wrote: > There is something very wrong somewhere because if you are performing > > x / 640.0 * 9e6 > > For 0.0 <= x <= 640.0 > > Your results should be way less than 1. For x = 640 the > result is 9e6 and for anything else it is less. > [snip] FWIW, I guess we'll have to see if Richard wants to respond. Often, I find that OPs are really shy about winding up a thread they started. Since the Mandelbrot set, Zn+1 = Zn * Zn + C where Z(0) = 0 there is no reason for the constant C (represented by a point on the screen) to be multiplied with anything. If Richard's Domain_x is Real(Zn+1), then Domain_x=1 is nowhere near an edge. The description and sample data are not consistent. I thought he added a 1 somewhere to get his Domain_x with the low precision float results, but it makes no sense in the context of the Mandelbrot set equation. Sounds like a throwaway test of some sort when zooming in failed (or turned blocky) due to lack of numeric precision. > [snip] > Original Message > From: Richard C. Wagner [mailto:drsavage@...] > Sent: 04 June 2010 01:38 > To: MinGW Users > Subject: [Mingwusers] MinGW and Floating Point > [snipped all]  Cheers, KeinHong Man (esq.) Kuala Lumpur, Malaysia 
From: Ben Ross <Ben.R<oss@sc...>  20100604 13:02:14

KHMan wrote: > Zn+1 = Zn * Zn + C where Z(0) = 0 > >there is no reason for the constant C (represented by a point on the screen) to be multiplied with anything. There is if you are using screen coordinates to base the units on because you will need to transform those values down into the domain of the fractal. C is constant but it exists in 2 domains, screen coordinates and fracal coordinates which is where the transformation happens between the two. (Now do I get in trouble for being too far off topic for this list? :) P.S. Why is it that sometimes I only see half conversations on this list and sometimes the only the replies not the OP? SciSys UK Limited. Registered in England and Wales No. 4373530. Registered Office: Methuen Park, Chippenham, Wiltshire SN14 0GB, UK. * Before printing, please think about the environment. 
From: Greg Chicares <gchicares@sb...>  20100604 13:23:46

On 20100604 13:02Z, Ben Ross wrote: [...] > P.S. Why is it that sometimes I only see half conversations on > this list and sometimes the only the replies not the OP? I haven't had such a problem here in a long time. I would guess that your ISP or employer filters out some messages. The most reliable archive seems to be gmaneto search, go here: http://search.gmane.org/ and paste gmane.comp.gnu.mingw* into the "In group" box. If a message appears there but not in your inbox, it has been filtered out. 
From: KHMan <keinhong@gm...>  20100604 14:59:47

Ben Ross wrote: > KHMan wrote: >> Zn+1 = Zn * Zn + C where Z(0) = 0 >> >> there is no reason for the constant C (represented by a point on the > screen) to be multiplied with anything. > > There is if you are using screen coordinates to base the units on > because > you will need to transform those values down into the domain of the > fractal. > C is constant but it exists in 2 domains, screen coordinates and fracal > > coordinates which is where the transformation happens between the two. You're right, of course. I was selfishly thinking about the iterative process only. So his Z^2 has a real part very close to 1, an edge with a high dwell, the real part of C was small. Hence the ~1 values. [snip] In any case, I think I shall not prolong this thread any further. :)  Cheers, KeinHong Man (esq.) Kuala Lumpur, Malaysia 