Maxima seems to try and use floating point for some comparisons of large integers. Of course, large integers might not fit in a float:
Maxima 5.33.0 http://maxima.sourceforge.net using Lisp ECL 12.12.1 Distributed under the GNU Public License. See the file COPYING. Dedicated to the memory of William Schelter. The function bug_report() provides bug reporting information. (%i1) is (notequal(84644440725961403098463183554485799389772425728699536724546678651368471662755793858191462623325951275455550962101277270763335324980423888503086416881487600951168887632284102290001262851926718316596582705934285641705714110547524777517804311041930987129930496818273454551255885915706318740821679919000000000000000000000*x/422165920314471048721358275854632323285179941428330150821135511815100042994592631347355397175387243022779234708963662480477375868719044084318634583443223137428890926160543699705457864438134730545535596936604372279922247951010042249163649352110753480952771747316504857000652757440826179465253453626540111934123296968384641+2097152/10460353203,0)); Maxima encountered a Lisp error: #<a ARITHMETIC-ERROR>
This error arose from a sage bug report: http://trac.sagemath.org/ticket/14965 so while the example may seem contrived, someone actually did stumble into this.
Robert Dodier
2014-06-29
A stack trace shows that Maxima got stuck trying to compare the left-hand side to items in the assume database. (It reaches that step after trying some other things.) Some of the assume db things are floating point values of constants such as 1.161..., 2.718..., and 3.141... -- that's how floating point arithmetic comes into play.
I think the only way around the problem is to strengthen the floating point comparison -- catch the error and retry it with bigfloat arithmetic, maybe. I don't think it's reasonable to try to avoid the floating point arithmetic in comparisons, since that would mean avoiding the assume database -- I wouldn't want to try to reimplement the comparison functions.
Robert Dodier
2014-06-29
Nils Bruin
2014-06-30
I think the only way around the problem is to strengthen the floating point comparison -- catch the error and retry it with bigfloat arithmetic,
If you know you're comparing here, I don't think there's a need to retry: when the conversion fails, equality can't possibly hold, can it? There may be subtleties that prevent such a simplistic approach from working properly of course.
Robert Dodier
2014-08-21
Diff:
--- old +++ new @@ -1,5 +1,6 @@ Maxima seems to try and use floating point for some comparisons of large integers. Of course, large integers might not fit in a float: +~~~~ Maxima 5.33.0 http://maxima.sourceforge.net using Lisp ECL 12.12.1 Distributed under the GNU Public License. See the file COPYING. @@ -10,5 +11,6 @@ Maxima encountered a Lisp error: #<a ARITHMETIC-ERROR> +~~~~ This error arose from a sage bug report: http://trac.sagemath.org/ticket/14965 so while the example may seem contrived, someone actually did stumble into this.
Robert Dodier
2014-08-21
Fixed by commit 1c6327b11. Closing this report.
Robert Dodier
2014-08-21