Re: [RFC] Floating Point support in GMP extension

On Sat, Jan 4, 2014 at 9:38 PM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote: > 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