-
Notifications
You must be signed in to change notification settings - Fork 25
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make a new release supporting GSL 2.6 #176
Comments
We are now a lot closer from all the hard work by @hakonhagland and others. What else needs to be done for our next release? |
Hello, I need to have this issue fixed. I just upgrade fedora 30 to fedora 32. and all my application are unavailable because perl-Math-GSL is not compatable with GSL 2.6; |
Thanks for reporting. Are you using the system
|
@leto What more do we need to do before pushing the current master to CPAN? |
Hello,
I am using perl
This is perl 5, version 30, subversion 2 (v5.30.2)
Linux Teucidide 5.6.15-300.fc32.x86_64 #1 SMP Fri May 29 14:23:59 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
===========================================================================
Patrick DUPRÉ | | email: [email protected]
Laboratoire interdisciplinaire Carnot de Bourgogne
9 Avenue Alain Savary, BP 47870, 21078 DIJON Cedex FRANCE
Tel: +33 (0)380395988
===========================================================================
Sent: Wednesday, June 03, 2020 at 8:05 AM
From: "Håkon Hægland" <[email protected]>
To: "leto/math--gsl" <[email protected]>
Cc: "pdupre0" <[email protected]>, "Comment" <[email protected]>
Subject: Re: [leto/math--gsl] Make a new release supporting GSL 2.6 (#176)
Thanks for reporting. Are you using the system perl? (i.e. not perlbrew perl). If you are using perlbrew perl remove the sudo below. Can you try the following:
yum install swig
git clone https://github.com/leto/math--gsl.git
cd math--gsl
perl Build.PL
sudo ./Build installdeps --cpan_client cpanm
./Build
./Build test
sudo ./Build install
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
When can we expect to have the new verson?
Subject: Re: [leto/math--gsl] Make a new release supporting GSL 2.6 (#176)
@leto What more do we need to do before pushing the current master to CPAN?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
@hakonhagland do you want to make this release and I will add you as comaintainer on CPAN? |
@leto Thanks, I can try. I have not uploaded anything previously to CPAN, so I might need some more help.. |
@hakonhagland is there anything blocking you now? I just merged a bunch of stuff and fixed the version in POD |
@hakonhagland I added you as co-maintainer and PAUSE said it accepted it. Try uploading a dist and see what happens 😅 |
@leto, @ambs I tried to upload now, but seems like I am missing permissions for some of the modules (those with maintainer AMBS):
|
@hakonhagland this is a weird error from the fact that I think AMBS released Math::GSL versions that contained those submodules or some weird bug in PAUSE. If we can get AMBS to give you co-maint, it may work |
hey @ambs can you help us out and give HAKONH co-maint on Math::GSL? He has done epic work. I gave him co-maint but it seems you are the only maintainer of some submodules and you also need to do it |
@leto Seem like it worked despite the warnings about missing permissions since today I got the a CPAN Testers Daily Summary Report emailed. As you can see there are two test failures. How can we fix them? |
@hakonhagland welcome to my pain 👼 |
@hakonhagland if you click on the FAIL link for both, and look at the output, you will see they are different errors. One is from GSL.t and the other is SF.t, both precision issues Precision-related bugs are the bane of the Math::GSL test suite. We discover many precision bugs in some OS's and compiler combinations, and it's a messy situation |
@hakonhagland one failure seems FreeBSD related (maybe their default compiler) and the other is probably related to Perl being built with |
If you are not scared yet, it's likely that the Math::GSL test suite has some TODO tests that are actually bugs in Perl core or related to some weird Perl non-default compilation setting on some weird OS only on some compiler versions 😈 |
@hakonhagland you can TODO those tests on just those platforms, is one "middle path" way to go. To get a release in the hands of users sooner rather than later. I support that |
@leto Interesting. Now, I am looking at the first failed test for perl 5.20.1 on FreeBSD, it says:
It I try run the
So test #22 in
The RT ticket: Fails on perls compiled with -Duselongdouble. The strange thing is that it is already a TODO test and as the comment says "why doesn't $TODO work here?" |
@hakonhagland welcome to the madness. That comment is like 10 years old 😅 |
@hakonhagland I am OK with completely disabling those 2 tests if we have to. They are longstanding issues and not related to your recent code |
@hakonhagland my guess is that |
@leto I think the test # 22 is correct.. But if you look at the other failed test for perl 5.28.3 on GNU/Linux, it says:
And from the output above that line:
so it seems like it is test 'is_similar(0.10005,0.1000501, 1e-7) that fails. Notice that this test is defined as, see t/GSL.t
Since the test is one entry in the hash |
@leto This other failed test for perl 5.28.3 on GNU/Linux is really strange though. It seems to me the test simply does
which checks if
So I am not sure what is going on here.. |
@hakonhagland you can inspect the full TAP output which is numbered. You probably want these bash aliases:
|
Could this line in
the
|
@hakonhagland that code looks like my shitty code from over 10+ years ago, feel free to refactor and improve it 😄 |
Of course
1.00000000002876e-07 is > 1e-7
But
perl -E 'use bignum;$_ = abs(0.10005000 - 0.10005010); say; say "Test will fail" if $_>1e-7'
0.0000001
===========================================================================
Patrick DUPRÉ | | email: [email protected]
Laboratoire interdisciplinaire Carnot de Bourgogne
9 Avenue Alain Savary, BP 47870, 21078 DIJON Cedex FRANCE
Tel: +33 (0)380395988
===========================================================================
Sent: Friday, June 12, 2020 at 12:26 AM
From: "Håkon Hægland" <[email protected]>
To: "leto/math--gsl" <[email protected]>
Cc: "pdupre0" <[email protected]>, "Comment" <[email protected]>
Subject: Re: [leto/math--gsl] Make a new release supporting GSL 2.6 (#176)
@leto This other failed test for perl 5.28.3 on GNU/Linux is really strange though. It seems to me the test simply does
Math::GSL::is_similar(0.10005,0.1000501, 1e-7)
which checks if abs(0.10005 - 0.1000501) < 1e-7 . However, if I on my machine run
perl -E '$_ = abs(0.10005 - 0.1000501); say; say "Test will fail" if $_>1e-7'
1.00000000002876e-07
Test will fail
So I am not sure what is going on here..
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
@pdupre0 Thanks for the comment. I think I am starting to understand what is going on: on line 38 we have:
This will compare 0.10005 and 0.1000501 by calculating (se line 96 in
where
since |
===========================================================================
Patrick DUPRÉ | | email: [email protected]
Laboratoire interdisciplinaire Carnot de Bourgogne
9 Avenue Alain Savary, BP 47870, 21078 DIJON Cedex FRANCE
Tel: +33 (0)380395988
===========================================================================
Sent: Friday, June 12, 2020 at 9:54 AM
From: "Håkon Hægland" <[email protected]>
To: "leto/math--gsl" <[email protected]>
Cc: "pdupre0" <[email protected]>, "Mention" <[email protected]>
Subject: Re: [leto/math--gsl] Make a new release supporting GSL 2.6 (#176)
@pdupre0 Thanks for the comment. I think I am starting to understand what is going on: on line 38 we have:
q{is_similar(0.10005,0.1000501, 1e-7)} => [ 0 ],
This will compare 0.10005 and 0.1000501 by calculating (se line 96 in Test.pm):
my $delta = abs($x-$y);
where $x = 0.10005 and $y = 0.1000501. The exact value of $delta should be 1e-7, but the creator of the test assumed (?) that the arithmetic was not exact. so $delta was assumed to be somewhat greater than 1e-7. Hence, on the next, line 97, we usually return a zero:
$delta > $eps ? diag qq{\t\t\$x=$x\n\t\t\$y=$y\n\t\tdelta=$delta\n} && return 0 : return 1;
since $eps == 1e-7. However on systems with quadmath (the systems where the test fails) $delta can become exactly equal to 1e-7 an so line 97 will return a 1 instead of the expected 0, and the test fails. Is this correct?
I do not think so.
You anticipate that the exact calculation would be less than 1e-7, and it may not happen.
Actually, even is the result of the calculation is exactly 1e-7, the result fails.
There is no reason to anticipate exactly 1e-7 by numerical calculation with limited precision (what ever it is) on floating number.
You just need to provide a tolerance on the calculation. For double if could be 1.0001e-7, for double double it can be a lot less.
Indeed this test is OK
perl -E '$_ = abs(0.10005000 - 0.10005010); say; say "Test will fail" if $_>(1e-7+1e-17)'
|
@hakonhagland the test is correct, the bug lies in Perl, GSL or Math::GSL, as per the comment |
I could give a 20 hour talk on writing tests dealing with floating point, but nobody would pay me 😅 @hakonhagland just disable these tests completely or make them TODO on the platforms that fail, is my suggestion. If you do fix those 12+ year old bugs, you definitely earn a 🍺 from me |
@leto Ok you are probably right.. still I do not get it though, look at this code at line 38:
the |
This test fails for perl 5.28.3 on GNU/Linux with quadmath. The reason is still unclear, see issue leto#176 for more information. We temporarily disable the test to make the test suite pass.
Exact floating-point comparison is a well-known problem, so I feel your pain here! I'm just looking at expanding PDL's support for GSL, so looking at this excellent project for ideas to "be inspired by, verbatim" (steal). Given that 0.41 supports 2.6, should this issue be closed and/or a new one opened for the precision issue? |
Yep.
The text was updated successfully, but these errors were encountered: