Comment by nsajko | Hacker News Reader

Comment by nsajko | Hacker News Reader

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://fricas.github.io

https://github.com/fricas/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.

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.

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.

> 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.

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.

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.

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.

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

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.

Reply on news.ycombinator.com