Re: Proposal: Arbitrary precision native scalar type

From: Date: Thu, 07 Dec 2023 14:27:37 +0000
Subject: Re: Proposal: Arbitrary precision native scalar type
References: 1  Groups: php.internals 
Request: Send a blank email to internals+get-121944@lists.php.net to get a copy of this message
On Wed, Dec 6, 2023 at 10:36 PM Alex Pravdin <alex.pravdin@interi.co> wrote: > Hello internals, > > > This is the second round of the discussion regarding arbitrary precision > scalar type integration into PHP. The previous part: > > https://marc.info/?l=php-internals&m=168250492216838&w=2 was > initiated by > me before deep diving into the work with decimals in PHP. After 6 months > of > working, I would like to update my proposal taking into account my > experience and the previous discussion. > All builtin functions that currently accept float also accept decimal. So > users don't need to care about separate function sets, and PHP developers > don't need to maintain separate sets of functions. If such functions get > the decimal parameter, they return decimal. If they have more than one > float parameter and mixed float and decimal passed, decimals converted to > float by default. If "default_decimal" or "as_decimal" used, float is > converted to decimal with the warning. > > You are going to run into some very difficult corners on this one. For the last... 8 years i guess? I have been working on an arbitrary precision library for PHP in userland. It utilizes BCMath, ext-decimal, and GMP, depending on what is installed and what kind of operation you are performing. So, the functions that currently accept floats include functions such as sin() or atan(). These functions are not at all trivial to do to arbitrary precision. In fact, the VAST majority of the work I have done on my library has been to handle cases like "What do I do if the user wants 2.921 ** 4.293810472934854?" or "How will I guarantee the precision that the user requested for tan() in an efficient way?" Now, libmpdec is going to actually have implementations for most of this stuff that you can call directly, but if the PHP function sin() isn't capable of *outputting* a decimal, then this isn't really that much of an improvement over the current situation. I mean, it's still something I would support, but that's the area where some help from the engine goes a VERY long way. You're probably also going to need a way for a user to grab certain constants to a given precision. I would think e and pi at the least. I have a lot of experience working on this problem space in PHP, and am definitely willing to help. I looked into doing a libmpdec PHP integration several years ago, but decided that voters were unlikely to give it a fair shot, and so decided against it. If you're willing to try and roll the ball up the hill though, I'll definitely help you. Jordan

« previous php.internals (#121944) next »