On Tue, 9 Apr 2024 at 09:57, Rowan Tommins [IMSoP]
wrote:
>
>
> On 8 April 2024 21:51:46 BST, Jordan LeDoux
> wrote:
> >I have mentioned before that my understanding of the deeper aspects of how
> >zvals work is very lacking compared to some others, so this is very
> >helpful.
>
> My own
On 8 April 2024 21:51:46 BST, Jordan LeDoux wrote:
>I have mentioned before that my understanding of the deeper aspects of how
>zvals work is very lacking compared to some others, so this is very
>helpful.
My own knowledge definitely has gaps and errors, and comes mostly from
introductions
Hi Jordan,
> To me, while being 100x to 1000x more performant at arithmetic is certainly
> reason enough on its own, the fact that MPFR (for example) has C
> implementations for more complex operations that can be utilized is the real
> selling point. The ext-stats extension hasn't been
On Mon, Apr 8, 2024 at 12:23 PM Rowan Tommins [IMSoP]
wrote:
>
> As I mentioned in the discussion about a "scalar arbitrary precision
> type", the idea of a scalar in this meaning is a non-trivial challenge, as
> the zval can only store a value that is treated in this way of 64 bits or
>
On 07/04/2024 23:50, Jordan LeDoux wrote:
By a "scalar" value I mean a value that has the same semantics for
reading, writing, copying, passing-by-value, passing-by-reference, and
passing-by-pointer (how objects behave) as the integer, float, or
boolean types.
Right, in that case, it might
On Mon, Apr 8, 2024, 16:40 Rowan Tommins [IMSoP]
wrote:
> On Mon, 8 Apr 2024, at 13:42, Arvids Godjuks wrote:
>
> The ini setting I was considering would function similarly to what it does
> for floats right now - I assume it changes the exponent, thereby increasing
> their precision but
On Mon, 8 Apr 2024, at 13:42, Arvids Godjuks wrote:
> The ini setting I was considering would function similarly to what it does
> for floats right now - I assume it changes the exponent, thereby increasing
> their precision but reducing the integer range they can cover.
If you're thinking of
On Mon, 8 Apr 2024 at 14:33, Barney Laurance wrote:
> On 2024-04-08 12:17, Arvids Godjuks wrote:
>
> > Why not have decimal be represented as 2 64-bit ints at the engine
> > level
>
> Just to clarify this point, what's the formula to convert back and
> forth between a decimal and two integers?
On 2024-04-08 12:17, Arvids Godjuks wrote:
Why not have decimal be represented as 2 64-bit ints at the engine
level
Just to clarify this point, what's the formula to convert back and
forth between a decimal and two integers? Are you thinking like
scientific notation: decimal = coefficient *
Hello everyone, I've been following the discussion threads and forming my
own opinion to share since I have done a bunch of financial stuff
throughout my career: I did the integers only at the application level and
DECIMAL(20,8) in the database due to handling Bitcoin, Litecoin, etc.
My feeling
Hi Rowan,
> Well, that's the original question: are they actually different purposes,
> from the point of view of a user?
The purpose of both is different from a detailed perspective. Addition of
native types and addition of OOP API. But if think about the purpose from a
broader perspective,
On Sun, Apr 7, 2024 at 2:45 PM Rowan Tommins [IMSoP]
wrote:
> On 07/04/2024 20:55, Jordan LeDoux wrote:
>
> > I have been doing small bits of work, research, and investigation into
> > an MPDec or MPFR implementation for years, and I'm likely to continue
> > doing my research on that regardless
On 07/04/2024 20:55, Jordan LeDoux wrote:
I have been doing small bits of work, research, and investigation into
an MPDec or MPFR implementation for years, and I'm likely to continue
doing my research on that regardless of whatever is discussed in this
thread.
I absolutely encourage you to
On Sun, Apr 7, 2024 at 8:27 AM Rowan Tommins [IMSoP]
wrote:
>
>
> On 7 April 2024 15:38:04 BST, Saki Takamachi wrote:
> >> In other words, looking at how the efforts overlap doesn't have to mean
> abandoning one of them, it can mean finding how one can benefit the other.
> >
> >I agree that the
On 7 April 2024 15:38:04 BST, Saki Takamachi wrote:
>> In other words, looking at how the efforts overlap doesn't have to mean
>> abandoning one of them, it can mean finding how one can benefit the other.
>
>I agree that the essence of the debate is as you say.
>However, an argument must
Hi Rowan,
> While I appreciate that that was the original aim, a lot of the discussion at
> the moment isn't really about BCMath at all, it's about how to define a
> fixed-precision number type. For instance, how to specify precision and
> rounding for operations like division. I haven't seen
On 7 April 2024 11:44:22 BST, Saki Takamachi wrote:
>I don't think the two threads can be combined because they have different
>goals. If one side of the argument was, "How about to add BCMath?" then
>perhaps we should merge the discussion. But BCMath already exists and the
>agenda is to
Hi Rowan,
>> On 7 April 2024 01:32:29 BST, Jordan LeDoux wrote:
>>
>> Internals is just volunteers. The people working on BCMath are doing that
>> because they want to, the people working on scalar decimal stuff are doing
>> that because they want to, and there's no project planning to tell one
On 07/04/2024 11:07, Rowan Tommins [IMSoP] wrote:
On 7 April 2024 01:32:29 BST, Jordan LeDoux wrote:
Internals is just volunteers. The people working on BCMath are doing that
because they want to, the people working on scalar decimal stuff are doing
that because they want to, and there's no
On 7 April 2024 01:32:29 BST, Jordan LeDoux wrote:
>Internals is just volunteers. The people working on BCMath are doing that
>because they want to, the people working on scalar decimal stuff are doing
>that because they want to, and there's no project planning to tell one
>group to stop.
On Sat, Apr 6, 2024 at 4:07 AM Barney Laurance
wrote:
> Hello,
>
> There are currently two proposals being discussed - *native decimal
> scalar type support* and *Support object type in BCMath*
>
> I've been getting involved in the discussion for the BCMath proposal, but
> not paying as much
Hi Barney,
> There are currently two proposals being discussed - native decimal scalar
> type support and Support object type in BCMath
>
> I've been getting involved in the discussion for the BCMath proposal, but not
> paying as much attention to the native decimal thread.
>
> But these seem
22 matches
Mail list logo
