On Mar 9, 2005, at 03:18, Duncan Sands wrote:
if the Ada front-end has an efficient, accurate implementation
of x^y, wouldn't it make sense to move it to the back-end
(__builtin_pow) so everyone can benefit?
Does not have it yet. Current implementation is reasonably accurate,
but not very fast. How
Duncan Sands wrote:
if the Ada front-end has an efficient, accurate implementation
of x^y, wouldn't it make sense to move it to the back-end
(__builtin_pow) so everyone can benefit?
I don't know how efficient or accurate the current implementation
is (we are in the process of redoing our math routi
Hi Robert,
> >>Well if you tell me there are people about there implementing cpow
> >>with log and exp, that's enough for me to decide that Ada should
> >>continue to stay away (the Ada RM has accuracy requirements that
> >>would preclude a broken implementation of this kind) :-)
> >
> >
> > the
> Ronny Peine
>
> Maybe i found something:
>
> http://www.cs.berkeley.edu/~wkahan/ieee754status/ieee754.ps
> page 9 says:
>
> "A number of real expressions are sometimes implemented as INVALID
> by mistake, or declared Undefined by illconsidered
> language standards; a few examples are ...
> 0.0**
Duncan Sands wrote:
Hi Robert,
Well if you tell me there are people about there implementing cpow
with log and exp, that's enough for me to decide that Ada should
continue to stay away (the Ada RM has accuracy requirements that
would preclude a broken implementation of this kind) :-)
the referenc
Hi Robert,
> Well if you tell me there are people about there implementing cpow
> with log and exp, that's enough for me to decide that Ada should
> continue to stay away (the Ada RM has accuracy requirements that
> would preclude a broken implementation of this kind) :-)
the reference manual all
Paolo Carlini wrote:
Duncan Sands wrote:
aren't __builtin_cpow and friends language independent? I mean, if a
front-end sees a x^y then presumably it ends up being turned into a
call to a __builtin_?pow by the back-end. If so, then conforming to
the C99 and C++ standards isn't enough: the standar
Duncan Sands wrote:
aren't __builtin_cpow and friends language independent? I mean, if a
front-end sees a x^y then presumably it ends up being turned into a
call to a __builtin_?pow by the back-end. If so, then conforming to
the C99 and C++ standards isn't enough: the standards for all gcc
suppor
Hi Paolo,
> > What we are debating here isn't really maths at all, just the
> > definition which will be most useful and least suprising (and perhaps
> > also what various standards tell us to use).
>
> Also, since we are definitely striving to consistently implement the
> current C99 and C++
Well, you are right, this discussion becomes a bit off topic.
I think 0^0 should be 1 in the complex case, too. Otherwise the complex
and real definitions would collide.
Example:
use complex number 0+i*0 then this should be handled equivalent to the
real number 0. Otherwise the programmer would get
Chris Jefferson wrote:
What we are debating here isn't really maths at all, just the
definition which will be most useful and least suprising (and perhaps
also what various standards tell us to use).
Also, since we are definitely striving to consistently implement the
current C99 and C++ Standar
Ronny Peine wrote:
Well, i'm studying mathematics and as i know so far 0^0 is always 1
(for real and complex numbers) and well defined even in numerical and
theoretical mathematics. Could you point me to some publications which
say other things?
cu, Ronny
Just wanting to put in my mathematical
Ronny Peine wrote:
Well, i'm studying mathematics and as i know so far 0^0 is always 1
(for real and complex numbers) and well defined even in numerical and
theoretical mathematics. Could you point me to some publications which
say other things?
cu, Ronny
Just wanting to put in my mathematical
13 matches
Mail list logo
