Add NaN, inf, is_nan and is_infinite

[Bzero]

This pull request introduces the 'NaN' keyword such that such that NaN values may be used directly in numbat.

As far as I am aware, NaN can currently only be accessed by calling an FFI function that returns NaN (e.g. ln(-1) or sqrt(-1)) but there is no direct way to declare a NaN value. With this change it becomes possible to use NaN directly, e.g:

>>> let foo = NaN

  let foo: Scalar = NaN

To check if a value is NaN, a is_nan() function is added (see also #144).

I stumbled over this limitation when trying to implement a function with a limited domain that can handle input outside of the domain in a meaningful way in numbat. Using the NaN keyword it is possible to write:

fn triangular_number(n: Scalar) -> Scalar=
	if n>=0
	then n*(n+1)/2
	else NaN

[sharkdp]

Thank you. I thought about this in the past, but didn't get around to implementing it — thanks.

I'm not sure if we really need NaN as a special token in the language, though? Could we perhaps define it in the prelude? For now, we could use something like ln(-1) and later we could maybe replace that by something cleaner. Like a from_bits(0xFFC00000) call, where from_bits would act like a bitlevel cast from int=>float.

I stumbled over this limitation when trying to implement a function with a limited domain that can handle input outside of the domain in a meaningful way in numbat.

Note that you can use error("…") for those cases:

fn triangular_number(n: Scalar) -> Scalar=
	if n>=0
	then n*(n+1)/2
	else error("n needs to be non-negative")

[Bzero]

I'm not sure if we really need NaN as a special token in the language, though? Could we perhaps define it in the prelude?

I figured having 'NaN' as a reserved keyword would make it available even with the '--no-prelude' option (just as any other value) and it would protect it from being user-redefined which could lead to unexpected behavior. On the other hand also π and all other constants can be overwritten so I am happy to turn it into a constant defined in prelude.

For now, we could use something like ln(-1) and later we could maybe replace that by something cleaner. Like a from_bits(0xFFC00000) call, where from_bits would act like a bitlevel cast from int=>float.

Sounds good to me!

[Bzero]

Note that you can use error("…") for those cases:

fn triangular_number(n: Scalar) -> Scalar=
	if n>=0
	then n*(n+1)/2
	else error("n needs to be non-negative")

If I understood it correctly that currently only works for functions with Scalar return values, right?

[triallax]

Do we also want to add "constants" for positive and negative infinity as well?

[Bzero]

I think that could be handy. Positive infinity inf should be enough though as one can just use -inf for negative infinity.

On that occasion it would probably make sense to add f64::is_infinite() to the FFI.

[sharkdp]

I figured having 'NaN' as a reserved keyword would make it available even with the '--no-prelude' option (just as any other value) and it would protect it from being user-redefined which could lead to unexpected behavior.

I thought about this some more and I think I actually agree with you on this. Would you mind reverting that change again and making NaN/inf a proper builtin? (Sorry)

If I understood it correctly that currently only works for functions with Scalar return values, right?

Yes. I thought about adding something like

fn error_d<D>(x: D, msg: String) -> D = error(msg) * x

which could be used like 4.3 km + error_d(m, "message"). That would only be a workaround solution, though. And it only works if you have an actual value of type D around (which is maybe not the case in all generic function scenarios). The proper solution would be to extend the type system to allow for ! return types (functions that never return). That might actually not be too hard, since the typing rules are quite simple (everything combined with ! yields !)

[Bzero]

I thought about this some more and I think I actually agree with you on this. Would you mind reverting that change again and making NaN/inf a proper builtin? (Sorry)

Of course not! That's on me, I was changing it a bit too quickly before waiting for your reply.

[Bzero]

I had some trouble writing a proper test for NaN since NAN == NAN is false.

[triallax]

You could add a test for this somewhere in the interpreter tests, and check that NaN == NaN evaluates to false in Numbat.

[Bzero]

There is a test in the interpreter tests already which works fine but I thought it might be good to have a parser test too?

[triallax]

Oh I missed that, but we can have something like NaN != NaN as a test too I suppose.

[sharkdp]

I would think we're good with the inf test here. The code for NaN is the same.