-------- In message <CAPDSy+4y9ZZ-f=MyV1b_-t5OygyYgdr3W4V4soiLVGOgzXKdMg@xxxxxxxxxxxxxx>, David Schinazi writes: >Sounds good. I was mainly curious because I defined a sh-integer in one of >my drafts for a value that can in theory go up to 2^62-1, and I wonder if >it's worth the added complexity to support values between 10^15 and 2^62... Let me chime in here, as the 10^15 thing is largely my "fault". Without resorting to "there are N kinds of people" jokes, there are essentially four classes of numbers: A) Normal numbers. B) Scaled numbers C) Identifying numbers D) Cryptographic numbers The 10^15 has historically been more than fine for class A, people generally hate when there are more than 10 digits in a number, this we know this because AT&T did a LOT of research on this, back when people did a lot more with numbers by hand than we do today. In class B people deal with huge numbers by downscaling: Millions, Trillions, GigaBytes and PetaBytes. Nobody really cares if the stimulus was 1.000.000.000.000 or 1.000.000.000.010 dollars, so sawing of the right hand side is a good way to make numbers manageable, at the cost of suffixing multiplier: $125M In class C we have numbers which are used to enumerate things, customer numbers, passport numbers and so on. By their nature these numbers are not subject to arithmetic, but mainly because of the punched cards and the numeric keypad, using digits for encoding them is traditional. I would recommend that these be encoded either as byte sequences, or if they are important for manual debugging as strings. Class D is strictly speaking not only cryptographic numbers, but again, these are not usually subject of arithmetic, but in difference from class C they have a fundamental numeric nature, and there may be some mathematical operators which apply to them, for instance ordering. For these, I would recommend using fixed size byte sequences with a defined endianess. But again: If they are important to human debugging, for instance being able to tell which is larger/smaller, it may make more sense to put them in a string with a suitable radix. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@xxxxxxxxxxx | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
