Re: [eigen] first time usage by me! and very satisfied!

[ Thread Index | Date Index | More Archives ]

On Fri, Sep 12, 2008 at 6:29 PM, Schleimer, Ben <bensch128@xxxxxxxxx> wrote:
> Hi Gael,
>   I just like jumping in and adding my two cents:

I'm always happy to get feedback :)

>> indeed I though it would not harm to add shortcuts for most
>> common
>> statistic reduction methods. they would be added in the
>> Array module,
>> and also be available in a column and row wise flavors.
> You might want to consider adding another module (Statistics) instead of adding it to core Array. There's lots of these kinds of algos which can be added but not necessarily useful for non-statistians.

well, if someone want to implement a full Statistics module he is
welcome :)  but currently, I don't see the need for that.

> I don't know if would be better to extend Array via composition or inheritance in this case. It would be possible to accelerate the algos by using caching in the derived class. Maybe make caching a trait...

I don't follow you. Actually there is no such Array class. The Array
module mainly contains the definitions of a couple of methods declared
in MatrixBase. Then for the caching mechanism, I don't see where to
store it. We definitely don't want to extend the Matrix class with
that, so we would have too add some StatMatrix class extending
Matrix.... moreover, you need to track any write access to the data to
invalidate the cache...  perhaps I completely missed your point ?

ah ! after answering the rest of the comments I now see how it could
be done. maybe you were thinking  to something like that:

VectorType v;
// play with v..
// now you want some statistics on v:

Statistics<VectorType> s(v);


// MatrixBase would define:
// Statistics<Derived> stats() const { return derived(); }
// so that you can also do:


// that is ok if you don't need to take advantage of the cache

yeah, this could work well for matrix-wise operations. On the other
hand for column and row wise stuffs this might be complicated....

>> /* use the precomputed mean to compute the stddev */
>> Scalar stddev(const Scalar& mean) const;
>> /* shortcut */
>> Scalar stddev() const { return stddev(mean()); }
> use caching instead of the first method
>> maybe we can even have a single version with a default arg
>> value:
>> Scalar stddev(const Scalar& _mean = mean()) const;
>> but I don't know if it's legal to call a non static
>> member function on *this...
> This is definitely not legal. Default arguments have to be set at compile time.

actually the pb is that you don't have access to "*this"... but you
can use the result of any function as default argument value, for

float foo(float v = random()) {...}

is ok.

>> I prefer that to something like:
>> Scalar stddev(Scalar*  returnedMean = 0) const;
>> because in case you have already computed the mean value
>> you cannot
>> tell stddev to use it...
> This is confusing. what does the function return if returnedMean == 0?
> It might be better to cache the mean and not return it in the stddev() method. The user has access to it in mean(), no?

 I think I was not clear here. I meant: "I prefer the above approach
rather than the following common solution".
and to be clear, its implementation would be:
Scalar stddev(Scalar*  returnedMean = 0) const
   Scalar m = mean();
   if (returnedMean) *returnedMean = m;
   // compute and returns stddev

but again I don't like this approach !!

>> so to summarize we would add:
>> * mean()
>> * standardDeviation([precomputed_mean])
>> yeah, eventually "standardDeviation" is not too
>> long
>> * variance([precomputed_mean])
>> * median()
>> maybe here we could have an optional argument to tell if
>> the vector is
>> already sorted ??
> We could have a cached sorted flag...

same pb as above


>> * sort()
>> median needs a sort algo, and here I really mean
>> "sort", not "sorted",
>> so it an in-place sort
> Cheers
> Ben
>> cheers,
>> gael.
>> On Thu, Sep 11, 2008 at 8:29 PM, Andre Krause
>> <post@xxxxxxxxxxxxxxxx> wrote:
>> > dear list, just wanted to let you all know i am using
>> eigen2 alpha 07 for the
>> > first time - and i am very satisfied. works like
>> charm, with no problems on
>> > win32 and visualc++ 2008.
>> >
>> > though i am missing some basic convenience functions
>> like mean, medium, stdev
>> > etc. . i already heard on #eigen, that they are
>> planned for some future release.
>> >
>> > kind regards,
>> >        andre
>> >
>> >
>> >

Mail converted by MHonArc 2.6.19+