Le Tue, 7 Feb 2012 16:13:10 -0800,
Jonathan Bober a écrit :
> See http://trac.sagemath.org/sage_trac/ticket/12449
>
> I made a patch to change the way that sage evaluates symbolic
> functions for basic python types, and at the same time changed RDF to
> just use math.gamma() instead of gsl's gam
See http://trac.sagemath.org/sage_trac/ticket/12449
I made a patch to change the way that sage evaluates symbolic functions for
basic python types, and at the same time changed RDF to just use
math.gamma() instead of gsl's gamma function.
(Note: math.gamma() should be available in sage-5.0 (pytho
Le Mon, 6 Feb 2012 17:59:57 -0800 (PST),
Dima Pasechnik a écrit :
> still, might be worth trying (unlike with (e)glibc)
Well, after some poking around, it seems it's a mistake to confuse
eglibc and glibc, especially when considering upstream friendliness to
suggestions/bug reports/patches ; h
On Tuesday, February 7, 2012 7:57:11 AM UTC+8, Jonathan Bober wrote:
>
> On Mon, Feb 6, 2012 at 3:05 PM, Dr. David Kirkby <> wrote:
>
>> On 02/ 5/12 10:16 PM, Jonathan Bober wrote:
>>
>> Never mind all that: the gsl implementation is not very good at all,
>>> whereas the libc implementation on m
On Mon, Feb 6, 2012 at 3:05 PM, Dr. David Kirkby wrote:
> On 02/ 5/12 10:16 PM, Jonathan Bober wrote:
>
> Never mind all that: the gsl implementation is not very good at all,
>> whereas the libc implementation on my machine seems quite good. Old
>> (libc):
>>
>
> If that's the case, why not repor
On 02/ 5/12 10:16 PM, Jonathan Bober wrote:
Never mind all that: the gsl implementation is not very good at all,
whereas the libc implementation on my machine seems quite good. Old (libc):
If that's the case, why not report the fact to the appropiate mailing list -
bug-gsl at gnu.org?
dave
Le Sun, 5 Feb 2012 20:03:48 -0800,
Jonathan Bober a écrit :
> The source code does say:
>
>In extensive but non-exhaustive
>random tests, this function proved accurate to within <= 10 ulps
> across the
>entire float domain. Note that accuracy may depend on the quality
> of the system
Le Sun, 5 Feb 2012 14:16:39 -0800,
Jonathan Bober a écrit :
> Never mind all that: the gsl implementation is not very good at all,
> whereas the libc implementation on my machine seems quite good.
Bad :-/
> Old (libc):
>
> sage: gamma(1.23).str(base=2)
> '0.1110100100100111001110100010110010
I think we may be overlooking a very reasonable option. Python already has
a gamma function in the math module! It is a separate implementation that
does not depend on libc, and it gives reasonable results (though perhaps
not as good as eglibc tgammal() on x86):
sage: max(( abs( RR(math.gamma(floa
See http://trac.sagemath.org/sage_trac/ticket/12449
I'm in the middle of [hopefully] fixing this by calling the gsl gamma
function. While I'm at it, I'll also make the evaluation on basic types
much faster, as it shouldn't go though Ginac. (Actually, I've already
mostly written a fix. I opened the
Le 05/02/2012 14:43, Dima Pasechnik a écrit :
On Sunday, 5 February 2012 21:03:46 UTC+8, Snark wrote:
(b) 1, 2 and 4 are all the same bug in various disguise : the libc
lgammal function isn't good enough ;
more precisely, the (e)glibc gamma function is not good. (lgammal isn't
too good e
On Sunday, 5 February 2012 21:03:46 UTC+8, Snark wrote:
>
> Hi,
>
> this thread is getting... long. Let me try to refocus it on more
> constructive grounds.
>
> Let's list the problematic expressions:
> 1. gamma(float(6))
> 2. SR(10.0r).gamma()
> 3. float(maxima("1.7e17"))
> 4. binomial(0.5r,5)
Hi,
this thread is getting... long. Let me try to refocus it on more
constructive grounds.
Let's list the problematic expressions:
1. gamma(float(6))
2. SR(10.0r).gamma()
3. float(maxima("1.7e17"))
4. binomial(0.5r,5)
The following is known :
(a) 1,3 and 4 give test-passing results with "#tol
Le 03/02/2012 10:56, Jonathan Bober a écrit :
On Thu, Feb 2, 2012 at 1:16 PM, Julien Puydt mailto:julien.pu...@laposte.net>> wrote:
Well, if I don't err, $10^{17}$ has 18 decimal digits, which is more
than the 15,95.. that fit in 53 binary digits.
It is not that simple. 15.95 digits i
On Thu, Feb 2, 2012 at 1:16 PM, Julien Puydt wrote:
>
> Well, if I don't err, $10^{17}$ has 18 decimal digits, which is more than
> the 15,95.. that fit in 53 binary digits.
>
It is not that simple. 15.95 digits is more like a guideline. At issue is
whether the number in question can be exactly r
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.. that fit in 53 binary digits.
In any case, let me
Le 03/02/2012 07:31, Dr. David Kirkby a écrit :
Here's two from OpenSolaris on x86 - one with gcc, the other with the
Sun compiler 'cc'
drkirkby@hawk:~$ gcc test.c -lm
drkirkby@hawk:~$ ./a.out
sizof(double)=8
lgamma (6.)=4.78749174278204581157
tgamma (6.)=
On 02/ 2/12 04:45 AM, Dima Pasechnik wrote:
Here is an illustration of the same phenomenon on x86_64. There, of course,
8-byte floats are double, so the code to demonstrate
the problem is as follows:
#include
#include
int main ()
{
double x = 6.0;
printf("sizof(double)=%d\n",sizeof(double))
On Thu, Feb 2, 2012 at 11:23 AM, Julien Puydt wrote:
>
> Let us consider :
> #include
> #include
>
> int
> main ()
> {
> long double x;
> x=6.0;
> printf ("%.20Lf\n", tgammal(x));
> x=10.0;
> printf ("%.20Lf\n", tgammal(x));
> return 0;
> }
>
> On an x86_64 box, I get :
> $ ./test
> 119.99
Le 02/02/2012 05:52, Jonathan Bober a écrit :
I've just been looking at this trying to figure out what was going on
and I was just going to say exactly the same thing.
I don't really know anything about the whole glibc vs eglibc thing, but
I bet the implementation is the same as
glibc-2.14.1/sys
On Thursday, 2 February 2012 12:52:53 UTC+8, Jonathan Bober wrote:
>
> I've just been looking at this trying to figure out what was going on and
> I was just going to say exactly the same thing.
>
> I don't really know anything about the whole glibc vs eglibc thing, but I
> bet the implementati
I've just been looking at this trying to figure out what was going on and I
was just going to say exactly the same thing.
I don't really know anything about the whole glibc vs eglibc thing, but I
bet the implementation is the same as
glibc-2.14.1/sysdeps/ieee754/dbl-64/e_gamma_r.c:
double
__ieee7
Here is an illustration of the same phenomenon on x86_64. There, of course,
8-byte floats are double, so the code to demonstrate
the problem is as follows:
#include
#include
int main ()
{
double x = 6.0;
printf("sizof(double)=%d\n",sizeof(double));
printf("lgamma (%.20f)=%.20f\n", x, lgamm
On Thursday, 2 February 2012 06:24:18 UTC+8, Robert Bradshaw wrote:
>
> On Wed, Feb 1, 2012 at 4:19 AM, Julien Puydt <> wrote:
> > = Forewords =
> >
> > I investigated the numerical issues on my ARM build, and after much
> poking
> > around and searching, I found that I w
On Wed, Feb 1, 2012 at 4:19 AM, Julien Puydt wrote:
> = Forewords =
>
> I investigated the numerical issues on my ARM build, and after much poking
> around and searching, I found that I was chasing the dahu : the tests were
> wrong, and the result were good.
No, the tests
Le 01/02/2012 20:43, Julien Puydt a écrit :
sage: SR(10.0r).gamma() # rel tol 1e-15
Out of tolerance 362880.0 vs 362880.0
In fact, the printed result is misleading : the floats *are* different,
and the difference is 4.6566...e-10, so the relative error is
1.2832...e-15, so it's indeed out of
Le 01/02/2012 18:26, William Stein a écrit :
On Wed, Feb 1, 2012 at 4:19 AM, Julien Puydt wrote:
So the tests should be modified not to depend on the specific implementation
: they're currently testing equality of floats!
See http://trac.sagemath.org/sage_trac/ticket/10952
Oh, dear! That is
On Wed, Feb 1, 2012 at 4:19 AM, Julien Puydt wrote:
> = Forewords =
>
> I investigated the numerical issues on my ARM build, and after much poking
> around and searching, I found that I was chasing the dahu : the tests were
> wrong, and the result were good.
>
> Let's consi
= Forewords =
I investigated the numerical issues on my ARM build, and after much
poking around and searching, I found that I was chasing the dahu : the
tests were wrong, and the result were good.
Let's consider the numerical failures one by one :
= 1/4 ===
29 matches
Mail list logo
