Open JCumin opened 8 years ago
That's definitely an awesome idea and would certainly be possible with CLP(FD).
I do not expect any problems with this approach. You can have float(M,E)
and integer(I)
to symbolically distinguish the cases and carry over the information about types so that integer operations remain efficient. SWI does something very similar internally (tags denote the type of the number).
However, how about taking it up a notch and aiming even higher? I see basically two very promising options, both of which could be implemented in Brachylog and would provide a rather unique selling point over many other languages even beyond typical golfing languages:
?- X is 1 rdiv 2 + 1 rdiv 3.
. This would definitely come in handy in Brachylog and would be comparatively easy to implement.Especially regarding unums, I will help in every way I can to produce a Prolog implementation. Later, we can even move it to the SWI core. See also the unum page by Ulrich Neumerkel, who may also be interested in these developments.
@triska Rational numbers are available for free, but they present the same problem that low-level arithmetic has as far as I see, e.g. 5 rdiv 6 is X rdiv 2 + 1 rdiv 3.
returns an Arguments are not sufficiencly instantiated
error.
@triska As for unums, it would indeed be harder to implement, especially considering that the publications on the subject are relatively sparse and not very extensive (excluding the book which I don't have access to)
For constraint solving over rational numbers, I recommend CLP(Q) constraints, available as library(clpq)
in SWI-Prolog. For example:
?- use_module(library(clpq)). true. ?- { 5/6 = X/2 + 1/3 }. X = 1.
You are perfectly right to expect more than (is)/2
!
CLP(Q) constraints should be your default when using rational numbers.
is this still open for addition?
Use something like
'float':Mantissa:Exponent
to represent floats in the transpiler and built-ins, so that we can apply constraints on the mantissa and exponent of a floating point number.This could be used to actually model all numbers but I think that would destroy performance on integer arithmetic if it was like that.
@triska would probably have a better idea about whether this is a good idea or not?