Path: csiph.com!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail From: Tim Rentsch Newsgroups: comp.lang.c Subject: Re: C23 (C2x) changes Date: Sat, 02 Oct 2021 08:07:24 -0700 Organization: A noiseless patient Spider Lines: 48 Message-ID: <86lf3bsbwz.fsf@linuxsc.com> References: <87y27it1mo.fsf@bsb.me.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: reader02.eternal-september.org; posting-host="394007ef4ff0447a8819fcdafe9c3245"; logging-data="620"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18hNTfTnLcjEZF/3eMDbppOD/U60XP+1yQ=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:kC2ON2tQKmFeNx9nXRBWUJmBxwo= sha1:KWjbfC3RC64n7TkHdu+ghMu+GOA= Xref: csiph.com comp.lang.c:162938 Manfred writes: > [...] > - How common is the need to model math that is strictly about > natural numbers compared to the need for integer math? (this is > not a rhetorical question, I'm genuinely curious). Combinatorics and number theory routinely concern themselves with domains limited to the non-negative integers. The celebrated prime number theorem, for example, counts primes less than a given upper bound, but considers only non-negative numbers as primes. Is -3 a prime? In a sense yes, but it's easier just to avoid the question by admitting only non-negative integers as candidates. > It could also be argued that after all natural numbers can be > handled using signed integers, as long as in the transition from > theoretical analysis to practical analysis, the limitation of > (2^31-1) is not that different from the limitation of (2^32-1) Considering practical aspects of writing code, if the domain of interest is confined to non-negative values, using an unsigned type (for function parameters, etc) makes for an easier fit, as otherwise input values would have to be tested for being negative, and something done to handle the offending situation. If unsigned types are used the problem doesn't come up. Also, when working in code related to those theoretical domains, I can say from first hand experience that we _always_ want that last bit, no matter how wide the data type in question. An extra bit means a larger range of applicability, and that's always useful. > - more relevant, IMO: the main difference between signed and > unsigned types is that in the latter case all bits are digits, > i.e. they constitute a homogeneous set, which makes them > specifically useful for binary arithmetic (which justifies the > difference in semantics, in my view). Speaking for myself a more important difference is that signed types have various pesky undefined and implementation-defined behaviors, whereas unsigned types do not. In most cases it's easier to reason about code that uses unsigned types if the range of possible values is even remotely close to the limits of the type in question. I routinely use unsigned types for variables unless the variable in question must be able to hold a negative value.