Re: [Mesa3d-dev] gl_sqrt in mmath.c

[Klaus N. <kl...@ma...>]

I don't know if you understand me: I did not change the
'gl_sqrt'-function, I only analysed it to see what it produces both in
speed and accuracy.

On Mon, 26 Mar 2001, David Konerding wrote:
>
> There are a number of issues here.  You can't just play with compiler
> optimization flags willy-nilly.

I know. I played with the flags that are used by Makefile generated by
'./configure'.

> is NOT acceptable).  You don't mean "precision", you mean "accuracy", and for
> those of where it matters
Sorry, English is not my mother-tongue.

>
> Did you read the man page for gcc and learn what -fstrict-aliasing does?  I
> wouldn't use that
> feature for math-intensive routines.
>
Like I said above, I only used it because it was used in 'configure.in'.

> So it's a 20 or 30 digit number ... what's the error?  Binary representation
> of floating point is a very, very ugly numerical situation,
> it's not surprising to me you get some garbage off to the right- what really
> matters is the raw error,
> between the numerically correct answer and your approximate solution.

What I did was 'sqrt(x)/gl_sqrt(x)' and I something like '10^30'
instead of '10^0' (I got a 30 digit number in front of the dot).

>
> You should also remote -ffast-math from your compile line, it's a dubious
> routine, and I'm sure there is at least one
> place where Mesa violates the rules that -ffast-math assumes you're following.
>

'-ffast-math' is also used in the standard Makefiles of Mesa.

Klaus