Re: Merging Octave and Octave-Forge?

[Levente Torok]

On Wednesday 27 August 2008, John W. Eaton wrote:
> On 27-Aug-2008, Jaroslav Hajek wrote:
> 
> | On Wed, Aug 27, 2008 at 1:54 PM, Bill Denney <address@hidden> wrote:
> | > Jaroslav Hajek wrote:
> | >> On Wed, Aug 27, 2008 at 9:53 AM, Thomas Weber
> | >> <address@hidden> wrote:
> | >>
> | >>> I disagree. It's quite obvious they had a need for treating NaNs as
> | >>> missing values instead of usual calculation rules.
> | >>>
> | >>> If you don't want that behaviour, don't install the package. The
> | >>> package's documentation is totally clear about the package's effects
> | >>
> | >> Why didn't they follow the "convention" of Matlab's stat toolbox, and 
> create
> | >> nancov, nancor etc? Given that there is nansum, nanstd, nanmean...
> | >> That way, both kinds of functions could be used at once.
> | 
> | > I believe that the nan* functions are newer than our nan package.  It's
> | > probably not a bad idea to convert the names, though.
> | >
> | 
> | Silly me - I could have guessed that :)
> 
> I'm not sure of the exact sequence of events, but there is a message
> in the Octave mailing list archives from 1999 that says
> 
>   A few years ago, when MATLAB was developing their stats toolbox, they
>   added the functions nansum, nanmean, nanmedian, nanvar, nanstd, nanmax,
>   nanmin, nancov and nancorr.  These functions were identical to sum, mean,
>   median, var, std, max, min, cov and corrcoef except that they ignored NaNs
>   in the computations (they do not ignore Inf and -Inf).
> 
>   Does octave have any of those functions? 
> 
> Also looking at the archives, I think Alois' tsa and nan packages were
> written later.
> 
> I think the argument for replacing the functions instead of defining a
> separate set of nan* functions is that if you only provide nan*
> versions of these functions, you don't get the behavior you want when
> some other functions that you call happen to use the original names
> (say function foo that you need calls 'mean' and you want the
> 'nanmean' behavior.  Do you really want to track down all of those
> instances and modify them?  I understand the problem, but I also think
> that a bigger risk is silently producing results that differ from
> Matlab for the same code.  My experience is that users typically don't
> like that.

In the lack of explicit importing possiblity (opposed to languages as 
python...) 
Basicaly I vote to have nancov ... as in matlab.
However in addition to this I would probably like to have a global variable (or 
global switch, or name it anything you like)
by which I can use the nan functionality without rewriting my code.

How do you like this idea?

Lev
-- 
Blogger of http://fapuma.blogspot.com