Re: [eigen] unpleasant surprise mit math functions

[Hauke Heibel <hauke.heibel@xxxxxxxxx>]

Hi guys,

On Wed, Sep 26, 2012 at 10:58 PM, Gael Guennebaud
<gael.guennebaud@xxxxxxxxx> wrote:
>> How about putting the math-functions into their own namespace?
>
> yes I thought about that option, however I remember seeing some user
> code relying on them explicitly. I know that's bad and that they
> should not do so, but if we can find an easy solution that don't break
> existing code I'd feel better, and in case we would go to take the
> risk to break anything, ...

Maybe that was me. I do not remember the exact use case but I can
search for it but I do remember the basic problem I had. I wrote a
generic function which worked identically for arrays and floating
point scalars. If I were required to use ei_sin/cos and co. for Arrays
or even to specify the namespace for sin/cos, I would have to rewrite
the whole function simply because sin(Array) does not work. So there
exist (maybe rare) situations in which the current implementation
reduces unnecessary code duplication.

I also do not really see why this should be bad. It's not generally
bad to utilize Koenig lookup or ADL though I definitely agree its
usage. The problem with the template parameter is definitely a big
surprise.

I think there are two potentially better solutions to the problem than
removing the functions or even moving them to yet another namespace.
The first solution might be to use a more restricted interface for
sin/cos etc. which does not simply take a type T as a parameter but
something else, e.g. ArrayBase. I am not sure whether that is the best
match because I do not know the class hierarchy by heart. The second
potential solution is to utilize SFINAE and something like
std::enable_if (its easily written) in order to prevent the
compilation for sin/cos etc. for anything but Array based
expressions/objects.

In summary, I would be glad if it were possible to have the option to
call sin/cos and co on Arrays exactly as I can do it in Matlab.

Regards,
Hauke

p.s. Regarding the exp application on matrices, at least Matlab
circumvents this issue by offering free functions expm and logm.