Ticket #17 (new defect)
Opened 13 years ago
fix up L1_Norm return type
Reported by: | utke | Owned by: | utke |
---|---|---|---|
Priority: | minor | Component: | Higher Order Tensor lib (C++) |
Version: | Keywords: | ||
Cc: |
Description
should be unsigned short. unsigned int is too large anyway and the
change made with changeset:37797074af9d reveals the actual problem to be a usage error of pow as in:
The bug you have submitted appears to be a usage error.
The C++ standard (Chapter 26) requires the following declarations for standard function pow:
double pow (double, double); #1
double pow (double, int); #2
float pow (float, float);
float pow (float, int);
long double pow (long double, long double);
long double pow (long double, int);
The rules for function overloading (Chapter 13) require that a unique best matching function be at least a good a match on every function argument, and a strictly better match on at least one argument, compared to all other candidates. If more than one function could be called but none meets those criteria, the function call is ambiguous.
The call pow(double, int) is an exact match to #2 on both arguments, and is not as good a match with any other function. The call resolves to #2.
The call pow(double, unsigned int) is an exact match to #1 and #2 on the first argument, but requires a standard conversion to either double or int for the second argument. (Neither option is a promotion, which would be a better match than a standard conversion.) The call is therefore ambiguous.
Some compilers do not comply with the C++ standard regarding the overloads of standard function pow. Some versions of g++, for example, supply only the one function pow(double, double). In that case, no overload resolution is involved, and you can call pow with any pair of numeric types without ambiguity.
To work with standard-conformting compilers you can cast the second argument of the call to double, removing the ambiguity:
pow(x, (double)ue);