mingw-users

 [Mingw-users] MinGW and Floating Point From: Richard C. Wagner - 2010-06-04 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.0e-6. And the answer doesn't change with each increment of the first number. I've written a stand-alone 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 ```
 Re: [Mingw-users] MinGW and Floating Point From: KHMan - 2010-06-04 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.0e-6. And the answer > doesn't change with each increment of the first number. I've written a > stand-alone 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, Kein-Hong Man (esq.) Kuala Lumpur, Malaysia ```
 Re: [Mingw-users] MinGW and Floating Point From: Ben Ross - 2010-06-04 10:52:02 ```There is something very wrong somewhere because if you are performing x / 640.0 * 9e-6 For 0.0 <= x <= 640.0 Your results should be way less than 1. For x = 640 the result is 9e-6 and for anything else it is less. I tried int value; for(value = 100; value < 120; value ++) { std::cout << value << ": " << (double(value)/640.0*9e-6) << std::endl; } and got 100: 1.40625e-006 101: 1.42031e-006 102: 1.43438e-006 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: [Mingw-users] 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.0e-6. And the answer doesn't change with each increment of the first number. I've written a stand-alone 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/thinkgeek-promo _______________________________________________ MinGW-users mailing list MinGW-users@... 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/mingw-users 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. ```
 Re: [Mingw-users] MinGW and Floating Point From: Earnie - 2010-06-04 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.for-my-kids.com ```
 Re: [Mingw-users] MinGW and Floating Point From: KHMan - 2010-06-04 11:46:44 ```Ben Ross wrote: > There is something very wrong somewhere because if you are performing > > x / 640.0 * 9e-6 > > For 0.0 <= x <= 640.0 > > Your results should be way less than 1. For x = 640 the > result is 9e-6 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: [Mingw-users] MinGW and Floating Point > [snipped all] -- Cheers, Kein-Hong Man (esq.) Kuala Lumpur, Malaysia ```
 Re: [Mingw-users] MinGW and Floating Point From: Ben Ross - 2010-06-04 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 co-ordinates 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 co-ordinates and fracal co-ordinates 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. ```
 Re: [Mingw-users] MinGW and Floating Point From: Greg Chicares - 2010-06-04 13:23:46 ```On 2010-06-04 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 gmane--to 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. ```
 Re: [Mingw-users] MinGW and Floating Point From: KHMan - 2010-06-04 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 co-ordinates 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 co-ordinates and fracal > > co-ordinates 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, Kein-Hong Man (esq.) Kuala Lumpur, Malaysia ```