Re: [eigen] Bugs in Mat::Random, reductions

["Gael Guennebaud" <gael.guennebaud@xxxxxxxxx>]

ah, now I'm puzzled again. indeed, in that case the user even don't
have to read the doc:

first attempt:

#include<Eigen/Eigen>
m.cwise().sin();

=> error including: you_must_include_array_module_first

second attempt:

#include<Eigen/Eigen>
#include<Eigen/Array>
m.cwise().sin();

error: Eigen/Array must be included before Eigen/Eigen header

third attempt:

=> the lesson is learned  !!


so why not.

Then there is a practical issue because it is not possible to keep
both approaches for a smooth transition. So I guess we should only
enforce a correct order with a warning and mark Eigen/Core as
deprecated. And then wait some times before doing the real change.

gael.

On Sat, Oct 25, 2008 at 7:44 PM, Benoît Jacob <jacob@xxxxxxxxxxxxxxx> wrote:
> I mostly agree with that, but I would like to put one more evolution of this
> solution on the table.
>
> Instead of requiring the user to do
> #define EIGEN_USING_ARRAY_MODULE
> #define EIGEN_USING_GEOMETRY_MODULE
> #include <Eigen/Eigen>
>
> we could do
>
> #include <Eigen/Array>
> #include <Eigen/Geometry>
> #include <Eigen/Eigen>
>
> In other words, the only difference from the current situation, from the
> user's point of view, is that he must always include Eigen/Eigen last.
>
> Eigen/Array would just do:
> 1) check that Eigen/Eigen is not already included (#error otherwise)
> 2) define EIGEN_USING_ARRAY_MODULE
>
> Let me explain why it might still be worth doing that. We brought this
> conversation from the topic of error messages when the user forgets to
> #include a module. But this is a broader issue. The real question is, is it
> potentially useful to let Eigen know globally which modules are #included?
> The issue of error message is just one example of where it is useful to know
> that. There might be more...?
>
> So, I have the feeling that it might be worth asking the user to
> #include<Eigen/Eigen> last.
>
> Opinions?
>
> Benoit
>
>
>
>> Since no one complained, I guess nobody is against that solution. On
>> the other hand nobody seems to be excited by it, and actually, neither
>> do I. I mean, currently we have an intuitive mechanism to include
>> modules, but some weird link error messages if someone forgot to
>> include the right module.  And the we would change for more intuitive
>> error messages but with an unintuitive inclusion mechanism. So
>> eventually that's probably not worth it. In both cases we have to
>> compensate some unintuitiveness  by big warning in the documentation.
>> So let's keep the current state, and improve the doc. isn't it ?
>>
>> gael.
>>
>> ---
>
>
>
> ---
>
>