Status check: Int128 & UInt128

Yes, but if there is a bug in DoubleWidth then by copy-pasting the code you also get an crash in your app. My question is: should I file an issue or not? This may take some time, because I am a little bit busy.

Btw. As for the BigInt branch Swift Numerics, I would advise against using it, but it is just me, and I may be wrong.

Oki.
I created #272, but I don't have time to properly support (and even test it) right now, so please consider it a placeholder.

When I get a bit more free time I will make it more usable.

EDIT: I added 1 more test case to the issue. But the last time I touched DoubleWidth was a few months ago, so my memory about what is going on there is a little bit fuzzy.

3 Likes

If anybody is interested, I have checked that the above works in Numberick and proposed an alternative approach that does not need big integer models for testing (re: Foundation).


Edit: I've now fixed the issue below. Thanks for bringing it to my attention :+1:

1 Like

@oscbyspro
Try this one: github.com/oscbyspro/Numberick/issues/101. Though, I may have misused your API, because I do not have time to read the docs or check your code.

Btw. I am not doing this to troll anyone. But the whole thing shows that DoubleWidth is a non-trivial thing to implement. I would love to give '+1' for having this kind of thing in stdlib/Foundation/SwiftNumerics.

To be more precise, for my needs I would love to have UInt128 from LLVM. Though DoubleWidth is also 'ok'.

2 Likes

We really don't want DoubleWidth to be the thing people use. It's a convenient stopgap, but very much not a representation or implementation that we would want people to settle on.

1 Like