|Re: [eigen] unpleasant surprise mit math functions|
[ Thread Index |
| More lists.tuxfamily.org/eigen Archives
- To: eigen@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [eigen] unpleasant surprise mit math functions
- From: Hauke Heibel <hauke.heibel@xxxxxxxxx>
- Date: Thu, 27 Sep 2012 11:28:57 +0200
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=mEjRABrnXRdz4nx9gwY92bZPCrBAyJXqy+8Q+AEY8zc=; b=oiZ053KKJjnFPcXoOEMe6KxnxTRUFwdI5qntMbWZCKulJdmsm4+BYxeqHlE46wlP71 2z0AUb6M3wGh4nWEKrBSycOdqUANY2wRDuju2I6Uh1xutuIgYMtRLaQ02Yd/Ve7Wi4Ks 0uGU8dgmh3qANI10OePWTwtGVcPTe1s3ctOE3pHeEh5id797ROwocReW3uKZ43gQZboJ zQuHj8+5+4rtkAi7fkg2mi4IhfklWs/FY9cc4aZbmV1E691yyvb27d6NXp532MrYfGcu 6bx+crbxbIJOP44zAXRQk2Xrm5aAPFnT3DKbEfRB6zHGWvRUKqyKC8bpCjHkRzdpqiXF mc4w==
On Wed, Sep 26, 2012 at 10:58 PM, Gael Guennebaud
>> 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
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
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.
p.s. Regarding the exp application on matrices, at least Matlab
circumvents this issue by offering free functions expm and logm.