|
From: Richard F. <fa...@gm...> - 2025-11-30 17:48:48
|
loading decfloat via load(decfp): the following commands work bfloat(%i) bfloat(3) but bfloat(3*%i) fails. bfloat(3*x) fails bfloat(3+x) fails The bug occurs inside a call to dectimesbigfloat, decaddbigfloat... There's a test to see if any of the parts of the product or sum are not convertible to decimal, in which case the usual (binary) bigfloat is used. but it then fails since it apparently cannot be converted to a bigfloat. If you really want a binary bigfloat, you could add, say, sin(bfloat(0)) to any decimal expression and you'll get a binary bigfloat, somaybe you don't need to "turn off" decimals. I will look at this some more, but I suspect this used to work, and a change somewhere else (such as improved type checking) causes this error. RJF On Sun, Nov 30, 2025 at 8:52 AM Barton Willis via Maxima-discuss < max...@li...> wrote: > *Reminder: * After running the share testsuite, don't expect floating > point calculations to work. The culprit is the decimal float package. > There is a source code comment in testsuite.lisp saying that this test > needs to be the last. > > This morning, I consumed a third cup of coffee puzzling over why Maxima > was giving an error for bfloat(%i/sqrt(3)). > > Maybe somebody can figure out a way to allow Maxima to "unload" this > package and restore Maxima to as it was before loading. > > Don't get me wrong: the decimal float package is worthy, but using it > could confuse users (like me). > > Example > > %i1) bfloat(%i/sqrt(3)); > > Maxima encountered a Lisp error: > > The value NIL is not of the expected type NUMBER. > _______________________________________________ > Maxima-discuss mailing list > Max...@li... > https://lists.sourceforge.net/lists/listinfo/maxima-discuss > |