Re: Difference between NaN and NA?

[Jaroslav Hajek]

On Fri, Apr 9, 2010 at 7:52 PM, David Bateman <address@hidden> wrote:
> Søren Hauberg wrote:
>>
>> 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
>>
>
> Can we just have a @double directory that is added to the path when special
> treatment of NA values is desired? This would be similar to the situation
> with the NaN package and allow the functions that aren't overloaded fall
> back to the original versions.
>

Perhaps. I don't see much difference between this and the NaN package, however.

-- 
RNDr. Jaroslav Hajek, PhD
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz