Control: tags -1 + patch
[Lucas Nussbaum]
>> /"PKGBUILDDIR"/source/DWGUGens/dwglib/DWG.hpp: In member function 'void
>> TUBE::set_area(float, float)':
>> /"PKGBUILDDIR"/source/DWGUGens/dwglib/DWG.hpp:1271:53: error: no matching
>> function for call to 'min(float, double)'
>> loss = 1.0 - std::min(lossF/sqrt(a1),1.0);
>> ^
I had a look by compiling with -E and checked out the preprosessed sour code.
The problem is that a C++ version of sqrt() from <cmath> is used, which return
float and not double as a1 is float. This causes the expression lossF/sqrt(a1)
to be float. The end result is that the compiler try to locate min(float,
double)
as 1.0 is double not float. I'm not quite sure why the compiler do not promote
the float to a double, but a simple fix for this issue is to ask the compiler
to assume 1.0 is a float like this:
diff --git a/source/DWGUGens/dwglib/DWG.hpp b/source/DWGUGens/dwglib/DWG.hpp
index 85ed86c..b6df5b7 100644
--- a/source/DWGUGens/dwglib/DWG.hpp
+++ b/source/DWGUGens/dwglib/DWG.hpp
@@ -1268,7 +1268,7 @@ class TUBE{
if(a1 < 1e-18)
loss = 0.0;
else
- loss = 1.0 - std::min(lossF/sqrt(a1),1.0);
+ loss = 1.0 - std::min(lossF/sqrt(a1),1.0f);
}
void go(){
I'm not sure if the code used to operate on doubles or floats earlier, nor what
the author intended. If it is important that the calculation is done using
doubles, I guess this approach is better:
diff --git a/source/DWGUGens/dwglib/DWG.hpp b/source/DWGUGens/dwglib/DWG.hpp
index 85ed86c..282b2da 100644
--- a/source/DWGUGens/dwglib/DWG.hpp
+++ b/source/DWGUGens/dwglib/DWG.hpp
@@ -1268,7 +1268,7 @@ class TUBE{
if(a1 < 1e-18)
loss = 0.0;
else
- loss = 1.0 - std::min(lossF/sqrt(a1),1.0);
+ loss = 1.0 - std::min(lossF/sqrt(static_cast<double>(a1)),1.0);
}
void go(){
It make sure sqrt(a1) is operating on a double, and the compiler take care of
the
converting the rest of the variables to double. I suspect the 1.0f approach
is better, as the loss variable is a float, so any increased accuracy is lost
when the result is assigned anyway. But I do not really know what the code
try to do, as I did not try to understand the context of the calculations.
--
Happy hacking
Petter Reinholdtsen
