[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Toon-members] Precision in SE3::exp()

From: Gerhard Reitmayr
Subject: Re: [Toon-members] Precision in SE3::exp()
Date: Fri, 30 Mar 2012 12:54:36 +0200

On 28 Mar 2012, at 23:15, Simon Taylor wrote:

> > ok, so the problem is with the patch or without ?
> For me, the patch "fixes" the difference in behaviour - that is, gives the 
> same output both with and without a "using namespace std;".

of course, because then the name is fully qualified.

>> it should probably be done similar to sqrt:
>> using std::cos, std::sin;
>> and later sin(Precision p)
>> This is useful, if Precision is something completely different, for example 
>> automatic differentiation class (like FADBAD++ that I am using). then the 
>> compiler will also look in the namespaces of the Precision type to find a 
>> matching sin overload. Otherwise, if there isn't one in std:: it will fail.
> That makes sense. I always forget about C++ doing that search for functions 
> in the namespace of the parameters, that's pretty neat.
>> but, I tried to test this with FADBAD++ and it didn't fail :/
> Hmm, can the types be implicitly converted to double or something?

not sure, but usually not. anyway, if I find some time, I will test this 

>> In anycase shouldn't there be a warning, then the double expression is 
>> assigned to the float value at the end ? this should provide some heads-up 
>> that there is something going on.
> That warning isn't enabled by default on GCC, it's not in -Wall or -Wextra, 
> and needs to be specifically requested with -Wconversion. I hadn't realised 
> that until today, but it's now part of my standard warning flags.
> The other interesting warning flag is -Wdouble-promotion, which warns when 
> some floats are promoted to double for an expression:
> float f=1.3f;
> if(f < 2.4) // f promoted to double here for the comparison
> Obviously the promotion above won't change behaviour, but it might be 
> undesirable on platforms without hardware floating point. I guess for 
> float/double that could be fixed to if(f < Precision(2.4)) - would that have 
> any problems generalising to FADBAD++ or other types? Also, it's pretty ugly, 
> so might not be something we want to sprinkle liberally throughout TooN.

usually its fine, because 2.4 would be promoted to a FADBAD++ type, or the 
FADBAD++ type has a comparison function for doubles or something. But I can see 
that this is tricky. I am using TooN on mobiles but I usually use it as float 
and it works ok. I don't see big speed problems, even if there are some 
occasional promotions :)

but I guess the Precision(2.4) is the only working solution to avoid these kind 
of promotions. 


> Simon
>> cheers,
>>   Gerhard
>>> I've been trying to find a list of C++ overloads that are added std to 
>>> search for all potential occurrences of these sorts of issues but I haven't 
>>> had much luck. There's a couple of gcc options that help tracking them down 
>>> in code that actually gets compiled (-Wdouble-promotion and -Wconversion) 
>>> but I don't think there's a warning for implicit parameter conversion (I 
>>> can't make "double v = ::sqrt(1.3f);" generate any warnings, but having v 
>>> as a float makes -Wconversion pick it up as possible data loss).
>>> Simon
>>> ps: since the git switch we seem to have lost commit email notifications...
>>> <explicit_std_namespace.patch>_______________________________________________
>>> Toon-members mailing list
>>> address@hidden
>> --
>> Submit to ISMAR 2012 -
>> Gerhard Reitmayr
>> Institute for Computer Graphics and Vision
>> tel: ++43 316 873 5082
> _______________________________________________
> Toon-members mailing list
> address@hidden

Submit to ISMAR 2012 -

Gerhard Reitmayr
Institute for Computer Graphics and Vision
tel: ++43 316 873 5082

reply via email to

[Prev in Thread] Current Thread [Next in Thread]