On Tue, Feb 7, 2012 at 7:19 PM, Julien Puydt wrote:
> Le Tue, 7 Feb 2012 20:23:08 -0800 (PST),
> Jason a écrit :
> > One benefit of programs like matlab and mathematica is that not only
> > do they bring together many different functions with a common syntax,
> > but that they (presumably) have s
Le Tue, 7 Feb 2012 20:23:08 -0800 (PST),
Jason a écrit :
> One benefit of programs like matlab and mathematica is that not only
> do they bring together many different functions with a common syntax,
> but that they (presumably) have standardized precision and accuracy
> control. So coming up with
One benefit of programs like matlab and mathematica is that not only
do they bring together many different functions with a common syntax,
but that they (presumably) have standardized precision and accuracy
control. So coming up with a standard in this area is important. I
think such a standard cou
Le Mon, 6 Feb 2012 15:27:48 -0800 (PST),
rjf a écrit :
> On Feb 6, 9:00 am, Julien Puydt wrote:
> > Still, I'm glad you think the problem is trivial/doesn't exist :
> > that means you'll be able to provide a nice patch real soon.
> >
> > Looking forward for your fix, thanks for your suggestions,
to quote from the Kahan/Darcy paper..
http://www.cs.berkeley.edu/~wkahan/JAVAhurt.pdf
Strictly speaking, a number can possess neither precision nor
accuracy.
A number possesses only its value.
Precision attaches to the format into which the number is written or
stored or rounded. Better ( higher
On Feb 6, 9:00 am, Julien Puydt wrote:
>
...
> 0.0 is a range of numbers, and zero is in that range, and I think they
> shouldn't be considered equal.
That is your opinion. People have other opinions. Some programming
languages
implement 0.0 numerically equal to (integer) 0. For example, ANSI
Le Mon, 6 Feb 2012 07:45:49 -0800 (PST),
rjf a écrit :
>
> On Feb 5, 3:02 am, Julien Puydt wrote:
> > Le 04/02/2012 23:11, Robert Bradshaw a crit :
> >
> > .
>
> > I think cos(0.0) != 1.0 isn't bad, since 0.0 isn't zero anyway, and
> > 1.0 isn't one anyway. In fact, I would welcome if using
On Feb 5, 3:02 am, Julien Puydt wrote:
> Le 04/02/2012 23:11, Robert Bradshaw a crit :
>
> .
> I think cos(0.0) != 1.0 isn't bad, since 0.0 isn't zero anyway, and 1.0
> isn't one anyway. In fact, I would welcome if using strict comparisons
> on floats triggered an exception.
>
> And this mo
Le 04/02/2012 23:11, Robert Bradshaw a écrit :
On Sat, Feb 4, 2012 at 8:17 AM, rjf wrote:
On Feb 2, 1:16 pm, Julien Puydt wrote:
Le 02/02/2012 23:22, Jonathan Bober a crit :
Can you think of a reason that the answer should change? Does maxima use
less that 53 bits of precision ever?
Well,
On 02/ 4/12 10:11 PM, Robert Bradshaw wrote:
Note that what is broken[1] here is ARM's libc, if one types
"gamma(6.0)" one gets "120." on all systems. It's a
question about gamma(float(6.0)) which is explicitly requesting the
(presumably faster but potentially less accurate) system
i
On Sat, Feb 4, 2012 at 2:11 PM, Robert Bradshaw <
rober...@math.washington.edu> wrote:
>
> Note that what is broken[1] here is ARM's libc, if one types
> "gamma(6.0)" one gets "120." on all systems. It's a
> question about gamma(float(6.0)) which is explicitly requesting the
> (presuma
On Sat, Feb 4, 2012 at 8:13 AM, rjf wrote:
>
>
> > 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.
>
> I think
On Sat, Feb 4, 2012 at 8:17 AM, rjf wrote:
>
> On Feb 2, 1:16 pm, Julien Puydt wrote:
>> Le 02/02/2012 23:22, Jonathan Bober a crit :
>>
>> > Can you think of a reason that the answer should change? Does maxima use
>> > less that 53 bits of precision ever?
>>
>> Well, if I don't err, $10^{17}$ h
Le 04/02/2012 17:21, rjf a écrit :
On Feb 2, 1:29 pm, Julien Puydt wrote:
+1 A user asking for a floating-point computation means (s)he is ready
to accept the results are mathematically wrong, but computationally
within a reasonable error range.
There are lots of reasonable expectations. Lik
On Feb 3, 7:53 pm, David Kirkby wrote:
> On 2 February 2012 23:05, 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 a
On Feb 2, 1:29 pm, Julien Puydt wrote:
>
>
> +1 A user asking for a floating-point computation means (s)he is ready
> to accept the results are mathematically wrong, but computationally
> within a reasonable error range.
>
There are lots of reasonable expectations. Like the answer will be
the
On Feb 2, 1:16 pm, Julien Puydt wrote:
> Le 02/02/2012 23:22, Jonathan Bober a crit :
>
> > Can you think of a reason that the answer should change? Does maxima use
> > less that 53 bits of precision ever?
>
> Well, if I don't err, $10^{17}$ has 18 decimal digits, which is more
> than the 15,95.
On Feb 2, 5:28 pm, 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 integ
On Saturday, 4 February 2012 17:38:00 UTC+8, Dr. David Kirkby wrote:
>
> On 02/ 4/12 05:00 AM, Dima Pasechnik wrote:
> >
> >
> > On Saturday, 4 February 2012 11:53:35 UTC+8, Dr. David Kirkby wrote:
> >>
> >>
> >>
> >> On 2 February 2012 23:05, rjf<> wrote:
> >>
> >>>
> >>> I don't know about ari
On 02/ 4/12 05:00 AM, Dima Pasechnik wrote:
On Saturday, 4 February 2012 11:53:35 UTC+8, Dr. David Kirkby wrote:
On 2 February 2012 23:05, 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
http://urchin.earth.li/~twic/Ulrich_Drepper_Is_A_.html
On Saturday, 4 February 2012 16:18:35 UTC+8, Snark wrote:
>
> Le 04/02/2012 06:00, Dima Pasechnik a �crit :
> > It's well-known how to compute gamma() better than it is implemented in
> > (e)glibc, the prevalent Linux libc implementation,
>
Le 04/02/2012 06:00, Dima Pasechnik a écrit :
It's well-known how to compute gamma() better than it is implemented in
(e)glibc, the prevalent Linux libc implementation,
which computes exp(lgamma()) rather than gamma() directly.
See e.g.
http://oai.cwi.nl/oai/asset/10080/10080A.pdf
Perhaps I sho
On Saturday, 4 February 2012 11:53:35 UTC+8, Dr. David Kirkby wrote:
>
>
>
> On 2 February 2012 23:05, 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) w
On 2 February 2012 23:05, 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
> ex
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) whe
Le 03/02/2012 02:28, Jonathan Bober a écrit :
On Thu, Feb 2, 2012 at 3:05 PM, rjf mailto:fate...@gmail.com>> 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) w
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 i
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.
28 matches
Mail list logo
