Proposal: Floats with Ranges

[pauldog]

Here is my language idea proposal. It's called "Floats with Ranges".

Introduction
Often you want a variable to take values in a certain range. The float type is unable to express this and so the IDE or compiler can't help you check if your variables are able to go outside the desired range. As an example the function acos(x) only takes values between -1 and 1 so it would be nice for the compiler to verify that x can only take these values. The function sqrt(x) only takes values with x>=0. Probabilities all must be in a range 0>=x>=1. Temperature in degrees Celsius takes on all values x>-273.15. Speeds in m/s takes on all values 0<x<299792458. And so on.

Another example: exp(x), the only valid values of x are -88.722f<x<88.72f to avoid overflow or underflow.

Proposal
The proposal is that you specify an optional range of a float by specifying pairs of numbers the value can lie between:

float<3f, 5f> x;
float<7f, Inf> y;
//assign x and y at some point
var z = x+y;
var w = x*x;

The type of z will be determined before compilation: float<10f, Inf> which means that z>10f.

The type of w will be: float <9f,25f>

We can specify multiple pairs e.g float <-Inf, 3f, 10f, Inf> q; which means q<3 or q>10. (A projective geometry way of writing the same thing might be to put the larger number first in this case: float<10,3>)

It is simple for the compiler to convert a domain to a range for many math functions including the usual arithmetic operators * + / -, square roots, trig functions, exponentials. Mostly you would not calculate the ranges yourself, you would use the var keyword. Or:

float <?> z = a+b;
console.Log(z.GetType())

Or by hovering over the ? it would show the range.

WHY OH WHY?
Often we need floats to be in a certain range and the compiler can determine when the variable has possibility of going outside that range. This can potentially help guard against overflow and underflow issues and divide by zero errors. This may be important for safety critical systems.

This feature is an example of "Dependent Types" while not going the full way with dependent types but just taking a small part that is simple to implement. Also it's quite fun and interesting.

Any Issues?
This type can not solve all issues, for example if we had two floats with ranges:

float<-3.141,3.141> theta;
//assign theta
float<-1,1> x = sin(theta);
float<-1,1> y = cos(theta);.

var z=x*x+y*y;

Now usually the type for z would be float<0,2> but in actual fact we know that the real range is float<0.9999,1.00001> for example because there is a correlation between the values. (All variables are assumed to be uncorrelated for easier calculation) So sometimes the true range will be less than the derived range. I don't think there is any way round this nor do I think this takes away from the usefulness of the proposal. Although in this specific case, a good compiler could probably work this out quite easily! (Really the above example is a fault of the programmer for not knowing the sin^2+cos^2 formula and simplifying it.)

Another issue I haven't got a good language design for how one would do inclusive and exclusive ranges e.g. 2<x<5 vs 2<=x<=5. And we would need a good language design for ±Infinity at the ends of open ranges. In mathematics these range would be expressed as (2,5) and [2,5] but these brackets are used elsewhere in c#. Notation ideas welcome!

Casting
One would be allowed to cast like this, to inclusive ranges.

float<2,3> x;
float<0,10>y = (float<0,10>)x;

or automatic casting with:
float<0,10>y = x;
To cast to a smaller range one would have to use the unsafe keyword.

float<0,10>y;
unsafe{
   float<2,3> x = (float<2,3>) y;
}
float <0.3333,0.5> z=1/x;

For example if y=0 this would break.

Helper functions
We could have a generic function:
float<3,5> z = Math.Clamp< float<3,5> >(7);
which clamps the number so it lies in the range, in this case clamps 7 to the maximum value of 5.
For example a standard math library implementing the float<-1,1>sin(x) function could clamp it's return value in order to guarantee the result was in the correct type.

Future enhancements
In this proposal the numbers in the range can only be compile time constants. What about a variable that represents a coordinate in the screen float<0,Screen.width>. When the screen width changes the type may change. How to deal with this case? This is not possible in this proposal. One could use coordinates in which the width of the screen is 1 then one could use the type float<0,1> which might still be of some use.

Other Uses
These ranges might be used in pattern matching, and switch statements too.

Workflow
The way this would work is that you'd specify the ranges of your inputs and your outputs. If the compiler cannot make an automatic cast it would display a warning or and error. You would then either add code to check the values manually or add a Clamp function. (or do an unsafe cast - not advised). You could therefor guarantee that your code will never break by the variables going outside the ranges.

Conclusion
I haven't worked out all the details. Feel free to add your own suggestions.

[HaloFour]

See: #413

[CyrusNajmabadi]

Often we need floats to be in a certain range

Such as?

[pauldog]

I'm sorry but you are bad at high school maths or are trolling at this point.

(-2)^2 is completely legal and sensible. Pow supports this just fine. There's no error at all using negative numbers here.

--

Also, for context, I majored/mastered in both CS and Math in college :D

so trolling then.

[pauldog]

@pauldog, you wrote:

Sorry, I can't help you if you can't do math. Perhaps learn some before commenting on a proposal about math. How did you get a job without knowing high school math? You should probably delete your posts before your boss finds out.

Was this really necessary? Being nasty to other contributors doesn't do anything positive to push this idea towards any kind of conclusion (and, it's against the code of conduct too).

Probably not necessary. But I feel like they were trolling because they pretending like they never heard of an overflow error. Like that is a problem from the dawn of computers.

[CyrusNajmabadi]

so trolling then.

No. As i'm pointing out, Pow is totally fine to have negative first values. So i don't see how it would be helpful to add a Range concept here in the manner you stated because that's not how one would annotate Pow. in other words, if you annotate Pow as not allowing negatives, you literally prevent it from being used from completely legit cases. That seems not-helpful.

[CyrusNajmabadi]

But I feel like they were trolling because they pretending like they never heard of an overflow error.

I said nothing about that. I said that i didn't understand your example because your annotation of this method doesn't make sense to me. And I pointed out exactly why:

I don't know what you mean by 'overflow' here. a < 0 is completely fine for Pow. After all, it's completely reasonable to raise a negative number to a power...

[tannergooding]

It's worth noting that many of the examples given are not "invalid inputs". That is, they do not cause the callee to throw, fail fast, etc.

They simply result in NaN which is in general a related, but very different concept. It's more similar to Try APIs where you want to differentiate between something that returns false vs something that returns true (and where for nullable annotations, Try APIs state they accept nullable inputs if they don't throw).

[pauldog]

It's worth noting that many of the examples given are not "invalid inputs". That is, they do not cause the callee to throw, fail fast, etc.

They simply result in NaN which is in general a related, but very different concept. It's more similar to Try APIs where you want to differentiate between something that returns false vs something that returns true (and where for nullable annotations, Try APIs state they accept nullable inputs if they don't throw).

Well of course. Because they have to give a value of NaN since they have to give a value at runtime as there is no compile time checking that the value will be in the correct range. Like I said if you want to put a value outside the range, there could be language ways of specifying this with "unsafe" etc. But at least its explicit you are doing this.

One could use the helper function with standard math library functions. e.g.

float<-1,1> x = Clamp<-1,1>( sin(y) ); float z = arcsin(x);

This ensures the value of x is in the required range -1...1 without having to rewrite the standard math function sin(y). (A cast from a small range to a larger range is always valid and doesn't need a cast). And there would be "ranged math functions" e.g. rsin and rarcsin which require the correct ranges. For example can we guarantee that the current implementation of sin(x) will never give a value of 1.00000000001 and therefor break your code at some future date? Or we may use exp(x) but what range of values of x are valid?

To reiterate "what's the point of all this?", the answer is that for compile time guarantees on floats. With compile time warnings to suggest places where you should either clamp a float to within a range or check the float is within a range. This helps you write valid code. It also helps you write faster running code. Since compile time checking of ranges will be faster than runtime checking of ranges.

With float equations it is impossible to check every combination of values, so your program could run fine for years but suddenly fail with an overflow or Nan error.

The suggestion is only an optional feature which might be used rarely but used wisely for safety critical compile-time verified code.

Is this a good idea? I don't know! Its just a suggestion. 😀

How useful would it be? Who knows, I may try and write an implementation in a toy language to see how well it works.

[tannergooding]

Because they have to give a value of NaN since they have to give a value at runtime as there is no compile time checking that the value will be in the correct range. Like I said if you want to put a value outside the range, there could be language ways of specifying this with "unsafe" etc. But at least its explicit you are doing this.

That's not why. Someone could expose a method which checks for out of bound values and throws instead (that's how most APIs work after all). The reason they behave like this is performance and also because the IEEE 754 spec defines that's how they behave.

The libraries differentiates between "disallowed" vs not. In particular you can see this with NRTs where null being disallowed means that providing null will throw. APIs which accept null and don't report success (TryParse may return false) are annotated as allowing null.

NaN is then in the same boat, since the method does not throw it is allowed and the concept of it being outside the input domain for "success" is a different concept.

This ensures the value of x is in the required range -1...1 without having to rewrite the standard math function sin(y). (A cast from a small range to a larger range is always valid and doesn't need a cast).

This would fail for NaN as Clamp would return NaN

[pauldog]

I feel like you are deliberately misunderstanding what I'm saying.

I'm not saying asin(-10) will crash your program. I'm saying asin(-10) gives a result of NaN which obviously is not what you want. The NaN will then propagate through your code causing untold damage. Yes it's allowed. But with speficied ranges you can specify what you as the programmer WISH to be allowed. In fact asin(-10) actual value is a complex number so NaN is wrong whichever way you look at it.

It therefore tells you you've made a mistake somewhere.

I am not talking about run-time throwing. I'm talking about compile time verification. Completely different things.

Anyway. It's just an idea which you won't use anyway since its seems like everyone's made up there mind on the matter anyway.

[tannergooding]

I feel like you are deliberately misunderstanding what I'm saying.

I understand what you're saying. I'm clarifying that there are differing concepts here and what you're stating isn't how many other people reading this will interpret it. We have some pretty well-defined terms around what disallowed means after all.

I'm saying asin(-10) gives a result of NaN which obviously is not what you want.

Whether or not NaN is what you want depends on how the API is being used. There are many cases where it is what you want because it allows you to detect errors or switch the domain in which you're operating (e.g. should you be using a Complex number instead).

There are many domains, including for graphics, games, scientific computation, and even simulations where utilizing complex numbers is desirable and therefore where NaN is immensely beneficial for representing key state.

Anyway. It's just an idea which you won't use anyway.So why bother arguing about it?

I'm one of the owners of the numerics APIs for .NET. It's my job to understand these types and interact with the community on such proposals.

I'm elaborating another point of view and why what you're asking for here isn't necessarily as clear cut as you're making it out to be.

Just because these inputs are potential problematic for the domain you're working in, doesn't mean they are strictly problematic to all domains or undesirable in all domains.

It is a case where writing an analyzer to help flag your specific use case might be a good option. That could then be provided for other users with similar requirements.

[pauldog]

OK, well it was just an idea I had last night. No big deal.