View mode: basic / threaded / horizontal-split · Log in · Help
October 05, 2008
Positive
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
October 05, 2008
Re: Positive
"Andrei Alexandrescu" wrote
> (Background: Walter has kindly allowed ".()" as an alternative to the ugly 
> "!()" for template argument specifications.)

:(

Another case of multiple syntax possibilities.  What was wrong with !() ? 
I didn't consider it ugly at all.  In fact, I prefer it.

It's very alarming to me that something like this just has no problem 
getting in the language without community feedback.

> 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.

I wouldn't use it, if that helps at all.  Even if it was in Tango (i.e. not 
just because I don't use Phobos).

-Steve
October 05, 2008
Re: Positive
Steven Schveighoffer wrote:
> "Andrei Alexandrescu" wrote
>> (Background: Walter has kindly allowed ".()" as an alternative to the ugly 
>> "!()" for template argument specifications.)
> 
> :(
> 
> Another case of multiple syntax possibilities.  What was wrong with !() ? 
> I didn't consider it ugly at all.  In fact, I prefer it.
> 
> It's very alarming to me that something like this just has no problem 
> getting in the language without community feedback.
> 
>> 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.
> 
> I wouldn't use it, if that helps at all.  Even if it was in Tango (i.e. not 
> just because I don't use Phobos).

Seconded.
October 05, 2008
Re: Positive
Andrei Alexandrescu wrote:
> 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 not a math major. But in college I took 4 years of math, up through 
integration in the complex plane and branch cuts (which I never did 
properly understand <g>). Every engineering/physics class was a math 
class. I never saw this notation. I am not suggesting it doesn't exist, 
just that it became commonplace fairly recently, or that it isn't 
commonplace at least at the undergraduate level. This plays into the 
numbers issue you mentioned.
October 05, 2008
Re: Positive
On Sat, Oct 4, 2008 at 10:55 PM, Steven Schveighoffer
<schveiguy@yahoo.com> wrote:
> "Andrei Alexandrescu" wrote
>> (Background: Walter has kindly allowed ".()" as an alternative to the ugly
>> "!()" for template argument specifications.)
>
> :(
>
> Another case of multiple syntax possibilities.  What was wrong with !() ?
> I didn't consider it ugly at all.  In fact, I prefer it.
>
> It's very alarming to me that something like this just has no problem
> getting in the language without community feedback.

Heartily agree.  Not that it means anything.
October 05, 2008
Re: Positive
Steven Schveighoffer wrote:
> It's very alarming to me that something like this just has no problem 
> getting in the language without community feedback.

It's there at the moment so we can look at it and see if we like it. I 
know Andrei likes it. Anyhow, this is the opportunity for community 
feedback.
October 05, 2008
Re: Positive
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.

Sounds like range-restricted values, which people have been asking for 
as a language feature for ages.  The idea has merit.

> 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?

See below.

> 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.

So you're saying the problem with contracts here is code duplication? 
I'm not sure I follow.

> 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.

To be fair, there's one check for each time such a value is constructed 
or altered.  So you're simply assuming that the checked value will be 
constructed and then never altered.  But how is this different from 
using contracts?

I like the idea of checked values for safety, but I think efficiency 
concerns would prevent me from using them for actual work.  For example, 
let's say that I'm performing a bunch of computations.  I only really 
want to check whether the result is in range--I don't care about the 
intermediate values.  So I'd be inclined to forgo the use of checked 
values for the actual work and simply return a checked type at the end. 
 But this is exactly how contracts work!  Why would I bother with 
checked values if I can do the same checking in in/out clauses?

> 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.

It's clearly as important to describe the attributes of a variable in 
math as it is in programming.  So mathematicians settled on the notation 
you mention, and programmers have largely settled on the use of 
contracts.  There may still be some value in more math-like notation in 
programming, but I don't personally see much of a need for it in this 
case.  Like Walter, I'd continue to use contracts unless some compelling 
reason can be provided for using this notation instead.


Sean
October 05, 2008
Re: Positive
Andrei Alexandrescu escribió:
> (Background: Walter has kindly allowed ".()" as an alternative to the 
> ugly "!()" for template argument specifications.)
> 
> For example:
> 
> Positive.(real) sqrt(Positive.(real) x);

I can't read that. I see a bunch of calls and casts. !() was a little 
hard at first, but this is impossible.

Of course, this is just my opinion, I don't know what the others think 
about it...

Another problem, from an IDE perspective: "Positive." will trigger 
autocomplete of Positive's members, ugh.
October 05, 2008
Re: Positive
Walter Bright wrote:
> Steven Schveighoffer wrote:
>> It's very alarming to me that something like this just has no problem 
>> getting in the language without community feedback.
> 
> It's there at the moment so we can look at it and see if we like it. I 
> know Andrei likes it. Anyhow, this is the opportunity for community 
> feedback.

To me, the !() syntax has always clearly communicated what's happening. 
 The exclamation mark signifies an assertion of sorts (using the 
English meaning of 'assertion', not the programming meaning).  With the 
dot syntax I'd always be wondering whether there was a function call 
taking place that I didn't know about.  Is there anything this change in 
syntax gives us over what we currently have?  If not, I don't want it.


Sean
October 05, 2008
Re: Positive
"Walter Bright" wrote
> Steven Schveighoffer wrote:
>> It's very alarming to me that something like this just has no problem 
>> getting in the language without community feedback.
>
> It's there at the moment so we can look at it and see if we like it. I 
> know Andrei likes it. Anyhow, this is the opportunity for community 
> feedback.

Well, here is my feedback.

First, I hate it when D has two ways of doing something.  For example, C 
style array declarations, or function pointers.  But those have good 
reasons.  We want the new style because it's unambiguous and context-free, 
but we want the old style to allow easy porting of C code.

But this change has no qualities I can see except that Andrei thinks it 
looks better (at least, that's the only reason he's given).  There are not 
compatibility issues with C or some other language, it's just a new syntax 
that looks different.  Are there problems with the original !()?  Please 
give a reason for this addition besides asthetics, and then we can discuss 
the merits.  Or if the community overwhelmingly loves this new syntax, I 
guess that's a good reason.  Otherwise, I think it should be rejected on the 
simple principle of not fixing things that aren't broken.

-Steve
« First   ‹ Prev
1 2 3 4 5
Top | Discussion index | About this forum | D home