Re: Difference between NaN and NA?

[Søren Hauberg]

tor, 08 04 2010 kl. 13:31 +0200, skrev Jaroslav Hajek:
> But why make it built-in? I think that even with the current limited
> OOP capabilities, it is possible to build a class that maintains the
> NA's as a separate mask, making even the elementary operations
> NA-aware (i.e. so that x + NA is NA and never NaN). Overloading the
> statistics functions like mean etc. would also be quite simple.

The problem with the current OOP programming is that you can't really
inherit from base classes. If we created a 'NA_Friendly_Matrix' (NAFM?)
class, but didn't (as an example) provide an implementation of the 'sin'
function, the user would experience an error when calling 'sin'. The
user would be forced to manually convert to an ordinary matrix whenever
calling a function that does not have a NAFM implementation (the OOP
stuff doesn't seem to provide a mechanism for automatically converting
to a built-in type). This would IMHO just be a pain to use.

So, if we were to have such a class, I fear it would have to be
implemented in C++ and be part of Octave core. But perhaps I'm just
missing the obvious here...

Søren