When will you implement cent and ucent?

Era Scarecrow rtcvb32 at yahoo.com
Sun Mar 27 16:41:33 UTC 2022


On Sunday, 27 March 2022 at 07:23:59 UTC, Salih Dincer 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.

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.

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

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.


More information about the Digitalmars-d mailing list