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
Upgrade arb to 2.6.0 #18560
Comments
Branch: u/cheuberg/libs/arb-2.6.0 |
Commit: |
Changed keywords from none to arb |
New commits:
|
Branch pushed to git repo; I updated commit sha1. New commits:
|
comment:3
Replying to @sagetrac-git:
Perhaps it would be better to add tolerances so that the tests pass with both versions of arb. What do you think? |
comment:4
Replying to @mezzarobba:
|
comment:5
Replying to @cheuberg:
The tolerance simply applies independently to the center and the radius, so that in many cases |
comment:6
This builds and passes its test suite on OS X 10.10.3. |
comment:7
|
comment:9
Replying to @jdemeyer:
I do not understand what happened.
which is what the checksum should be. I now put a copy of the tar.gz file to http://www.math.aau.at/user/cheuberg/sage/arb-2.6.0.tar.gz , could you please try that file (which also has a better file name for our purposes)? Thank you. As I cannot reproduce the problem, I set the ticket back to needs_review. |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
comment:13
OK, the problem was that |
comment:14
Why are you choosing absolute tolerances over relative tolerances in the doctests? |
comment:15
Can you make the files |
comment:16
About the doctests: I would actually prefer to just change the doctests without tolerance. It's kind of ugly to have to add tolerances everywhere. And most tests don't change, so it's not so bad. |
Branch pushed to git repo; I updated commit sha1. New commits:
|
comment:19
Replying to @jdemeyer:
In most cases, the relative changes in the radius is around 0.1, but I would not like to allow a relative tolerance of 0.1 for the center of the ball. Unless there is a way of specifying different relative tolerances for radius and center of the ball? |
comment:20
Replying to @jdemeyer:
It might well be the case that the tolerances I introduced above might be too small when the upgrade to the next arb version or that other tests require new tolerances. At the moment, we could easily go back to the modified doctests I already reverted once. And switching back to tolerances when we realize that we keep changing doctests with every arb version would not to be hard, either. OTOH: I am not sure whether all machines will return the same error in all computations, but that's perhaps something that Fredrik could comment on? Marc, you suggested using tolerances. Any further comments on this issue? |
comment:21
Replying to @cheuberg:
As far as I understand, yes, they will.
Not really. I agree with you on the choice of absolute tolerances, and I don't understand Jeroen's argument against tolerances, but honestly I don't care much. |
comment:22
Replying to @mezzarobba:
The problem with tolerances is:
|
comment:23
Results can differ on 32-bit and 64-bit system but this should not happen often. Gratuitous nondeterminism is avoided, but it's safest to think of arb as actually employing randomization, which unfortunately doesn't play well with doctesting. Two reasonable workarounds would be:
|
comment:24
The two statements seem to contradict each other: Replying to @fredrik-johansson:
|
comment:25
Replying to @fredrik-johansson:
If we go with this, I would not make a difference between normal interactive Sage output and doctests. Just print balls with fewer digits always, like we already do for
This would require writing a much more complicated doctest parser (remember you don't just want balls, but also polynomials/lists/matrices with ball coefficients and then you'll also want support for complex numbers, mpfi intervals and who knows what), I don't think this is a realistic solution. |
comment:27
Replying to @jdemeyer:
I do not like the idea of always printing less information than we actually have. After all, we precisely know the error, so dilluting it seems somehow crude. |
comment:28
Replying to @cheuberg:
On the other hand, when do you really care about seeing the last few digits in a many-digit number? Like I said, we are already printing elements of |
comment:29
Replying to @jdemeyer:
What I mean is that you might run through billions of values before you see a difference, but if you assume that a difference never occurs and implicitly base your code on this assumption (perhaps forgoing using the radius information before converting output to floating-point numbers), then it could potentially bite you in a serious way when it does. |
comment:30
Replying to @fredrik-johansson:
Well, doctests never "bite you in a serious way" so I'm willing to take my chances here. If the problem turns out to be more common then expected, we can still change our strategy. |
comment:31
As for the number of digits to print, why not print many digits by default but do something like this in (some of the) doctests:
|
comment:32
Replying to @fredrik-johansson:
-1 because it clutters the doctests for no obvious advantage. |
Changed branch from u/cheuberg/libs/arb-2.6.0 to u/cheuberg/libs/arb-2.6.0-no-tolerance |
comment:33
Replying to @jdemeyer:
There is only one way to find out how common that problem will be ... Thus I attach a branch without tolerances, but with modified doctests (as before), plus New commits:
|
Reviewer: Jeroen Demeyer |
Changed branch from u/cheuberg/libs/arb-2.6.0-no-tolerance to |
Upgrade the optional arb spkg to version 2.6.0.
Tar.gz file at https://www.math.aau.at/user/cheuberg/sage/arb-2.6.0.tar.gz
CC: @mezzarobba @fredrik-johansson @jhpalmieri
Component: packages: optional
Keywords: arb
Author: Clemens Heuberger
Branch/Commit:
922b674
Reviewer: Jeroen Demeyer
Issue created by migration from https://trac.sagemath.org/ticket/18560
The text was updated successfully, but these errors were encountered: