Re: [boost] Infinite precision integer draft
I don't think that it is that important to have unsigned_integer, but this argument against it doesn't stand up: 1) Unsigned integer is not just an arbitrary restriction on range but an important concept in its own right. Its use clarifies intent. In my opinion, for example, it is a common, though minor, programming error to use "int" rather than "unsigned int" when you intend to express cardinality of something (e.g., the size of an array). The only real justification otherwise is to allow such practical "tricks" as testing if a decreasing index is less than 0. 2) The extra data type, assuming that the design error of deriving unsigned_integer from integer is avoided, would add complexity for boost maintainers but virtually none for users. It is, after all a logical extension of the built in types -- it takes the user all of 5 seconds to understand it, if that. Good library design is user-centric. Developer-centric design is the root of a great deal of evil. Lack of development/maintenance resources is, of course, a valid argument, but this is a completely different issue than that of the evils of unnecessary complexity. 3) Normal use of an unsigned integer type will never "try" to produce a negative result -- its not a meaningful concept, so if you play by the rules it doesn't happen. You certainly would never try to negate a cardinality (how often do you write code that says "If this string contains 27 characters then I want another one containing -27 characters?). Subtraction does have to be done with care, but in most cases the issue of subtracting a larger from a smaller doesn't come up. Subtraction generally appears, sometimes subtly so, as a computation of the size of the complement of a subset within a larger set. If you are dealing with where you would want to use unsigned integers and you unwittingly do subtract a larger from a smaller value -- if your program logic does not protect you from it -- than you better have an exception. 4) If the exceptions are exceptional than in most systems it is very much more expensive to do an explicit test than to set up to handle an exception. Topher Cooper At 04:09 PM 6/2/2006, you wrote:
Unsigned integers shouldn't exist. If the programmer wants to check whether the number is greater than 0, or greater than 42, he can do it himself a lot faster than a try{} catch{} block in terms of both programming and runtime. Creating the extra datatype would add completely unnecessary complexity to the situation. Unnecessary complexity is the root of all evil. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Fri, Jun 02, 2006 at 06:40:00PM -0400, Topher Cooper wrote:
1) Unsigned integer is not just an arbitrary restriction on range but an important concept in its own right. Its use clarifies intent. In my opinion, for example, it is a common, though minor, programming error to use "int" rather than "unsigned int" when you intend to express cardinality of something (e.g., the size of an array). The only real justification otherwise is to allow such practical "tricks" as testing if a decreasing index is less than 0.
I disagree. Such 'intent' can, and should, be put in the name of the variable. when it's a size, you can use the builtin type anyway. We are talking about arbitrary precision unsigned integers; I see no use for that. The only reason for it's existance is when you actually (want to) rely on the fact that it will throw when it becomes negative. I think the users should be protected from bad usage like that.
3) Normal use of an unsigned integer type will never "try" to produce a negative result -- its not a meaningful concept, so if you play by the rules it doesn't happen. You certainly would never try to negate a cardinality (how often do you write code that says "If this string contains 27 characters then I want another one containing -27 characters?). Subtraction does have to be done with care, but in most cases the issue of subtracting a larger from a smaller doesn't come up. Subtraction generally appears, sometimes subtly so, as a computation of the size of the complement of a subset within a larger set. If you are dealing with where you would want to use unsigned integers and you unwittingly do subtract a larger from a smaller value -- if your program logic does not protect you from it -- than you better have an exception.
I disagree once more -- if you unwittingly subtract a larger from a smaller value then the program is bugged. There is no reason to add a special type of this kind of bug, and not for other range checks (ie, what if I don't want it to become larger than 1000000? Or when the variable should be negative all the time and may not become positive? etc)
4) If the exceptions are exceptional than in most systems it is very much more expensive to do an explicit test than to set up to handle an exception.
In order to throw the exception when the value DOES become less than zero, you will have to build the test into the library. So, your "much more expensive to do an explicit test" will be forced upon the users, even those who can code correctly so that their variables indeed will never become negative anyway. The tests will be 100%, useless, overhead, in the final program. I'm not against extra tests all over the place, but that is debugging code which should not be compiled into the production version. An assertion is therefore what you want: that code is not compiled, once the code is stable. -- Carlo Wood <carlo@alinoe.com>
Topher Cooper <topher@topherc.net> writes:
1) Unsigned integer is not just an arbitrary restriction on range but an important concept in its own right. Its use clarifies intent. In my opinion, for example, it is a common, though minor, programming error to use "int" rather than "unsigned int" when you intend to express cardinality of something (e.g., the size of an array). The only real justification otherwise is to allow such practical "tricks" as testing if a decreasing index is less than 0.
I happen to use unsinged ints when I mean nonnegative numbers, but several people have argued that they're error-prone than signed ints, with good reason... Oh yeah, we just saw an example of it in the bjam source (http://news.gmane.org/find-root.php?message_id=%3c3212b1a80605210414u63627d0...) Also, some constraints just aren't worth expressing in the type system. for (unsigned x = 0; x < 20; ++x) has no particular value over for (int x = 0; x < 20; ++x) It's hard to argue that it's less obvious that x is nonnegative in the 2nd case. Of course, using size_t instead of int does have some worthwhile semantic value, but I consider the fact that size_t is unsigned to be an artifact.
2) The extra data type, assuming that the design error of deriving unsigned_integer from integer is avoided, would add complexity for boost maintainers but virtually none for users.
More to understand. Adds the need to make a decision about which type to use.
It is, after all a logical extension of the built in types -- it takes the user all of 5 seconds to understand it, if that.
No. The type, as proposed, has very different behavior than the builtins at the boundaries. Or should I say "boundary?" An infinite precision unsigned has only a single boundary, zero, and isn't modular. And you can't make it behave like the builtins -- what value would it wrap around to? So it's very different from the builtin type, and presents a trap for the unwary.
Good library design is user-centric.
Yes.
Developer-centric design is the root of a great deal of evil. Lack of development/maintenance resources is, of course, a valid argument, but this is a completely different issue than that of the evils of unnecessary complexity.
No. Complexity for developers always, ultimately, has a cost to the users they serve. Complexity should only be shouldered if there are benefits that dwarf those costs. In this case, there are not.
3) Normal use of an unsigned integer type will never "try" to produce a negative result -- its not a meaningful concept, so if you play by the rules it doesn't happen. You certainly would never try to negate a cardinality (how often do you write code that says "If this string contains 27 characters then I want another one containing -27 characters?). Subtraction does have to be done with care, but in most cases the issue of subtracting a larger from a smaller doesn't come up. Subtraction generally appears, sometimes subtly so, as a computation of the size of the complement of a subset within a larger set. If you are dealing with where you would want to use unsigned integers and you unwittingly do subtract a larger from a smaller value -- if your program logic does not protect you from it -- than you better have an exception.
Not if it's just an intermediate value. As shown in the bjam example above, you might just be introducing an error condition/exception where none was needed. -- Dave Abrahams Boost Consulting www.boost-consulting.com
Topher Cooper <topher@topherc.net> writes:
If you are dealing with where you would want to use unsigned integers and you unwittingly do subtract a larger from a smaller value -- if your program logic does not protect you from it -- than you better have an exception.
No, you better have an assertion. -- Dave Abrahams Boost Consulting www.boost-consulting.com
participants (3)
-
Carlo Wood -
David Abrahams -
Topher Cooper