This relates somewhat to the other discussion topic (https://sourceforge.net/p/half/discussion/general/thread/36919c68c5/#a326).
I am running into many issues when trying to convert code that worked before with all the built-in float types to start using the half float type, having to add in explicit conversions all over.
In some cases, I have to add custom code when templating to check if type is half so that it will operate in a different way than with the other types, especially when using std::complex<half>. Adding this code isn't possible or easy when the issue occurs in library code, e.g., std, or computation libraries.</half>
Doing a few things would help a lot to make this process automatic, allowing half to be used in the same places as float, double, long double.
Some things that would help are: Adding implicit casting from float to half rather than explicit. Even though this is a narrowing conversion, it would be really helpful if the half type behaved the same as built-in float types. Adding template specializations of std library functions to match what is done for the built-in float types, e.g.: std::complex<half>
</half> std::exp, std::abs, etc. Functions from <cmath>
*** It looks like you define these in the 'half' namespace, but putting in std namespace would make more interoperable I think</cmath>
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The implicit conversion thing I addressed in the other thread and is kind
of a problem.
Specializations for std::complex shouldn't be necessary since the
standard implementation should work as well. If it doesn't, the root
problems for that might rather need to be adressed. However, since
specializing standard library templates usually isn't a big deal, I might
look into that.
As to the mathematical functions, this is somewhat of a problem since the
standard library functions aren't templates rather than overloads and you
are not allowed to just add random functions to the std namespace. There
can be templates of these as part of their standard-prescribed treatment of
mixed and integer type arguments, but that is more of an implementation
detail (and might not be realized by templates at all) and even then it's
not clear if just specializing these is legal at all. I try to stay as
standard conformant as possible with the library and I just can't add stuff
into std. The functions are in the half namespace because they are half
precision functions. That does make it problematic when template code just
calls std::-qualified functions, since then even ADL won't be able to
resolve it. But I can't see a way around that other than adjusting the
client template code to be more type-agnostic in that regard, e.g. by
employing using directives and ADL instead of direct qualification.
However, if you don't shy away from trickery like that in your own project,
you might be abe to realize something like this on your side by importing
the half functions into the std namespace with a using directive, if
possible. This might even work on the entire namespace to import all the
functions in bulk. Of course this is quite a dirty trick, but so is
everything that just throws random stuff into std.
I am running into many issues when trying to convert code that worked
before with all the built-in float types to start using the half float
type, having to add in explicit conversions all over.
In some cases, I have to add custom code when templating to check if type
is half so that it will operate in a different way than with the other
types, especially when using std::complex<half>. Adding this code isn't
possible or easy when the issue occurs in library code, e.g., std, or
computation libraries.</half>
Doing a few things would help a lot to make this process automatic,
allowing half to be used in the same places as float, double, long double.
Some things that would help are: Adding implicit casting from float to half rather than explicit. Even
though this is a narrowing conversion, it would be really helpful if the
half type behaved the same as built-in float types. Adding template specializations of std library functions to match what
is done for the built-in float types, e.g.: std::complex<half>
</half> std::exp, std::abs, etc. Functions from <cmath>
*** It looks like you define these in the 'half' namespace, but putting in
std namespace would make more interoperable I think</cmath>
This relates somewhat to the other discussion topic (https://sourceforge.net/p/half/discussion/general/thread/36919c68c5/#a326).
I am running into many issues when trying to convert code that worked before with all the built-in float types to start using the half float type, having to add in explicit conversions all over.
In some cases, I have to add custom code when templating to check if type is half so that it will operate in a different way than with the other types, especially when using std::complex<half>. Adding this code isn't possible or easy when the issue occurs in library code, e.g., std, or computation libraries.</half>
Doing a few things would help a lot to make this process automatic, allowing half to be used in the same places as float, double, long double.
Some things that would help are:
Adding implicit casting from float to half rather than explicit. Even though this is a narrowing conversion, it would be really helpful if the half type behaved the same as built-in float types.
Adding template specializations of std library functions to match what is done for the built-in float types, e.g.:
std::complex<half>
</half> std::exp, std::abs, etc. Functions from <cmath>
*** It looks like you define these in the 'half' namespace, but putting in std namespace would make more interoperable I think</cmath>
The implicit conversion thing I addressed in the other thread and is kind
of a problem.
Specializations for
std::complex
shouldn't be necessary since thestandard implementation should work as well. If it doesn't, the root
problems for that might rather need to be adressed. However, since
specializing standard library templates usually isn't a big deal, I might
look into that.
As to the mathematical functions, this is somewhat of a problem since the
standard library functions aren't templates rather than overloads and you
are not allowed to just add random functions to the
std
namespace. Therecan be templates of these as part of their standard-prescribed treatment of
mixed and integer type arguments, but that is more of an implementation
detail (and might not be realized by templates at all) and even then it's
not clear if just specializing these is legal at all. I try to stay as
standard conformant as possible with the library and I just can't add stuff
into
std
. The functions are in the half namespace because they are halfprecision functions. That does make it problematic when template code just
calls
std::
-qualified functions, since then even ADL won't be able toresolve it. But I can't see a way around that other than adjusting the
client template code to be more type-agnostic in that regard, e.g. by
employing
using
directives and ADL instead of direct qualification.However, if you don't shy away from trickery like that in your own project,
you might be abe to realize something like this on your side by importing
the half functions into the
std
namespace with ausing
directive, ifpossible. This might even work on the entire namespace to import all the
functions in bulk. Of course this is quite a dirty trick, but so is
everything that just throws random stuff into
std
.Am Mi., 4. März 2020 um 16:53 Uhr schrieb Matt mattgately@users.sourceforge.net: