[Pre-RFC?] NonNaN type

[skysch]

So I’ve been thinking about this a lot, because it’s something that I want in theory, to the point where I’ve already implemented over a half dozen float wrapper types in my own code. However, I’m skeptical that it will be ergonomic, and I’d like to outline what I think the basis of that is.

If we take a look at String, we can see it as a wrapper around Vec<u8> that maintains a UTF-8 invariant, but in practice that is not all that it is, and I’d argue that it is not enough to only do that. The difference is that String provides a complete suite of total (as in non-partial) methods for manipulating UTF-8 data. I’m imagining what I would be doing if it didn’t: I’d likely use Vec as an ‘ASCII’ type and convert to String only when I wanted/needed to verify it as UTF-8.

EDIT: Actually, the property I’m referring to above should be closure, not totality/partiality.

Anyway, the problem I’ve always had with my own float wrappers is that float operations are almost all partial, so you’ve got to exclude them (consider /=, for instance), or ‘escape’ your wrapper type, which hurts ergonomics by making you re-wrap. And in practice, I’ve gotten so frustrated with this that I only use them for Ord now. (There’s a similar level of frustration around as.) The trouble here being that this encourages you to only use these wrapper types at API boundaries, where an assertion would do just as well.

Maybe something could be done by introducing a whole zoo of wrapper types (Finite, NonZero, NonNan, NonNegative), but I feel like these will all have the same essential problem, and it’s not clear to me that we are doing anything but re-implementing float semantics at that point.

We could define the float division operator with non-nan, finite, non-zero operand types, like for example fn div(a: FiniteNumber, b: FiniteNonZeroNumber) , which would guarantee never-failing division at compile time.

The ergonomic loss here is not in calling the div function, but in how you get your FiniteNumber and FiniteNonZeroNumber values. Calling the constructors for those types is no better than asserting that your denominator is nonzero. It’s potentially even worse. Sure, your div never panics, but your FiniteNumber constructor does… so we’re just pushing panics around unless you can statically determine all of your input values. And if you can do that, then just do CTFE and give a compiler error when a panic would occur.

[johannesvollmer]

Calling the constructors for those types is no better than asserting that your denominator is nonzero

I see what you mean, but I’d argue it’s not as bad as one might think, because I would assume that a large portion of code would use NonZeros and Finites to begin with (thus not requiring a construction).

so we’re just pushing panics around unless you can statically determine all of your input values. And if you can do that, then just do CTFE and give a compiler error when a panic would occur

Yes, that would be great, it’s basically the core idea of Rust: having as many things as proven at compile time as possible. That’s why we have lifetimes and immutability and the whole type system.

The trouble here being that this encourages you to only use these wrapper types at API boundaries, where an assertion would do just as well

The assertion would have to be repeated at every function at the api, while the type has a single constructor definition, which contains a single assertion. Defining a type thus probably is less code duplication.

[skysch]

The assertion would have to be repeated at every function at the api, while the type has a single constructor definition, which contains a single assertion. Defining a type thus probably is less code duplication.

I would expect float functions to inline most of the time, so any redundant assertions would probably be eliminated by an optimization pass?

I would assume that a large portion of code would use NonZero s and Finite s to begin with (thus not requiring a construction).

Not to be a stick in the mud, but I would like some example code for this. Are you thinking that the compiler would generate these types from literals? I don’t see how this is possible in the presence of user-supplied data, FFI, or std floats.

[skysch]

The problem I’ve had with fixed point is that trig ops are very slow. (And when doing things like computing color spaces, coordinates, or vectors – very common uses for float – you tend to want to do trig.) If you’ve got a fast fixed point trig implementation, it might look more appealing.

[johannesvollmer]

I don’t see how this is possible in the presence of user-supplied data, FFI, or std floats

Fair point, the FFI border is a problem. But we’re already doing all kinds of conversion with FFI from arrays / pointers to slices. That’s already something programmers are doing.

I must admit that I might be too optimistic concerning how much the Finite and NonZero types would be used.

[johannesvollmer]

I would expect float functions to inline most of the time, so any redundant assertions would probably be eliminated by an optimization pass?

I was concerned about actual code that programmers have to write, not actual byte code performance. The programmer would have to write an assertion every time, instead of simply constraining values by using a type.

[skysch]

Compare the following:

Currently:

takes_val(52.0); // Calls the following.

fn takes_val(x: f32) {
    assert!(!x.is_nan());
    do_a_float_thing(x);
}

And with NonNan wrapper type:

takes_val(52.0.into());

fn takes_val(x: NonNan<f32>) {
    do_a_float_thing(x.unwrap());
}

We shave a line off, but certainly not for free.

[DataAnalysisCosby]

These code snippets look perfectly equivalent. So yes, that is “free”.

[skysch]

They’re not equivalent. The second example calls an extra function, for example. The are more types used. The lines are longer, even if there are fewer of them, etc… It’s a (syntactic) tradeoff, not a free lunch. And all we’ve actually accomplished is changing where the panic will happen.

[johannesvollmer]

In this specific example, the compiler could perfectly infer that 52.0 is not NaN, the same way that the compiler can infer it is an f32 and not f64. Thus it would be takes_val(52.0) in both cases.

[skysch]

Change 52.0 to a variable then. Parse it from a file, or get it from an existing codebase. I used a literal because it was easy. As I already mentioned, we can do CTFE to reason about literals. That is not what most people are doing with floats.

[skysch]

Anyway, the ‘broader’ pattern I’m trying to get at is that types don’t maintain invariants, they only allow us to specify where the invariants must be upheld. Functions maintain the invariants, and only if the type doesn’t change. Float operations will change the types of these things, which means that we either won’t get our float operations, or we will not be able to maintain these invariants.

[johannesvollmer]

That sounds really sad do you think there is no way we can challenge that problem?

[skysch]

The typical way to solve this kind of problem would be to generalize to include the broadest set of invariants you can maintain for the operations you want to support… and if you want all the float operations, that’s exactly what the floating point types are. (And that’s effectively why NaN is part of float in the first place.)

You can definitely specialize further if you know what operations you want to stop supporting. Or rather, if you identify a set of operations or tasks that the new types are meant to be optimized for. I don’t think “people who don’t want NaNs” is a reasonable starting point, because that’s far too broad, and it certainly doesn’t tell you if you want to support div, pow or tan or not.

[DataAnalysisCosby]

Firstly, this transformation is free in that all of the functions calls are easily inlinable. It is zero cost.

Secondly, you can argue all day about which is better “syntactically” but that is not something you can argue about objectively so I don’t understand how you can claim either style is better, and that therefore it is a trade off.

Thirdly, all you’ve done is shifted where a panic happens because your code doesn’t actually do anything with the NonNaN type. It’s purpose is to uphold invariants in the context of containers. Using it to just check if a value is a NaN and panicking would obviously be no better than just an if statement and a float. Converting a float to a NonNaN so it can be stored in a Set, for example, is extremely useful.

Fourthly, you wouldn’t call unwap on a NonNaN. They’d implement Into floats.

[DataAnalysisCosby]

Types maintain invariants by having a single point of creation that upholds that invariant. If NonNaNs are created only via a From func that checks if the float is NaN then it is perfectly acceptable to say that the type upholds the invariant it is claiming to. And again, we don’t need NonNaN to implement math operations besides Ord. That can be done after extracting a float. NonNaN is for storage and comparisons, not arithmetic.

[skysch]

Secondly, you can argue all day about which is better “syntactically” but that is not something you can argue about objectively so I don’t understand how you can claim either style is better, and that therefore it is a trade off.

I didn’t argue that one style is better than the other. I’ve been saying all along that the second style doesn’t buy us anything. It’s just a change in syntax.

Types maintain invariants by having a single point of creation that upholds that invariant.

Not… exactly? You’re saying the same things with different words. Every mutating operatation must also maintain the invariant. Anything which consumes the type and emits another one also will cease to maintain the invariant. Types maintain invariants by constraining which functions they can be passed to, ensuring that only variant-maintaining functions will be invoked.

And again, we don’t need NonNaN to implement math operations besides Ord. That can be done after extracting a float. NonNaN is for storage and comparisons, not arithmetic.

Yes! That’s been my point all along: there’s no need to define float operations on this type, since all it meaningfully can do is provide an Ord impl. (And the way that invariant is maintained is by not allowing mutation of the inner value at all. So naturally, any non-mutating impl could also be provided for it.) If you want to do any float operations, you have to unwrap it first, which means if you’re not storing it in a data structure, you will be equally well served by a simple assertion.

I apologize if I’ve given the impression that I am against the idea of a NonNaN type for the purpose of Ord. I just don’t see any value for it outside of that.

[DataAnalysisCosby]

Aaaaah, my error - I’ve changed my opinion on implementing arithmetic for NonNaN at some point during this discussion, and it has been hard to keep up with the different opinions here (and I think I may have confused a few avatars together).

Then I absolutely agree with you. NonNaN can maintain its invariant by not having mutating operations. And yes, NonNaN is only useful in particular contexts, especially implementing Ord. Otherwise you should extract a float.

[skysch]

Thanks. I may have also gotten confused about some things… I didn’t mean to take over the discussion so much, but I’ve spent a lot of time over the last year experimenting with various float wrappers and fixed point types – precisely because I wanted to understand why they don’t exist or create them if they can. Largely the lesson I’ve learned is the float is actually really fantastic at solving the problems it is meant to solve.

Back on topic, there might be an interesting question of whether to implement Ord for Option<NonNaN> or just NonNaN, because it might allow you to choose whether to panic early or late. If you build a data structure which holds NonNans internally you can ensure early panics, but if it holds Option<NonNan>, you can defer the unwrap till the sort (or other op) and panic then. I don’t think there’s a good reason to be generic over these two modes, but if so, that’s a thing to think about.

[system]

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.