On Thu, Feb 16, 2012 at 7:29 AM, Alois Schloegl <alois.schlo...@ist.ac.at> wrote: > On 02/15/2012 11:12 AM, Michael Goffioul wrote: >> >> On Wed, Feb 15, 2012 at 10:08 AM, Alois Schloegl >> <alois.schlo...@ist.ac.at> wrote: >>>>> >>>>> If you are to do this, and since the NaN package actually shadows many >>>>> of octave-core functions, I would suggest to have those functions in >>>>> the tsa package so that one can use it without changing the "normal" >>>>> behaviour of octave. >>>> >>>> >>>> >>> >>> For clarification, the "normal" behavior of Octave is that it produces >>> NaN's >>> even in cases, where is is perfectly fine to get a meaningful result. The >>> NaN-toolbox addresses this issue. >>> >>> All statistical of the NaN-toolbox give the same "result" than the >>> standard >>> octave functions (if not, its a bug) if the data is fully defined (i.e. >>> contains no NaN's), and it produces meaningful results even for data >>> containing NaN's. >>> >>> The same function names are used, because it makes it easier to migrate >>> existing code to data containing missing values, and the user does not >>> need >>> to worry whether FUNCTION (e.g. std.m) or NANFUNCTION (e.g. nanstd.m) is >>> the >>> proper way of processing her data. >> >> >> Just out of curiosity, would it possible to implement the NAN behavior >> using classes instead? This would avoid the problem of shadowing >> existing core functions? > > > > I'm not familiar with classes, but I guess its possible to use them. The > real question is what would you gain ? Which problem would it solve?
The gain would be flexibility. The problem with shadowing core octave functions is that it's everything or nothing. You can't have both at the same time. If you want to process data with the original octave behavior, you'll have to unload the NAN package. But you won't be able to have both at the same time. Using classes would provide the flexibility to use the correct behavior depending on the data type (which is determined by the user when creating the data). > Shadowing of core functions is only necessary because the core functions do > not deliver an elegant, simple and straight-forward functionality (i.e. > ability to handle data containing NAN's) of statistical functions. I assume these functions have been designed with Matlab-compatibility in mind. If their behavior is not compatible, then it's a bug and you should log if in the bug database. Otherwise, there's nothing to fix. IMO it makes perfectly sense *not* to skip NaN values as they may be the symptom of a malfunction in a program. > If you are tired of these nagging warnings, ask the developers of octave to > fix it. And I do not mean turning off the warning on shadowing functions, > but to implement the NaN-skipping behavior within the existing core > functions. I'm not a user of those packages. I was just preparing binary packages and found odd to have the same MEX files in 2 different packages. I'm just trying to think about the possible consequences of the current design and the impact on the users. Michael. ------------------------------------------------------------------------------ Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ _______________________________________________ Octave-dev mailing list Octave-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/octave-dev
