[RFC] Floating Point support in GMP extension

My only concern is GMP float and int conversion.
I prefer to have result

10 / 3 = 3

and

10.0 / 3 = 3.33333333333333333333333(to GMP precision)

I prefer to have INT result for "INT op INT" and float result for "FLOAT op
INT". Huge integer arithmetic has it's own usage and converting int to
float automatically is not nice, since it breaks goodies of GMP int. I hope
everyone prefer this behavior.

I agree with this, pure-int operations should have a pure-int result.
Making GMP(10) / GMP(3) return a float now would also be fatal in case we
want to later introduce support for rationals or decimals in GMP (which
could just as well be the result of 10/3). On the same note I'd also
suggest to call the ini setting gmp.default_float_precision (to
disambiguate from a potential gmp.default_decimal_precision in the future).

Some more thoughts / suggestions:

• I would consider not making the type an internal flag exposed via
  gmp_isint() and gmp_isfloat() methods, but use two different class entries
  for them. I.e. have GmpInt and GmpFloat (as the GMP class name is not
  released yet, we can still nicely do this change). Maybe with a GmpNumber
  supertype implemented by all current and future GMP types. This would make
  dumps/serialization more obvious and forward-compatible, allow typehints,
  etc. Type can then be checked with $n instanceof GmpInt or $n instanceof
  GmpFloat (though one could still add the gmp_isint and gmp_isfloat
  functions, not sure how useful they would be though). This especially seems
  like the way to go if we want to add more GMP number types in the future
  (will prevent us from having an "int or float or decimal or rational"
  type...)

• The gmp_init_float() should likely also have a precision parameter. Given
  that non-decimal floating point bases are a rarity (?), maybe put it before
  the base argument?

• You'll likely need something like gmp_float_random() to accompany
  gmp_random(). (Hopefully using a sane parameter without limb size
  dependence ;)

• Additionally to gmp_cmp I'd also add a function gmp_float_equals or
  gmp_float_eq which exposes mpf_eq. Comparing floats is always a PITA and
  exposing that functionality would be greatly helpful ;)

• Is there any way to get rid of the locale-dependent behavior of
  mpf_set_str? This sounds like it could be a big pain. (Especially given how
  gmp floats are not what you use with your average user input, so seems
  little useful.)

That's it ... for now :)
Nikita

Also, I'm not sure how exactly "all other gmp_*() functions" are
supposed to work on floats - for many of them it just make no sense
(such as factorial or q/r division or modulo), for others like bit
functions it technically could make sense but would probably be not
useful since nobody does bit ops on floats... Maybe it would make more
sense to look into what GMP library does with floats and write different
function set from there?

Well, I note that you can do bitwise operations on floats in PHP as it
stands, although obviously this is accomplished by rounding. I don't see
why we shouldn't allow this for GMP floats, even though its applications
are likely limited.

--
Andrea Faulds
http://ajf.me/

I have a question here: why we must keep gmp integers and gmp floats
within the same object? They have different types in GMP library, PHP
has different types for ints and floats, internally in PHP they would be
using different code and different structures, API would be different -
why have the same object at all?

I considered that approach too (and even had it in my initial draft as
"proposal#2"), but what I ended up putting into the RFC felt more
"PHP" to me (in that we're dealing with a number, not an int versus a
float necessarily). I'm totes not averse to having GMPInt and
GMPFloat (descended from abstract GMPNumber); After all, that's what
the discussion period is for.

Also, I'm not sure how exactly "all other gmp_*() functions" are
supposed to work on floats - for many of them it just make no sense
(such as factorial or q/r division or modulo), for others like bit
functions it technically could make sense but would probably be not
useful since nobody does bit ops on floats... Maybe it would make more
sense to look into what GMP library does with floats and write different
function set from there?

On a case by case basis. As you say, some of those cases will be
"throw an error on trying to use a float", and some functions would be
new.

For common stuff though, like gmp_add(), I think it'd be silly to have
gmp_add() + gmp_float_add() as separate APIs, especially since one
would have to be smart enough to handle Int+Float mixing anyway. ((Or
you'd have to perform explicit casts, e.g.: $three = gmp_add(
gmp_init("1") + gmp_int(gmp_float_init("2.0")) );

-Sara