> Because the result is an infinite repeating decimal, in my opinion, your
Decimal class should not allow such a division without explicitly
specifying a scale and a rounding mode. In other words, I would expect an
exception here.
There is already an internal flag for inexact division, but is curr
al) pure
> PHP implementation.
>
>
> A new PHP extension that would provide native arbitrary precision numbers
> with an OO API would be welcome, IMO.
>
> Maybe brick/math can help inspire your API?
>
>
> Benjamin
>
> Le 29 sept. 2018 à 01:05, Rudi Theunissen
ce is here: https://github.com/php-decimal/extension
Thank you. :)
Rudi
On Sat, Sep 29, 2018 at 10:45 AM Rudi Theunissen
wrote:
> GNU MPFR looks solid too, significantly faster because it uses base 2
> storage, but may have difficulty converting to decimal. I'll fork a version
I believe that many projects, especially in finance and science, can
benefit from a fast, friendly, PHP 7+ decimal library.
On Sat, Sep 29, 2018, 10:25 Rudi Theunissen wrote:
> I wrote a basic benchmark and GMPi appears to be about twice as fast (+
> and - ops) but produces a different
7;s a bug we can solve here, rather than a fundamental accuracy
issue, GMPi looks promising. 😊
See: https://gist.github.com/rtheunissen/973ea1719c02a4204dabfe9dffd78c4b
On Sat, Sep 29, 2018, 07:20 Sara Golemon wrote:
> On Fri, Sep 28, 2018 at 6:06 PM Rudi Theunissen
> wrote:
> >
t; Looks promising! Could it be added to PECL maybe? That would make it
> easier for people to test :D
>
> On Sat, 29 Sep 2018 at 17:46, Rudi Theunissen wrote:
>
>> Actually yes! You mentioned it to me 5 months ago in a thread on Reddit:
>>
>> https:
lemon wrote:
> On Fri, Sep 28, 2018 at 6:06 PM Rudi Theunissen
> wrote:
> > I've been working on adding arbitrary precision decimal support as an
> > alternative to *bcmath. *I have created an extension based on
> *mpdecimal*,
> > which is what Python 3's
to discuss the API
and implementation with internals first.
See: https://github.com/php-decimal/php-decimal
Any advice, commentary or objection is welcome. :)
Thank you,
Rudi Theunissen
I'm sorry that this email created a new thread on externals.io - not sure
how to avoid that.
On Sun, 8 Jul 2018 at 18:51, Rudi Theunissen wrote:
> Hi everyone,
>
> This RFC is now final; no decision will be changed unless there is a very
> good reason to do so. I'm happ
Hi everyone,
This RFC is now final; no decision will be changed unless there is a very
good reason to do so. I'm happy with the approach in detail and available
to address any further concerns.
I'm waiting on the sidelines of the potential changes to the release
schedule, but would like to ask wh
This discussion has moved to the RFC thread here:
https://externals.io/message/102473
On Mon, 25 Jun 2018 at 07:56, Rudi Theunissen wrote:
> The part I found difficult was in the handlers - we only have `compare`,
> no equals.
> The only way we can have the handler differentiat
The part I found difficult was in the handlers - we only have `compare`, no
equals.
The only way we can have the handler differentiate between equality and
ordering
is if we pass a parameter to the handler, which means we'd have to change
the header.
From:
`typedef int (*zend_object_compare_zvals
hing
goes through `compare_function`.
On Sun, 24 Jun 2018 at 23:31, Levi Morrison wrote:
> On Sun, Jun 24, 2018 at 2:31 PM Rudi Theunissen
> wrote:
> >>
> >> Other languages (most? all?) separate equality and ordering for this
> reason.
> >
> >
> > J
malised to
-1, 0 and 1, but `null` will fall through.
I'm going to draft an RFC based on this approach with some clear examples.
:)
On Sun, 24 Jun 2018 at 16:31, Rudi Theunissen wrote:
> Other languages (most? all?) separate equality and ordering for this
>> reason.
>
>
> Java
>
> Other languages (most? all?) separate equality and ordering for this
> reason.
Java doesn't really separate them. Their `==` always checks object
reference so is like PHP's ===.
But they do have the .equals() method on all objects (our ==) and the
collections use that for equality.
In these
or.
My vote at the moment would go to #3 or #4 because it's the most flexible
and the NULL is an edge-case.
On Sun, 24 Jun 2018 at 11:30, Levi Morrison wrote:
> On Sun, Jun 24, 2018 at 8:11 AM Rudi Theunissen
> wrote:
> >
> > Here is a WIP implementation of `__compareTo
Here is a WIP implementation of `__compareTo`, with some decent tests.
https://github.com/php/php-src/compare/master...rtheunissen:rt-compare-to-magic-method?diff=unified
On Fri, 22 Jun 2018 at 17:03, Rudi Theunissen wrote:
> On further investigation, I'm not sure if we need both `
a's `Comparable` interface considers a
0-return
to indicate equality, where a `==` would compare references in the same way
PHP's `===` would. So in dropping the `__equals` method, we're slightly more
aligned with Java, even though that's not exactly the goal here. :p
On Fri, 22
all first.
On Fri, 22 Jun 2018 at 13:06, Rudi Theunissen wrote:
> > Yes, that's the type of thing that I think needs to be included as
> > part of the RFC.
> >
> > Including a list of all the (or at least the important) functions that
> > would be affected
cases.
Absolutely. I was hoping to gather some thoughts and opinions first while I
work on the implementation before I submit an official RFC. I'll make sure
to
include what you've mentioned, I completely agree.
On Fri, 22 Jun 2018 at 11:14, Dan Ackroyd wrote:
> On 22 June 2
>
> In my opinion we should have functions which take comparator and/or
> equality functions as parameters even if we can override these
> operators.
I really like this idea, because it puts the responsibility of the
definition on the caller. It
allows you to do things like "Is there an instance
in
having it be part of the language.
Not sure if that is a strong enough case, happy to elaborate some more and
provide some code.
On Thu, 21 Jun 2018 at 10:59, Dan Ackroyd wrote:
> On 21 June 2018 at 10:27, Rudi Theunissen wrote:
> > The Comparable RFC (http://wiki.php.net/rfc/com
The Comparable RFC (http://wiki.php.net/rfc/comparable) was written in 2010
and
revised in 2015 by Adam Harvey, but was not conclusive. I would like to take
on some shared responsibility to push this forward and re-open the
discussion.
Why is this useful, and why should it be added to PHP?
1. Th
Bug: https://bugs.php.net/bug.php?id=63217
PR: https://github.com/php/php-src/pull/2607
Demo: https://3v4l.org/dagUP
I've heard mixed responses to this bug and the approach to fix it (or
whether we should at all). The two common opinions are that ArrayAccess
should behave exactly like an array,
24 matches
Mail list logo
