On 02/14/2012 04:57 PM, Carnë Draug wrote: > On 14 February 2012 15:49, Carnë Draug<carandraug+...@gmail.com> wrote: >> On 13 February 2012 21:31, Michael Goffioul<michael.goffi...@gmail.com> >> wrote: >>> On Mon, Feb 13, 2012 at 1:17 PM, Alois Schloegl >>> <alois.schlo...@ist.ac.at> wrote: >>>> There is not a strict dependency between these, most parts of these >>>> toolboxes can be used independently. There is only a very small overlap, >>>> namely >>>> inst/sumskipnan.m >>>> inst/covm.m >>>> src/sumskipnan_mex.mex >>>> src/covm_mex.mex >>> >>> This is probably the same for any other dependency: when a package >>> depends on another, it doesn't mean it's using the full set of >>> functions provided by that package, just a few of them. >>> >>>> One could make another small package (e.g. SkipNaN) out of this subset, and >>>> define the dependency against this newly introduced package. However, I'm >>>> hesitant to do this because users would need to download two instead of one >>>> package, and the SkipNaN-functions are only useful in combination with TSA- >>>> or NaN-tb. >>>> >>>> >>>> What's happening if both packages are loaded? >>>> >>>> These functions are exactly the same in both packages, so it does not >>>> matter >>>> which is installed first. >>> >>> Besides the fact that it can be confusing for the user, that's only >>> true as long as the 2 versions are kept in sync. This also means that >>> whenever you make a change to one of those 2 MEX files, you'll have to >>> release both packages at the same time and make sure to tell those >>> users who happen to have both packages installed that they need to >>> upgrade both of them (otherwise you don't know which version the user >>> will end up using). >> >> I agree with Michael. As an example, the image package has the signal >> package as dependency because of one single function. >>
I see your point, let me think about how to re-structure these two projects. As far as I see it, nothing is broken at the moment. Usually, I do simultaneous releases, and the overlapping functions are pretty mature. I would like to lower the number of different releases. Would it be an option to put TSA+NaN into a single package and having an option to pkg for installing only one or the other part ? >> 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. > > I'm a bit confused now. The NaN package already is a dependency of tsa > so why the doubled functions? > > Carnë It has not been my intention to define such a dependency. Where is this dependency defined? Alois ------------------------------------------------------------------------------ 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
