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