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
