Dealing with NANs

[Beakerboy]

Dealing with NANs

[markrogoyski]

There are pros and cons to both approaches.

Returning a NAN is nice in terms of types that NAN is kind of a float and you can have a return type declaration of float which works for real numbers and NANs. However, there is immense complexity in every function needing to check every other function, and you will have a lot of conditional logic anytime you call a function because you can't trust that you got an actual answer back. You also push this complexity onto any clients using our code, in that they also can't trust return values if NAN comes back.

Throwing exceptions is nice because you can go back to trusting return values. Parts of the code that explicitly expects and knows how to deal with NANs can try/catch and deal with it, and other parts of the code can ignore it and pretend that only the happy path exists, because it basically only does for them. The downside is client code will crash if the exception is not handled, but as long as it is documented, it basically becomes the client's responsibility to handle it.

I have not researched what other math libraries do and could spend some time looking at some OO math libraries like Apache Commons Math and the like. But my initial thoughts without thinking too much is that for now maybe a MathPHP\Exception\NanException is all that we need and make sure the few places it is expected is checked and we throw this new exception rather than letting a NAN return value infect other parts of the code that are not expecting or prepared to handle it.

[Beakerboy]

MathPHP\Exception\NanException Sounds like a great compromise.

[markrogoyski]

Version 2.5.0 implemented NanException as discussed.