5 ms·

A problem with Julia is that it does not parse input numbers with arbitrary precision by default. Example: julia> sin(1.461920290375737576933544899379e+31)

by nsajko 6y ago

A problem with Julia is that it does not parse input numbers with arbitrary precision by default. Example: julia> sin(1.461920290375737576933544899379e+31) -0.9468766486679395 julia> sin(parse(BigFloat, "1.461920290375737576933544899379e+31")) 0.6864670207863400975666631018263839509022548965872940746039593018855528710432756 Fricas is better in this regard, some links: https://en.wikipedia.org/wiki/FriCAS https://en.wikipedia.org/wiki/FriCAS https://fricas.github.io https://fricas.github.io https://github.com/fricas/fricas https://github.com/fricas/fricas http://www.euclideanspace.com/prog/scratchpad/fricas/ http://www.euclideanspace.com/prog/scratchpad/fricas/ EDIT: some info about FriCAS: it's implementation is currently based on Common Lisp, on top of which a language called "Spad" (short for Scratchpad) is implemented. Fricas is a fork of the Axiom computer mathematics system, which in turn is a continuation of Scratchpad. EDIT: and, at least with SBCL, it can use GMP for bignum. I only skimmed the article, but I believe Fricas supports all uses of Julia mentioned in the article, and more, like advanced symbolic integration.

baggepinnen 6y ago
This is unlikely to be a problem for the vast majority of people using julia as a calculator
- nsajko 6y ago
  The problem is that you won't know when your results are wrong because of low input precision. And when you do know, things will be a bit more complicated.
eigenspace 6y ago
You can do julia> big"1.461920290375737576933544899379e+31" 1.461920290375737576933544899379e+31 julia> sin(big"1.461920290375737576933544899379e+31") 0.6864670207863400975666631018263839509022548965872940746039593018855528710432756 to succinctly parse arbitrary precision literals.
johnmyleswhite 6y ago
It seems like it would be pretty easy to make a REPL mode that did the big conversions automatically. Not sufficient to protect a naive user, but arbitrary precision floating point is never safe.
- nsajko 6y ago
  > arbitrary precision floating point is never safe Care to expand on that? Are you advocating for interval arithmetic or maybe decimal floating point? For what it's worth I think that one would rarely need to interactively deal with so much data at once that using, say, 10000 bit binary floating point would be prohibitive. It is difficult to lose the necessary significant digits with so much "safety margin", and one still has space for about a million of such high-precision floating point numbers.
  - johnmyleswhite 6y ago
    I agree with your assertion that most users could get away with 10,000 bits. My point is only that there's always going to be somebody who still tries to do something that fails, so you have to pick some set of tradeoffs. Yours seems reasonable.
the_svd_doctor 6y ago
For a "computational math" (ish) language, having FP64 as the default number format seems pretty reasonnable to me. Cases where one needs bignums of course exist, but I think they are less common. Usually if you need arbitrary precision, you know it.
- nsajko 6y ago
  Turns out I wish I could delete my top-level comment now, because I realized that because of Julia's type conversion and promotion semantics a user would actually not get into the problems I worried about.

by nsajko 6y ago

baggepinnen 6y ago

This is unlikely to be a problem for the vast majority of people using julia as a calculator

nsajko 6y ago
The problem is that you won't know when your results are wrong because of low input precision. And when you do know, things will be a bit more complicated.

eigenspace 6y ago

You can do julia> big"1.461920290375737576933544899379e+31" 1.461920290375737576933544899379e+31 julia> sin(big"1.461920290375737576933544899379e+31") 0.6864670207863400975666631018263839509022548965872940746039593018855528710432756 to succinctly parse arbitrary precision literals.

johnmyleswhite 6y ago

It seems like it would be pretty easy to make a REPL mode that did the big conversions automatically. Not sufficient to protect a naive user, but arbitrary precision floating point is never safe.

nsajko 6y ago
> arbitrary precision floating point is never safe Care to expand on that? Are you advocating for interval arithmetic or maybe decimal floating point? For what it's worth I think that one would rarely need to interactively deal with so much data at once that using, say, 10000 bit binary floating point would be prohibitive. It is difficult to lose the necessary significant digits with so much "safety margin", and one still has space for about a million of such high-precision floating point numbers.
- johnmyleswhite 6y ago
  I agree with your assertion that most users could get away with 10,000 bits. My point is only that there's always going to be somebody who still tries to do something that fails, so you have to pick some set of tradeoffs. Yours seems reasonable.

the_svd_doctor 6y ago

For a "computational math" (ish) language, having FP64 as the default number format seems pretty reasonnable to me. Cases where one needs bignums of course exist, but I think they are less common. Usually if you need arbitrary precision, you know it.

nsajko 6y ago
Turns out I wish I could delete my top-level comment now, because I realized that because of Julia's type conversion and promotion semantics a user would actually not get into the problems I worried about.