Re: 64-bit unsigned integer?

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On 2018-03-01 21:32, Dan'l Miller wrote:
> Dan'l Miller wrote:
>>> Why would they be allocated as the humanly-imaginable worst-case for usage of the library?
> Dmitry Kazakov wrote:
>> Because the upper bound is exactly that, the humanly-imaginable worst case.
> 
> No, the upper bound of a bounded integer (or bounded string for that matter) is what I declared it to be in my own app-domain source code.

You are a human and it is your imagination which gave you the bound value.

> Dan'l Miller wrote:
>>> Bounded textual strings are not allocated as the maximum universally-conceivable textual string length of megabytes long.  Bounded simply means:  pick a modest upper bound and stick to it, say, 128-bit integer for bounded bignum or 32-character string for bounded textual string.
> Dmitry Kazakov wrote:
>> Why 128 and not 256 or 1056781?
> 
> Because I declared it to be a 128-bit bounded bignum at this place in my app-domain source code for some register in my main processor, and I declared some other 256-bit bounded bignums at some other place in my app-domain source code for some other register in my GPU.  And in this application, the calculations on the 128-bit bounded bignums never utilize the 256-bit bounded bignums, and the calculations on the 256-bit bounded bignums never utilize the 128-bit bounded bignums; they are disjoint usages.  Why does bounded mean for you “one size fits all for all human beings on the planet”?

Bounded numbers will be a generic package thus you will not be able to 
intermix differently bounded numbers even if they are semantically same. 
You will not be able to convert between such types. You will have no 
literals, no universal integer expressions, no way to pass it to a 
generic numeric package, no way to have it as discriminant (large 
discriminants are useful in some cases) etc.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de