Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:127020 X-Original-To: internals@lists.php.net Delivered-To: internals@lists.php.net Received: from php-smtp4.php.net (php-smtp4.php.net [45.112.84.5]) by qa.php.net (Postfix) with ESMTPS id C98F51A00BC for ; Tue, 1 Apr 2025 20:25:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1743538986; bh=QL15lhW8ovB0xQ8VZLOZ++NHDrEHMnb+ojKr/+PTuN8=; h=Date:From:To:In-Reply-To:References:Subject:From; b=S+mIDwKRPAzLIVVCM97DH2ffjONEUxaqoQc0FCjuCn23Nf18XROpgYHAs0KIRJsRU Tz+Mokn6MdoR2BzUAPosKr4V8RDebV32FAEr+ZZxSxRQsW8eCpZf3xahtxQAMzyhjZ 3UYlhW7VvFLxib6j6jtMGvgsJoYUufeRNbixWtWNP5xrgiDzHdu8AanviaSaoeIEaZ oDctlGJIw2sX/1vM9PAqGR2iObA6mLnya6RnQqYONsMPMChIbiLL4hrwmIt+g7bgYx hR0PlIAFmJoG26unO9+7XJWiTp2e+FwKp3rFIW0IBhh07UElcNJYH9P6JMlYvHKDxs p+tD85DRukbsw== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id CC2BC180034 for ; Tue, 1 Apr 2025 20:23:05 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_05,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,DMARC_MISSING,HTML_MESSAGE, RCVD_IN_DNSWL_LOW,SPF_HELO_PASS,SPF_PASS autolearn=no autolearn_force=no version=4.0.0 X-Spam-Virus: No X-Envelope-From: Received: from fout-a5-smtp.messagingengine.com (fout-a5-smtp.messagingengine.com [103.168.172.148]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Tue, 1 Apr 2025 20:23:05 +0000 (UTC) Received: from phl-compute-11.internal (phl-compute-11.phl.internal [10.202.2.51]) by mailfout.phl.internal (Postfix) with ESMTP id E96D81383DD6; Tue, 1 Apr 2025 16:25:31 -0400 (EDT) Received: from phl-imap-09 ([10.202.2.99]) by phl-compute-11.internal (MEProxy); Tue, 01 Apr 2025 16:25:31 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bottled.codes; h=cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm3; t=1743539131; x=1743625531; bh=KsTeN1Meku EPPcJMPCDf6hxsRxYAwmVoWewOpO2lusE=; b=GBjytmzvpiz6oA6c/EekREki7K 7IPe/97VEjRZ7d3ZbZ4gFqC+DKyummikPNm0kCPNcIJdwMLKUQDu5qEGIyrXMveI 0T+Cc212vtJZco3QtnNyWRlg2uKUIG6B3OfDdwBymjbGW+rtIRiOXo9e7r7Jz4kU 78LqCq+1Rkek45G9DmtZvWvWIgDFQlThfX49MKv4Jfc9o7U4U5l6Nh/z3ZdaOLGd U3NIfO5ttAG3uiGK1swBmQrE+12rNdMAnFtYhkMt5aUa24a08hoN6YCALL7Lj9Kx P1Bp8GJw7MUhQXRJtn9ozN2bF7ydnZuTWjWfiE7qxOGtQ2tCG6PJCl0521Gw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t= 1743539131; x=1743625531; bh=KsTeN1MekuEPPcJMPCDf6hxsRxYAwmVoWew OpO2lusE=; b=YXLcA1mysjQfI9mtwXmzfqx/MaCNiseWekHwQmwY9PfF9wvQD0k NY6YffbjdNQEj1DeurgMfc4kLp24qDwbg9QDwnFUDFmujCHk5sZAz0WFVo1fy4y3 vhC/CRBqYw+gI9CEw6uIZ1jdaxPcU8Q9HvSKPZEVMjvklexdXZMvm+TJbmlOi0vC 4OseiWV35LpD1nT0NM9N2TBwWOi8m4p5u5K7OtYVYkdCqk9wqnX6NPgDfmFZzHsz SpNGcnLxln0bFz9c8xbxMmgrj+iFV2gP/TpinYSop51QACtmclDhtJS3gslwYi4C u8R0gJdzwzQDmFodPiT5uNfs9f4g+cPvGtw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgddukeefjeefucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggv pdfurfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpih gvnhhtshculddquddttddmnecujfgurhepofggfffhvffkjghfufgtsegrtderreertdej necuhfhrohhmpedftfhosgcunfgrnhguvghrshdfuceorhhosgessghothhtlhgvugdrtg houggvsheqnecuggftrfgrthhtvghrnhepiedthffhvdffhfettdfgveefgfeugeegudeu keejheeigefghfeiveelfeefueefnecuffhomhgrihhnpehgihhthhhusgdrtghomhenuc evlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehrohgssegs ohhtthhlvggurdgtohguvghspdhnsggprhgtphhtthhopeefpdhmohguvgepshhmthhpoh huthdprhgtphhtthhopehlrghrrhihsehgrghrfhhivghlughtvggthhdrtghomhdprhgt phhtthhopehinhhtvghrnhgrlhhssehlihhsthhsrdhphhhprdhnvghtpdhrtghpthhtoh epuggvrhhitghksehphhhprdhnvght X-ME-Proxy: Feedback-ID: ifab94697:Fastmail Received: by mailuser.phl.internal (Postfix, from userid 501) id 89833780068; Tue, 1 Apr 2025 16:25:31 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface Precedence: bulk list-help: list-post: List-Id: internals.lists.php.net x-ms-reactions: disallow MIME-Version: 1.0 X-ThreadId: T56bad387c0567f45 Date: Tue, 01 Apr 2025 22:25:10 +0200 To: "Derick Rethans" , internals@lists.php.net, "Larry Garfield" Message-ID: <371df6b7-2c4b-4bb6-b711-162e512ce145@app.fastmail.com> In-Reply-To: <89495A22-BCBD-4779-835D-56B90257FF51@php.net> References: <4a3c6ce7-102d-4cfe-a7a8-35630715b870@gmail.com> <799bd54a-2136-4410-823a-9233ccbeb16a@app.fastmail.com> <89495A22-BCBD-4779-835D-56B90257FF51@php.net> Subject: Re: [PHP-DEV] [RFC brainstorm] Approximately equals operator Content-Type: multipart/alternative; boundary=8f163078bd6b4c86a90b47c141187b7f From: rob@bottled.codes ("Rob Landers") --8f163078bd6b4c86a90b47c141187b7f Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Tue, Apr 1, 2025, at 22:17, Derick Rethans wrote: > On 1 April 2025 20:52:32 BST, Larry Garfield = wrote: > >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 P= HP:=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 = deal 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 equalit= y. > >> 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 "cl= ose 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 th= e=20 > >> `~=3D` operator nicely rounds the numbers for you before comparing = them. > >> This also means that the "Fundamental Theorem of Engineering" now h= olds! > >> i.e. 2.7 ~=3D 3 and 3.14 ~=3D 3. Of course also 2.7 ~=3D 3.14. But = this 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 th= e=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 b= e controlled by an ini setting. Maximum flexibility! > > > >--Larry Garfield >=20 > You got to be joking! Everybody knows ini settings make things unporta= ble. I suggest we introduce AI to determine the closeness instead. >=20 > cheers > Derick >=20 We have to be careful not to tie ourselves to a specific AI model. But w= e can use ini settings to allow the user to specify which model to use. =E2=80=94 Rob --8f163078bd6b4c86a90b47c141187b7f Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
On Tue, Apr 1, = 2025, at 22:17, Derick Rethans wrote:
On 1 April 2025 20:52:32 BST, Larry Garfield = <larry@garfieldtech.com= > wrote:
>On Mon, Mar 31, 2025, at 5:03 PM, Niels Do= ssche wrote:
>> Hi internals!
>>=
>> I'm excited to share what I've been working on!<= br>
>> I had an epiphany. I realized what we truly need = to revolutionize PHP: 
>> a new operator.
>>
>> Hear me out.
>= > We live in an imperfect world, and we often approximate data, but&n= bsp;
>> neither `=3D=3D` nor `=3D=3D=3D` are ideal c= omparison operators to deal with 
>> these kind= s of data.
>>
>> Introducing: th= e "approximately equal" (or "approx-equal") operator 
>> `~=3D` (to immitate the maths symbol =E2=89=83).
>> This combines the power of type coercion with approximating eq= uality.
>> Who cares if things are actually equal, c= lose 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 
<= /div>
>> numbers and it turns out that due to the non-exact re= presentation, 
>> seemingly-equal numbers don't= match! Gone are those days because the 
>> `~=3D= ` operator nicely rounds the numbers for you before comparing them.
<= /div>
>> This also means that the "Fundamental Theorem of Engi= neering" now holds!
>> i.e. 2.7 ~=3D 3 and 3.14 ~=3D= 3. Of course also 2.7 ~=3D 3.14. But this is 
>&g= t; false obviously: 2 ~=3D 1.
>>
>&= gt; Ever had trouble with users mistyping something? Say no more!
>> "This is a tpyo" ~=3D "This is a typo". It's typo-resis= tant!
>> However, if the strings are too different, = then they're not 
>> 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 
<= /div>
>> adaptive to the length.
>> * If t= he ratio is > 50%, then the shortest string comes first in the <= br>
>> comparison, such that if we ever get a `~<` op= erator, then "vanilla" ~< 
>> "strawberry".<= br>
>>
>> There is of course a PoC i= mplementation available at: 
>> You can see more examples on Gi= tHub 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(rando= m_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
>>
<= /div>
>> // String / string compares
>> va= r_dump("This is a tpyo" ~=3D "This is a typo"); // true
&g= t;> var_dump("something" ~=3D "different"); // false
&g= t;> var_dump("Wtf bro" ~=3D "Wtf sis"); // true
>>= ;
>> // String / different type compares
>> var_dump(-1.5 ~=3D "-1.a"); // true
>> v= ar_dump(-1.5 ~=3D "-1.aaaaaaa"); // false
>> var_dum= p(NULL ~=3D "blablabla"); // false
>> ```
<= div>>>
>> Note that this does not support all = possible Opcache optimizations 
>> _yet_, nor d= oes it support the JIT yet.
>> However, there are no= real blockers to add support for that.
>>
=
>> I look forward to hearing you!
>>
<= /div>
>> Have a nice first day of the month ;)
&= gt;> Kind regards
>> Niels
>
=
>Naturally, the degree of closeness for strings or for flo= ats should be controlled by an ini setting.  Maximum flexibility!
>
>--Larry Garfield

<= /div>
You got to be joking! Everybody knows ini settings make things= unportable. I suggest we introduce AI to determine the closeness instea= d.

cheers
Derick


We have to be careful not t= o tie ourselves to a specific AI model. But we can use ini settings to a= llow the user to specify which model to use.

=E2=80=94 Rob
--8f163078bd6b4c86a90b47c141187b7f--