Multiprecision Arithmetic

[thetrime]

This is quite a big change. It implements arbitrary[1] precision arithmetic as follows:

• Integers are now represented by IntegerTerm, if possible, or BigIntegerTerm, if not
  • This means that instead of IntegerTerm.get(String image) the parser must now call NumericTerm.get(String image), which returns an appropriate numeric term
• Rational numbers of arbitrary[1] precision are represented by RationalTerm
• You can create a rational using arithmetic functions rdiv/2, rationalize/1 or rational/1
• Availability of this is all determined by vm.Evaluate.isUnbounded. If false, then very large integers parsed from the source turn into floats instead, and the rational functions are not supported (you'll get an evaluation error if you try to use them). The value of this is available via current_prolog_flag(bounded, X)

I've also added 39 tests (of which 18 are skipped if unbounded arithmetic is disabled). These turned up a few existing problems, like (5 >> 64) being given as 5 due to the way Java handles >>. I've fixed those here too.

Finally, I've added another flag vm.Evaluate.strictISO. If this is turned off, then we allow things that ISO doesn't, but make a lot of sense logically speaking. For example, float_fractional_part(3) gives 0, and float_integer_part(3) returns 3, even though ISO says we should raise a type error. Similarly, rounding functions on integers also just echo their input. It also recognises the atom nan as a FloatTerm with value Float.NaN, implements div/2 as integer division that rounds toward -infinity (which is useful since it is guaranteed to be consistent with mod/2), and implements gcd/2 as the GCD of 2 [big]integers

This should probably be documented somewhere, but I'm not entirely sure where. A new section of the manual? Under 'extending'? Is there a sensible way to configure the isUnbounded and/or strictISO flags? Maybe there's some ant option where we can generate a .java file and include that in the build?

(Given that you definitely do NOT want to change them during execution, and it seems like it'd be a real effort to provide access to the Environment or Interpreter while /parsing/, I think this is a compile-time setting, not a runtime one)

You might want to bump the version number for this as well (to 0.3.1 or 0.4.0).

1: (subject to available memory, of course)

[drt24]

A new section of the manual yes, probably a new top level section of the manual, something like "Additional features" (though I don't like that name). It is definitely possible to build a java file or a properties file at ant build time that contains flags like that, I would probably go for a properties file as that makes it easier to change?

[drt24]

This generally looks good. One question on the code, some documentation and some way of configuring it are all that remains to do. If you want documentation and configuration could be in a separate MR.

[thetrime]

I'll fix the documentation in this request, but I'm less excited about the configuration. If you have some experience with ant (something I really don't) then I'm happy for some concrete pointers. I spent about an hour trying to work out how to tell ant where to find javacc on my machine but in the end I just had to edit the build.xml and reset it after I'd finished testing, which seems like the /opposite/ of a convenient build system...

For now I'll add it under the "Adding more Prolog functionality" but I propose that (in a separate merge request) I consolidate this, modules and any other non-ISO stuff into a new section called either 'Extensions', 'Non-ISO Extensions' or 'GPJ Extensions' - whichever you prefer.

[drt24]

Fair. I learnt some ant for this project because that is what was there when I started but I certainly wouldn't use it for a new project (would probably use maven instead). If someone needs to change the configuration options then they can implement the feature of making that possible.

[drt24]

One minor comment on the documentation and then good to go.

[thetrime]

Documentation adjusted as requested