On Jan 5, 2013, at 12:02 AM, Rick Mann rm...@latencyzero.com wrote:
Postings online suggest this is by design, in that it was more important to
get close results faster. Unfortunately, in something like a physic
simulation, the error adds up quickly. I think correct is more important than
On 7 janv. 2013, at 20:22, Greg Parker gpar...@apple.com wrote:
IEEE 754 guarantees exact results for + - * / sqrt. Everything else is
implementation-defined.
That’s why I suggested a mixed approach combining exact table lookup and a
refinement via only multiplications and divisions. It
On Jan 7, 2013, at 11:22 , Greg Parker gpar...@apple.com wrote:
Note also that physics simulations will always need to be careful with the
error inherent to finite precision floating-point arithmetic. IEEE
specification of exact results for every operation wouldn't solve that.
We don't
On 8 janv. 2013, at 00:24, Rick Mann wrote:
On Jan 7, 2013, at 11:22 , Greg Parker wrote:
Note also that physics simulations will always need to be careful with the
error inherent to finite precision floating-point arithmetic. IEEE
specification of exact results for every operation
On Jan 7, 2013, at 17:43 , Jean Suisse jean.li...@gmail.com wrote:
That wasn't clear (at least for me) in your original message. It is also a
key point. In that case, you indeed don't need accuracy. Why not go for one
of Vincent Habchi's solutions then ? That could give you more control
On Jan 4, 2013, at 23:30 , vincent habchi vi...@macports.org wrote:
This is not much of a surprise. Afaik, only 6 includes a IEEE double
precision FPU. I suppose you do all your computations using doubles?
Well, that shouldn't matter. If a double is a double, then even if it can't
do it in
On 5 janv. 2013, at 09:02, Rick Mann rm...@latencyzero.com wrote:
Well, that shouldn't matter. If a double is a double, then even if it can't
do it in hardware, it should be done in software, and the result should be
the same.
Of course. But, if I am not mistaken, the IEEE norm does not
So, we've run into an issue in our physics simulation where the floating point
results from cos() (and probably other intrinsics) are different between Apple
ARM 5 and Apple ARM 6 processors. One person online said he solved the issue by
implementing his own intrinsics, but I don't know how to
Have you looked at crlibm? I've never used it on OSX or iOS or even tried
compiling it but I've seen it linked into some code at work.
On 5 Jan, 2013, at 10:38 AM, Rick Mann rm...@latencyzero.com wrote:
So, we've run into an issue in our physics simulation where the floating
point results
On 5 janv. 2013, at 03:38, Rick Mann rm...@latencyzero.com wrote:
So, we've run into an issue in our physics simulation where the floating
point results from cos() (and probably other intrinsics) are different
between Apple ARM 5 and Apple ARM 6 processors.
This is not much of a surprise.
10 matches
Mail list logo
