Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:71003
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.219.51 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAGa2bXbn-GV7OERZfdwfPB34P8z-Cx1xagGWjzxRHe4ZcGXSoQ@mail.gmail.com>
References: <CAESVnVo07=6hq2qZvoDodYttRA-Ag9n+h=UAEkdYwbv0TFXXKw@mail.gmail.com>
	<CAGa2bXbn-GV7OERZfdwfPB34P8z-Cx1xagGWjzxRHe4ZcGXSoQ@mail.gmail.com>
Date: Sat, 4 Jan 2014 22:49:50 +0100
Message-ID: <CAF+90c8emWM0kDq9SUbCLZzJqAFrB5JOCYqq3yAoC9Ho3s1n2w@mail.gmail.com>
To: Yasuo Ohgaki <yohgaki@ohgaki.net>
Cc: Sara Golemon <pollita@php.net>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a113306f2870cf004ef2c0176
Subject: Re: [PHP-DEV] [RFC] Floating Point support in GMP extension
From: nikita.ppv@gmail.com (Nikita Popov)

--001a113306f2870cf004ef2c0176
Content-Type: text/plain; charset=ISO-8859-1

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

--001a113306f2870cf004ef2c0176--