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

[Gerhard Reitmayr]

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 
further.

>> 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. 

cheers,
  Gerhard

> 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
>>> https://lists.nongnu.org/mailman/listinfo/toon-members
>> 
>> --
>> Submit to ISMAR 2012 - http://ismar.vgtc.org/
>> 
>> Gerhard Reitmayr
>> Institute for Computer Graphics and Vision
>> http://www.icg.tugraz.at/Members/gerhard
>> tel: ++43 316 873 5082
>> 
>> 
>> 
>> 
> 
> 
> _______________________________________________
> Toon-members mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/toon-members

--
Submit to ISMAR 2012 - http://ismar.vgtc.org/

Gerhard Reitmayr
Institute for Computer Graphics and Vision
http://www.icg.tugraz.at/Members/gerhard
tel: ++43 316 873 5082