On Friday, 3 February 2012 09:28:37 UTC+8, Jonathan Bober wrote:
>
> On Thu, Feb 2, 2012 at 3:05 PM, rjf <> wrote:
>
>>
>> I don't know about arithmetic on ARM specifically, but there is
>> something
>> wrong with a gamma() function that fails to return an integer (perhaps
>> in float format) when it is
>> given an integer argument (perhaps in float format), and the answer is
>> exactly representable
>> as an integer in float format.
>>
>>
> I'm not sure that I agree. It would certainly be nice if gamma() worked
> this way, but when you consider implementation issues, do you really want
> to treat integer arguments in a special manner? If there is a reasonable
> implementation that can guarantee this behavior with no loss in speed and
> no other significant trade-offs, then library designers should use it, but
> I don't think that it is such a simple issue.
>
>
>> It would also be nice if any floating-point tests that you ran with
>> Sage
>> either (a) determined IEEE 754 standard compatibility and
>> tested numerical routines subject to that standard, or
>> (b) determined machine parameters (e.g. machine epsilon etc.)
>> and the tests were written so as to take variations into
>> account.
>>
>> RJF
>>
>>
> Are there IEEE 754 standards for the accuracy of special functions? I
> tried finding some, but I could not. As far as I know, the standards do not
> specify that transcendental functions need to be computed with the same
> accuracy that one expects from basic arithmetic operations, because it is
> essentially unknown how much memory/time would be needed for this in all
> cases.
>
oh well, surely for gamma doubling the precision does the trick...
At least for x=151 one would get the relative precision of expl(lgammal(x))
down to <10^{-13}
for for x=6 down to <10^{-18}
>
> In Sage, RealField uses mpfr as its backend, and hence its special
> functions should always be computed accurately with correct rounding (and
> thus by definition its results should be independent of the system sage is
> running on). However, python floats map to hardware types and as such, I
> think that it is perfectly reasonable if certain operations with floats
> depend on the underlying hardware, the operating system, the specific
> libraries that are present, and perhaps the phase of the moon. (And I think
> that computing the gamma function is probably one of these cases. Yes, in
> case you are wondering, I would probably consider it acceptable if
> gamma(float(6)) did not even always give the same answer every time it is
> run in the same sage session.)
>
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
