At the moment function like sqrt() use the underlying C functions in double precision. Is there any way to have versions which work to extended precision?

John

"John Fletcher" <J.P.Fletcher@aston.ac.uk> wrote in message news:3C6268D1.C1E23080@aston.ac.uk...

> At the moment function like sqrt() use the underlying C functions in double precision. Is there any way to have versions which work to extended precision?

Yes - write them =)
The comment there says it's just a temporary solution. I'd expect
all the math functions to be rewritten until the final release.

Actually can we have some functions like sin, cos, tan, and sqrt that deal with float instead of double?  In the world of games, speed is usually more important than accuracy and I hate having to explicitly typecast back to float to avoid warnings.

Another nice thing to have is reciprocal square root (most processors have
this nowadays...) usually it's cheaper (and less accurate) than 1/sqrt(x)

Sean

"John Fletcher" <J.P.Fletcher@aston.ac.uk> wrote in message news:3C6268D1.C1E23080@aston.ac.uk...
> At the moment function like sqrt() use the underlying C functions in double precision. Is there any way to have versions which work to extended precision?
>
> John

"Sean L. Palmer" wrote:

> Actually can we have some functions like sin, cos, tan, and sqrt that deal with float instead of double?  In the world of games, speed is usually more important than accuracy and I hate having to explicitly typecast back to float to avoid warnings.
>
> Another nice thing to have is reciprocal square root (most processors have
> this nowadays...) usually it's cheaper (and less accurate) than 1/sqrt(x)
>
> Sean
>

I was pondring implementing the full precision versions I talked about.  I think that the modern Intel and compatible chips have coprocessor instructions which actually do the work to full precision.  Is it just a question of wrapping the correct input and output around that to do the different cases? There may be some error trapping as well.

John

"John Fletcher" <J.P.Fletcher@aston.ac.uk> wrote in message news:3C63C2A2.CC837516@aston.ac.uk...

> I was pondring implementing the full precision versions I talked about.  I think that the modern Intel and compatible chips have coprocessor
instructions
> which actually do the work to full precision.  Is it just a question of wrapping the correct input and output around that to do the different
cases?
> There may be some error trapping as well.

Yes, AFAIK Intel FPUs do calculations in full precision anyhow. However, extended arguments have to be passed on stack, and since they're 10-byte long, you get three PUSHes (while float would only take one).

Sean L. Palmer wrote:

> Actually can we have some functions like sin, cos, tan, and sqrt that deal
> with float instead of double?  In the world of games, speed is usually more
> important than accuracy and I hate having to explicitly typecast back to
> float to avoid warnings.
> 
> Another nice thing to have is reciprocal square root (most processors have
> this nowadays...) usually it's cheaper (and less accurate) than 1/sqrt(x)
>
> "John Fletcher" <J.P.Fletcher@aston.ac.uk> wrote in message
> news:3C6268D1.C1E23080@aston.ac.uk...
> 
>>At the moment function like sqrt() use the underlying C functions in
>>double precision. Is there any way to have versions which work to
>>extended precision?


Indeed on all counts, both extended and single-precision versions
of at least the more common math functions would be valuable.
Who wants to get to work on that library? :)

-Russell B

"Russell Borogove" <kaleja@estarcion.com> wrote in message news:3C63FBED.1080500@estarcion.com...

> Indeed on all counts, both extended and single-precision versions of at least the more common math functions would be valuable. Who wants to get to work on that library? :)

Not till we get inline asm working =)

I believe the common form of this stuff is to add "f" to the end of the name

sqrtf
fabsf
fmodf


etc

Sean

"Russell Borogove" <kaleja@estarcion.com> wrote in message news:3C63FBED.1080500@estarcion.com...
> Sean L. Palmer wrote:
>
> > Actually can we have some functions like sin, cos, tan, and sqrt that
deal
> > with float instead of double?  In the world of games, speed is usually
more
> > important than accuracy and I hate having to explicitly typecast back to float to avoid warnings.
> >
> > Another nice thing to have is reciprocal square root (most processors
have
> > this nowadays...) usually it's cheaper (and less accurate) than
1/sqrt(x)
> >
> > "John Fletcher" <J.P.Fletcher@aston.ac.uk> wrote in message news:3C6268D1.C1E23080@aston.ac.uk...
> >
> >>At the moment function like sqrt() use the underlying C functions in double precision. Is there any way to have versions which work to extended precision?
>
>
> Indeed on all counts, both extended and single-precision versions of at least the more common math functions would be valuable. Who wants to get to work on that library? :)
>
> -Russell B
>
>

"Sean L. Palmer" <spalmer@iname.com> wrote in message news:a4192g$2ihc$1@digitaldaemon.com...

> I believe the common form of this stuff is to add "f" to the end of the
name
>
> sqrtf
> fabsf
> fmodf

Why, if we have function overloading?

"Pavel Minayev" <evilone@omen.ru> wrote in message news:a419ev$2kdg$1@digitaldaemon.com...
> "Sean L. Palmer" <spalmer@iname.com> wrote in message news:a4192g$2ihc$1@digitaldaemon.com...
>
> > I believe the common form of this stuff is to add "f" to the end of the
> name
> >
> > sqrtf
> > fabsf
> > fmodf
>
> Why, if we have function overloading?

   The suffix specifies the precision of the return type, which cannot be
overloaded on. Or am I wrong?

Salutaciones,
                         JCAB