Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127017
Feedback-ID: i8414410d:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Tue, 01 Apr 2025 14:52:32 -0500
To: "php internals" <internals@lists.php.net>
Message-ID: <799bd54a-2136-4410-823a-9233ccbeb16a@app.fastmail.com>
In-Reply-To: <4a3c6ce7-102d-4cfe-a7a8-35630715b870@gmail.com>
References: <4a3c6ce7-102d-4cfe-a7a8-35630715b870@gmail.com>
Subject: Re: [PHP-DEV] [RFC brainstorm] Approximately equals operator
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: larry@garfieldtech.com ("Larry Garfield")

On Mon, Mar 31, 2025, at 5:03 PM, Niels Dossche wrote:
> Hi internals!
>
> I'm excited to share what I've been working on!
> I had an epiphany. I realized what we truly need to revolutionize PHP:=20
> a new operator.
>
> Hear me out.
> We live in an imperfect world, and we often approximate data, but=20
> neither `=3D=3D` nor `=3D=3D=3D` are ideal comparison operators to dea=
l with=20
> these kinds of data.
>
> Introducing: the "approximately equal" (or "approx-equal") operator=20
> `~=3D` (to immitate the maths symbol =E2=89=83).
> This combines the power of type coercion with approximating equality.
> Who cares if things are actually equal, close enough amirite?
>
> First of all, if `$a =3D=3D $b` holds, then `$a ~=3D $b` obviously.
> The true power lies where the data is not exactly the same, but "close=
 enough"!
>
> Here are some examples:
>
> We all had situations where we wanted to compare two floating point=20
> numbers and it turns out that due to the non-exact representation,=20
> seemingly-equal numbers don't match! Gone are those days because the=20
> `~=3D` operator nicely rounds the numbers for you before comparing the=
m.
> This also means that the "Fundamental Theorem of Engineering" now hold=
s!
> i.e. 2.7 ~=3D 3 and 3.14 ~=3D 3. Of course also 2.7 ~=3D 3.14. But thi=
s is=20
> false obviously: 2 ~=3D 1.
>
> Ever had trouble with users mistyping something? Say no more!
> "This is a tpyo" ~=3D "This is a typo". It's typo-resistant!
> However, if the strings are too different, then they're not=20
> approx-equal.
> For example: "vanilla" ~=3D "strawberry" gives false.
> How does this work?
> * The strings are equal if their levenshtein ratio is <=3D 50%, so it'=
s=20
> adaptive to the length.
> * If the ratio is > 50%, then the shortest string comes first in the=20
> comparison, such that if we ever get a `~<` operator, then "vanilla" ~=
<=20
> "strawberry".
>
> There is of course a PoC implementation available at:=20
> https://github.com/php/php-src/pull/18214
> You can see more examples on GitHub in the tests, here is a copy:
> ```php
> // Number compares
> var_dump(2 ~=3D 1); // false
> var_dump(1.4 ~=3D 1); // true
> var_dump(-1.4 ~=3D -1); // true
> var_dump(-1.5 ~=3D -1.8); // true
> var_dump(random_int(1, 1) ~=3D 1.1); // true
>
> // Array compares (just compares the lengths)
> var_dump([1, 2, 3] ~=3D [2, 3, 4]); // true
> var_dump([1, 2, 3] ~=3D [2, 3, 4, 5]); // false
>
> // String / string compares
> var_dump("This is a tpyo" ~=3D "This is a typo"); // true
> var_dump("something" ~=3D "different"); // false
> var_dump("Wtf bro" ~=3D "Wtf sis"); // true
>
> // String / different type compares
> var_dump(-1.5 ~=3D "-1.a"); // true
> var_dump(-1.5 ~=3D "-1.aaaaaaa"); // false
> var_dump(NULL ~=3D "blablabla"); // false
> ```
>
> Note that this does not support all possible Opcache optimizations=20
> _yet_, nor does it support the JIT yet.
> However, there are no real blockers to add support for that.
>
> I look forward to hearing you!
>
> Have a nice first day of the month ;)
> Kind regards
> Niels

Naturally, the degree of closeness for strings or for floats should be c=
ontrolled by an ini setting.  Maximum flexibility!

--Larry Garfield