On Jan 7, 2013, at 17:43 , Jean Suisse 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 over
> the results.
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 opera
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 wouldn't solve that.
We don't care so much about
On 7 janv. 2013, at 20:22, Greg Parker 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 should give, if not
On Jan 5, 2013, at 12:02 AM, Rick Mann 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
> fast, and am rath
On 5 janv. 2013, at 09:02, Rick Mann 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 define by itself
th
On Jan 4, 2013, at 23:30 , vincent habchi 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 hardware, it sh
On 5 janv. 2013, at 03:38, Rick Mann 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. Afaik, only 6 inclu
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 wrote:
> So, we've run into an issue in our physics simulation where the floating
> point results from cos() (and pro
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 d
10 matches
Mail list logo
