Positive

[Andrei Alexandrescu]

Janderson wrote:
> Andrei Alexandrescu wrote:
>> Hello,
>>
>>
>> (Background: Walter has kindly allowed ".()" as an alternative to the 
>> ugly "!()" for template argument specifications.)
>>
>> Just a quick question - I am feeling an increasing desire to add a 
>> template called Positive to std.typecons. Then Positive.(real) would 
>> restrict its values to only positive real numbers etc.
>>
>> The implementation would accept conversion from its base type, e.g. 
>> Positive.(real) can be constructed from a real. The constructor 
>> enforces dynamically the condition. Also, Positive.(real) accepts 
>> implicit conversion to real (no checking necessary).
>>
>> There are many places in which Positive can be useful, most notably 
>> specifications of interfaces. For example:
>>
>> Positive.(real) sqrt(Positive.(real) x);
>>
>> These specifications are also efficient because checking for 
>> positivity is done outside sqrt; if you had a Positive.(real) to start 
>> with, there is no cascading checking necessary so there's one test 
>> less to do.
>>
>> However, there is also the risk that Positive has the same fate the 
>> many SafeInt implementation have had in C++: many defined them, nobody 
>> used them. What do you think? If you had Positive in std and felt like 
>> crunching some numbers, would you use it?
>>
>> In order to get things really started, there's already been an 
>> exchange with Walter on the matter. His reply was (I haven't asked for 
>> permission, but I'm pretty sure he'd agree making it public):
>>
>> ==============
>> Honestly, I wouldn't use it. I'd rather have an in contract for sqrt 
>> that asserts the argument is positive. Also, this opens the door to 
>> Negative, NegativeOrZero, ZeroOrInfinity, Odd, Even, Prime, 
>> SixOrFifteen, etc.
>> ==============
>>
>> My answer to that was:
>>
>> ==============
>> About contracts: Let me explain how I think that's inferior to 
>> Positive in two ways.
>>
>> 1. Enough functions are defined on positive numbers only, to justify 
>> factoring that contract out of the functions themselves.
>>
>> 2. The efficiency perk is that when using several such functions 
>> together, there's only one check; once in Positive-land, no more 
>> checks are necessary.
>>
>> About proliferation of types: I don't think that follows at all. Math 
>> found positive numbers special enough to dedicate them a special 
>> notation (|R with subscript "+"). There's also a special notation for 
>> nonzero real numbers (|R with superscript "*"). There is no special 
>> notation for any of the sets you mentioned. That is bound to mean 
>> something.
>> ==============
>>
>> I'm interesting in further arguments. This feature is a numbers issue 
>> (pun not intended), meaning it will be any good only if enough people 
>> find it useful enough to actually use it in their own code and 
>> libraries, therefore building momentum behind it.
>>
>>
>> Andrei
> 
> As others have mentioned.
> 
> Why a second class form of range restriction?  Why not a first class 
> implementation like ADA's with ranges and subranges as specific 
> typedefs?  I know it would be more work for the compiler writer to 
> implement (if it can't be done in templates) however I prefer more 
> generic solutions then having many once-off solutions that crudely fit 
> together.
> 
> Being able to simply pick a type that is within the range needed would 
> save having to write contracts and static contracts all over the place. 
>  It also a great form of documentation.  I would find that useful, 
> particularly when working with algorithms that traverse arrays in 
> specific sequences such as spacial data structures but need to maintain 
> certain constraints.

Making ufloat, udouble, ureal as instantiations of Bounded.(low, high) 
is a great idea!

Andrei