 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I'm working on a large animation project.
One of the scenes has a large number of spheres that move and collide.
The positions and velocity vectors are written to a file in each frame to be
read by the next frame.
The same file produces a different constellation of the spheres after a few
hundred frames in Linux as compared to the same under Windows.
Is there a logical explanation? If one of the two uses one decimal more for
storing the intermediate situations, then I can well believe that the situations
become very different.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 14/02/2012 20:49, Jos leys nous fit lire :
> I'm working on a large animation project.
> One of the scenes has a large number of spheres that move and collide.
> The positions and velocity vectors are written to a file in each frame to be
> read by the next frame.
>
> The same file produces a different constellation of the spheres after a few
> hundred frames in Linux as compared to the same under Windows.
>
> Is there a logical explanation? If one of the two uses one decimal more for
> storing the intermediate situations, then I can well believe that the situations
> become very different.
>
>
Any random generator (seed(),random()) used in your simulation ?
You compared linux & windows, have you tried two windows or two linux ?
Were both 32 or 64 bits, or mixed ?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le_Forgeron <jgr### [at] free fr> wrote:
> Any random generator (seed(),random()) used in your simulation ?
>
> You compared linux & windows, have you tried two windows or two linux ?
>
> Were both 32 or 64 bits, or mixed ?
No seed()/rand().
My Windows is 64bit and the frame sequence is repeatable, giving the same result
all the time. Have not tried another Windows system.
The Linux is installed on a set of computers at a university in France, and I
don't have the specs. I can get them if that is important...
Post a reply to this message
|
|
| |
| |
|
|
From: Darren New
Subject: Re: Differences in calculations Windows-Linux
Date: 15 Feb 2012 21:00:09
Message: <4f3c6329@news.povray.org>
|
|
|
| |
| |
|
|
On 2/14/2012 11:49, Jos leys wrote:
> The same file produces a different constellation of the spheres after a few
> hundred frames in Linux as compared to the same under Windows.
Run the two and keep all the intermediate files. See which pair of files has
different results. I'm betting it's a difference in the printf() function,
or whatever it is that POV uses to output floating point numbers as decimal
strings, where the trailing bits are getting rounded differently during the
formatting.
--
Darren New, San Diego CA, USA (PST)
People tell me I am the counter-example.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 14.02.2012 20:49, schrieb Jos leys:
> I'm working on a large animation project.
> One of the scenes has a large number of spheres that move and collide.
> The positions and velocity vectors are written to a file in each frame to be
> read by the next frame.
>
> The same file produces a different constellation of the spheres after a few
> hundred frames in Linux as compared to the same under Windows.
>
> Is there a logical explanation? If one of the two uses one decimal more for
> storing the intermediate situations, then I can well believe that the situations
> become very different.
A 32-bit non-SSE2 version of POV-Ray might produce different results as
a 32-bit SSE2 or 64-bit version; the latter two use the true "double
precision" (64 bit) floating point arithmetics of the SSE2 instructions,
while the former uses the older x87 instructions, wich have a slightly
higher internal precision (72 bit IIRC). There are mechanisms available
to automatically trim x87 interim results to double precision, but those
might be disabled; the compiler probably has a say in this.
Another difference might arise if the two platforms use different
default rounding modes for floating point operations (which might also
differ between compilers); AFAIK POV-Ray doesn't explicitly specify a
rounding mode to use.
Darren already mentioned the possible implementation differences in the
internal function used to convert floating point numbers to text
strings; as this is a runtime library function, i.e. one that is
supplied by the compiler, its implementation details are beyond
POV-Ray's control.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 02/16/2012 04:26 PM, clipka wrote:
> while the former uses the older x87 instructions, wich have a slightly
> higher internal precision (72 bit IIRC). There are mechanisms available
80 bits
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
