On Saturday, 26 March 2022 at 06:53:32 UTC, Era Scarecrow wrote:

I figured BitInt would be slower because it works with strings, working with pure binary would be faster, if there was a cent and ucent type I would be able to do the math faster.

On Saturday, 26 March 2022 at 18:12:08 UTC, H. S. Teoh wrote:

It's been a while since we have been doing BCD (Binary Coded decimals) which are base-10, which 8bit computers and calculators use to put 2 digits in 1 byte. No, it's far faster to use the built-in larger binary types, rather than lowering to 1 number at a time.

My library was on par with BigInt in speed, unless you utilized all instruction sets during compiling; Then BigInt is actually a bit faster making use of a few extra feature sets i haven't coded to take advantage of yet. Trying to compile the data to test and write is annoying.

Doing math purely based on string/text certainly can be done and may be easy to do, but will be slow and best for examples of infinite precision and not used for real-time applications.

On Sunday, 27 March 2022 at 03:10:41 UTC, Era Scarecrow wrote:

I hope you will be successful because we need to use it without writing import. Really, is it that hard? By simply implementing, the codes that we write can run slow! It can be accelerated by 2030. Even if the background BigInt library can work collaboratively.

In summary let's use that cent and ucent henceforth, please without import lines!

SDB@79

On Sunday, 27 March 2022 at 07:23:59 UTC, Salih Dincer wrote:

One could just use BigInt under the hood and then have it do checks at certain points and modify it to fit in the appropriate 128bit limits. Though i don't see that being useful, plus you would want to run it without any allocation for embedded and low memory devices.

Not needing an import would be nice, but it is more syntactical sugar, much like how you don't need to import the basic Object type, just being done under the hood doesn't mean that much. Somewhere it would just be that cent outside of the core would be alias cent=Cent; otherwise cent/ucent would be reserved words.

Though as long as you're at it, if you want to specify 256/512/1024 types now would be the time to decide the names and put them in all at once.

I glanced at the work Walter did. Looks like a simple version of wideint. I thought it would just be the function prototypes. Instead it looks like he minimally implemented it, but it is basically just in the wrong spot, or not set to being called at all (not too familiar with the internals i'm not sure). If these are ready to be used, I'd just swap out the division/multiplication work for faster variants and call it good.

Though there's a number of features there that i hadn't implemented, primarily the bit rotation types that aren't represented in C/D, and thus didn't see the need to at the time.

On Sunday, 27 March 2022 at 16:41:33 UTC, Era Scarecrow wrote:

To be called, the remaining work is that a library type must be implemented with operator overloads. Those operators overloads will call the core int128 module routines. Also operators overloads being templates, we can expect to have a size-efficient cg ("pay as you go").

druntime is the right place. For example LDC can patch the default implementation and use the LLVM-specific i128 instructions. The library type will end up using the right thing.

At this point it looks like it still would be possible to hook cent/ucent operations to the int128 core module even if it's not the way that's been chosen as cent/ucent are now deprecated.