On Friday, 1 April 2022 at 02:41:58 UTC, Walter Bright wrote:
> On 3/31/2022 3:35 PM, max haughton wrote:
>> It's still quite ugly compared to just implementing cent properly e.g. lack of VRP and implicit conversions make the library approach a bit meh.
>
> There are very few uses for a 128 bit type, so all the conveniences are not particularly necessary.

For the past 2.5 years, I've worked on applications that use 256-bit integers for most of the computation (because the inputs are 256-bit numbers typically used to represent fixed point decimals with 18 digits) for computation and it would have been nice to to have uint256/int256 built-in types, instead of having to use a library BigInt type.

On 01/04/2022 5:48 PM, Tejas wrote:
> So will this look something like
> ```d
> alias i128 = __traits(signed, 128);
> alias u512 = __traits(unsigned, 512);
> ```
> And so on?

The name could be whatever you want, but yeah.

On 3/31/2022 10:33 PM, Petar Kirov [ZombineDev] wrote:
> For the past 2.5 years, I've worked on applications that use 256-bit integers for most of the computation (because the inputs are 256-bit numbers typically used to represent fixed point decimals with 18 digits) for computation and it would have been nice to to have uint256/int256 built-in types, instead of having to use a library BigInt type.

A library 128 bit type would be pretty easy to do, now that the computation functions are worked out. 256 bits could leverage that.

But frankly, with all the jawboning around it could have already been implemented. Just take:

  https://github.com/dlang/phobos/blob/master/std/complex.d

and de-template it, and delete most of it, and you've got struct Int128 and struct Uint128. The hard part:

  https://github.com/dlang/druntime/blob/master/src/core/int128.d

is already done.

Whoever does it first gets the glory :-)

On Friday, 1 April 2022 at 05:33:06 UTC, Petar Kirov [ZombineDev] wrote:
> On Friday, 1 April 2022 at 02:41:58 UTC, Walter Bright wrote:
>> On 3/31/2022 3:35 PM, max haughton wrote:
>>> It's still quite ugly compared to just implementing cent properly e.g. lack of VRP and implicit conversions make the library approach a bit meh.
>>
>> There are very few uses for a 128 bit type, so all the conveniences are not particularly necessary.
>
> For the past 2.5 years, I've worked on applications that use 256-bit integers for most of the computation (because the inputs are 256-bit numbers typically used to represent fixed point decimals with 18 digits) for computation and it would have been nice to to have uint256/int256 built-in types, instead of having to use a library BigInt type.

I have done that.

While it is not possible to get good codegen with the current provided types, it is possible with a 128bit type. You can then do your operation using a 128 bits accumulator and compiler are smart enough to figure out what to do most of the time.

This is why a 128 bit type is absolutely key, it unlocks the ability to write larger integer types in a way that will allow the compiler to generate good code for it.

Indeed, this is one time when typedef's would be better suited to the task.

On Monday, 28 March 2022 at 18:37:27 UTC, Guillaume Piolat wrote:
> On Saturday, 26 March 2022 at 19:30:13 UTC, Walter Bright wrote:
>> https://dlang.org/phobos/core_int128.html
>
> I tried to find faults in its divide and modulo so that I could rant about wideint.d being rewritten, but actually core.int128 seems to be better and correct (possibly more correct with negative modulo even). :)
>

Thanks, I took a page from hacker's delight when re-implementing the divmod() function, and did quite a bit of back and forth comparing results to wolfram. :-)

On Monday, 28 March 2022 at 19:35:10 UTC, deadalnix wrote:
> On Monday, 28 March 2022 at 18:37:27 UTC, Guillaume Piolat wrote:
>> On Saturday, 26 March 2022 at 19:30:13 UTC, Walter Bright wrote:
>>> https://dlang.org/phobos/core_int128.html
>>
>> I tried to find faults in its divide and modulo so that I could rant about wideint.d being rewritten, but actually core.int128 seems to be better and correct (possibly more correct with negative modulo even). :)
>>
>> So now it's all about adding the operator overloads, and done with that particular complaint!
>
> With LDC 1.27.1 :
>
> ```d
> Cent foobar(Cent a, Cent b) {
>     return mul(a, b);
> }
> ```
>
> Codegen:

[--snip--]

Being free functions, LDC is free to recognize them as intrinsics and do the desirable thing here.