Re: [eigen] unpleasant surprise mit math functions

[Gael Guennebaud <gael.guennebaud@xxxxxxxxx>]

On Mon, Sep 24, 2012 at 11:19 AM, Christoph Hertzberg
<chtz@xxxxxxxxxxxxxxxxxxxxxxxx> wrote:
> On 23.09.2012 15:24, Gael Guennebaud wrote:
>>
>> thank you Christoph and Karli, that makes perfect sense. So I thought
>> the solution would simply to put the "internal" base classes into
>> their own namespace. That worked for some expressions, but not for
>
>
> 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, I'd rather go for your second point:

> And why are they required at all?

and remove them. Jitse already raised the same remark a couple of
months ago in some related bug report, and I'm also starting to think
they should be removed.

gael

> I remember once users were required to specify ei_sin, etc if they had
> custom scalar types and this changed to internal::sin (no pun intended) in
> Eigen 3. However, I think it would make much more sense to make them declare
> that in the namespace of their class (or in std:: or global, if they prefer)
> and this seems to be sufficient at the moment.
> Or is it to prevent users from calling sin on integer arrays? I would say
> this goes into the category "shot yourself in the foot" and does not
> necessarily need to be prohibited by Eigen. Btw: what should happen if I
> call sin for a rational number class?
>
> If you can't/don't want to remove the internal::sin function then you could
> provide a function Eigen::sin(const Eigen::EigenBase<Derived>&); which
> statically asserts that Derived is an Array-Expression. In general, hoping
> that a namespace is hidden does not seem a good way to prohibit function
> calls. After all, the user should always be allowed to declare using
> Eigen::internal; without producing illegal code.
>
>
>> all. Typically if a template class Expr<Func> defined in namespace A
>> is instantiated with a class defined in internal then, all the generic
>> functions of internal become readily available for the class Expr.
>>
>> [...]
>>
>>
>> Did anyone be aware of such a rule? It does not make sense to me, and
>> looks rather dangerous.
>
>
> Well, the biggest problem with ADL is that hardly anyone really knows
> completely what it does ...
> As said above, I would never rely on functions in other namespaces not being
> visible.
>
>
> Christoph
>
>
>
> --
> ----------------------------------------------
> Dipl.-Inf. Christoph Hertzberg
> Cartesium 0.049
> Universität Bremen
> Enrique-Schmidt-Straße 5
> 28359 Bremen
>
> Tel: +49 (421) 218-64252
> ----------------------------------------------
>
>