On 8/17/2012 3:40 PM, clipka wrote:
> Am 17.08.2012 20:28, schrieb Dave:
>> I built pov 3.7 rc6 beta on my Raspberry PI.
>>
>> The first time I built, openexr was enabled by default; the second time
>> I built with '--without-openexr'. For each build I ran povray on the
>> biscuit.pov file as done by 'make check'. Perhaps this is by design, but
>> when built with openexr, the 8-bit color PNG exhibits weird artifacts. I
>> would expect to see this if I used '+fn16' (I actually used +fn) and
>> pnginfo displays the same info for both PNG's:
>
> This is definitely /not/ by design; whether you build with openEXR or
> not should be irrelevant unless you actually try to use openEXR in- or
> output.
>
> The only reason I can think of why disabling openEXR /does/ make a
> difference is that it is a file format based on some special
> "half-precision" floating point data type; maybe enabling openEXR also
> causes the CPU's floating point module to be switched into a different
> mode, where some computation errors become more prominent.
>
>
> Are you sure the ARM does support full double-precision IEEE floating
> point arithmetics?
>

 From what I have gathered from the RPi site/forums, the device uses 
hardware floating point. When I was looking into this, I tried 
-mfloat-abi=softfp and I got a link error that said (paraphrased):

   cannot mix objects compiled with different floating point abi's

I have since read on the forums:

   the RPi only supports -mfpu=vfp -mfloat-abi=hard (and this is the 
default)

When I built povray & the paranoia.c program, I took all defaults. I 
have no reason to believe that any compile-time floating point settings 
changed. As far as openexr... I could not tell you, but since I have no 
monitors that can display such images I decided to disable it.


>> For you information, when I first got the Raspberry PI up and running, I
>> ran an ancient program 'paranoia.c' which tests floating point accuracy.
>> The program can still be found here:
>>    http://www.netlib.org/paranoia/paranoia.c
>> The program reported no abnormalities on the Raspberry PI, so I would
>> expect that the PNG's produced by both x86 and arm (--without-openexr)
>> would be >close< to identical. But they are not...?
>
> I have no idea what that program actually tests - not to mention that
> you might have compiled it with totally different floating point mode
> settings.
>

Take a look at the program & compile it on your system & see what you 
think. I am not mathematically savvy enough to say whether the program 
is correct or not -- it purports to test floating point accuracy and 
seems to be testing against what was the proposed IEEE floating point 
standard ca. 1985. However, I compiled and ran the program on Win7x64 
using the MinGW gcc 64-bit compiler. The results are essentially 
identical (diff appended below). Since my Intel CPU supports IEEE 
floating point and the paranoia.c program produces identical results, I 
would bet that the RPi supports IEEE floating point.

$ diff MinGW.txt RPi.txt

< $ gcc --version
< gcc.exe (GCC) 4.5.4 20111030 (prerelease) [svn/rev.180676 - mingw-w64/oz]
< Copyright (C) 2010 Free Software Foundation, Inc.
---
 > $ gcc -version
 > gcc (Debian 4.6.3-8+rpi1) 4.6.3
 > Copyright (C) 2011 Free Software Foundation, Inc.
7c7
< $ gcc paranoia.c -lm
---
 > $ gcc paranoia.c
101c105
< Closest relative separation found is U1 = 1.1102230e-016 .
---
 > Closest relative separation found is U1 = 1.1102230e-16 .
144c151
< What the machine gets for (Z + Z) / Z is  2.00000000000000000e+000 .
---
 > What the machine gets for (Z + Z) / Z is  2.00000000000000000e+00 .
148c155
< The Underflow threshold is 2.22507385850720190e-308,  below which
---
 > The Underflow threshold is 2.22507385850720188e-308,  below which
151c158
< UfThold = (2.00000000000000000e+000) ^ (-1.02200000000000000e+003)
---
 > UfThold = (2.00000000000000000e+00) ^ (-1.02200000000000000e+03)
153,154c160,161
< 	(2.00000000000000000e+000) ^ (-2.04400000000000000e+003);
< actually calculating yields: 0.00000000000000000e+000 .
---
 > 	(2.00000000000000000e+00) ^ (-2.04400000000000000e+03);
 > actually calculating yields: 0.00000000000000000e+00 .
157c164
< Testing X^((X + 1) / (X - 1)) vs. exp(2) = 7.38905609893065220e+000 as 
X -> 1.
---
 > Testing X^((X + 1) / (X - 1)) vs. exp(2) = 7.38905609893065218e+00 as 
X -> 1.
169c177
< Trying it on Y = -1.#INF0000000000000e+000 .
---
 > Trying it on Y = -inf .
171,174c179,182
< Overflow threshold is V  = 1.79769313486231570e+308 .
< Overflow saturates at V0 = 1.#INF0000000000000e+000 .
< No Overflow should be signaled for V * 1 = 1.79769313486231570e+308
<                            nor for V / 1 = 1.79769313486231570e+308 .
---
 > Overflow threshold is V  = 1.79769313486231571e+308 .
 > Overflow saturates at V0 = inf .
 > No Overflow should be signaled for V * 1 = 1.79769313486231571e+308
 >                            nor for V / 1 = 1.79769313486231571e+308 .
186c195
<     Trying to compute 1 / 0 produces ...  1.#INF000e+000 .
---
 >     Trying to compute 1 / 0 produces ...  inf .
189c198,199
<     Trying to compute 0 / 0 produces ...  -1.#IND000e+000 .
---
 >
 >     Trying to compute 0 / 0 produces ...  nan .

Post a reply to this message