Activity for Christian Rau
-
Christian Rau posted a comment on discussion General Discussion
I'll look into it. Thanks for the info.
-
Release 2.2.1.
-
Release 2.2.1.
-
Fixed error in int-to-half conversion when converting minium negative value.
-
Yes, there is indeed a bug in the integer to half conversion when calling it with the type's minimum negative value, since on two's complement platforms (which is virtually everywhere) that doesn't have a positive equivalent inside the type's own domain. I will look into fixing it. Thank you for bringing this up.
-
Hello, Thank you for reporting this issue. However, I don't think your solution would be appropriate for the project (at least from my side, it could be a fine thing to do for ROCm). Rather than adding a specialization into the std namespace, what should actually happen is to call the actual half function from the half_float namespace in the first place wherever it's needed. ADL should actually take care of that, but if the standard library specializations mess that up, I guess one has to actually...
-
Updated documentation.
-
Added explicit qualifications to internal exception functions to avoid namespace conflicts.
-
Reduced type conversion warnings when internal computations use 64 integers.
-
It is true, that the only assignment operator for builtin types is the float version and will perform an implicit conversion to float, as described in the documentation (which also lists some ways to work around any problems with this). However, assignment between halfs works directly by copying the internal bit representation, like you described. There is no explicit assignment operator for half in the class definition because it is default generated by the compiler anyway (same with the copy constructor)....
-
Hello, I don't really want to hide all the necessary headers behind configuration macros, though. There already are quite a few macros and some things can just be assumed as given. I might consider making the streaming operators optional (as "iostream" can indeed be quite a monster) and I will also try to look into what "algorithm" is even used for. But things like "utility" and "cmath" are just necessary. I'm not going to implement my own swap function in in 2023. ;-)
-
Fixed language in documentation.
-
Hello, Sorry, yes, I had actually changed it locally already after your first message. I just haven't put up a new release since then, so the changes haven't found their way into the public. I wasn't really planning to make an entirely new release for that, but I'll see if I can update the website at least or find other things that warrant a new version. Regards, Christian Rau Am Do., 10. März 2022 um 12:04 Uhr schrieb Teresa teresachr@users.sourceforge.net: Hello @rauy, I hope you are well. Sorry...
-
Hello, Yes, I think I can change that. Regards, Christian Rau Am Mo., 13. Dez. 2021 um 16:25 Uhr schrieb Teresa teresachr@users.sourceforge.net: Hello @rauy, we are reviewing our documentation at arm. We have your half implementation as part of our third party libraries in Arm NN. We were wondering, if perhaps, the next time you publish a new version, you could consider changing the sentence: "the user knows what he is doing" for "the user knows what they are doing". I am attaching a README.txt with...
-
Hello, That wouldn't be the HALF_ERRHANDLING_FLAGS macro, rather than the HALF_ERRHANDLING_THROW_... macros, as explained in the documentation on http://half.sourceforge.net/. However, all the automatic error handling features already are disabled by default, so this won't help you. Your problem likely is the function fethrowexcept, which also works without automatic error handling and contains throw statements. Unfortunately it seems there really is no other way around it than for you to manually...
-
Hello, In this case it seems you need to manually undefine support for the <cfenv> header. This is normally enabled automatically based on the compiler/library version used. But if you say your environment is explicitly unsupporting the standard there, then you can manually deactivate support for these macros by defining the HALF_ENABLE_CPP11_CFENF macro to 0 (either via compiler/preprocessor options or in code before including half.hpp), as described in the documentation on half.sourceforge.net....
-
Release 2.2.0.
-
Release 2.2.0.
-
Removed exception handling branch.
-
Fixed missing include for F16C intrinsics.
-
Hello, Yes, this is a shortcoming of half not offering conversion constructors for every possible builtin type, but only for float. So when converting a double to a half, it always takes the route over the implicit conversion to float first. This is somewhat intentional, but can cause some unwanted warnings. The only way around that is either using the explicit 'half_cast' or explicitly converting the double to float beforehand. But I'm reconsidering the layout of conversion constructors and assignment...
-
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...
-
That seems to get messy quickly. I will consider broadening type conversions to more types in general in the future, to adress some of the above problems with double initializations maybe, but specifically allowing uint8_t conversion sounds like a bit of an inconsistent mess just to support 0 and 1. I know it's unfortunate when template code just uses these all over the place, it's why I usually use T(1) and T() in such completely type-agnostic code. That's ugly too, but such is the case if you want...
-
The problem is that code that implicitly casts from double to float is already problematic and narrowing conversions should be taken care of in templated code like that. So either you are already operating with mixed types even when using builtin types, in which case you might want to care for proper type-safety and narrowing conversions there, too. Or you only work within a single type, which should as well work when switching that type to half. I really don't intend to add implicit conversions...
-
The problem is I'd have to provide constructors like these for every type then and I'd like to avoid that. But I'm thinking about it, maybe I'll reconsider that. Am Sa., 18. Jan. 2020 um 15:40 Uhr schrieb "Emilio Mª López Riñón" redorav@users.sourceforge.net: Would a simple explicit constructor taking a double not work in this case? No viable conversion from 'double' to 'half' Sent from sourceforge.net because you indicated interest in < https://sourceforge.net/p/half/discussion/general/> To unsubscribe...
-
Hello, Yes, you're right. Explicit construction ('half a(3.4);') works and assignment ('half a; a = 3.4;') works too. But when using initialization with assignment operator ('half a = 3.4;') is should actually first use the 'float' constructor and then the copy constructor, but it seems it can't use the 'float' constructor as long as that is 'explicit'. This surprises me and I have to look if that has changed somehow since C++11 or if that has always been the case. Unfortunately, the 'float' constructor...
-
Hello, This should actually work and I don't quite understand why it doesn't. The half type has implicit constructors and assignment operators taking float arguments. These constructors are implicit and the compiler should thus allow the expression using an implicit conversion from 3.4 to 3.4f and then calling the float constructor. You could try with 3.4f directly and see if that works, but it should actually work with 3.4 already. There seems to be something else wrong, but without more code it's...
-
Improved performance of pow function.
-
Refined rsqrt function.
-
Improved accuracy of rsqrt function.
-
Improved and tested rsqrt function.
-
Added rsqrt function.
-
Release 2.1.0.
-
Release 2.1.0.
-
Separated performance tests into new file.
-
Improved accuracy of atan2.
-
Fixed exception handling for integral conversions.
-
Tested exception handling for 2 argument functions.
-
Changed handling of unused parameters.
-
Updated documentation.
-
Fixed tgamma exceptions.
-
Integrated branch for exception handling.
-
Tested exception detection and handling.
-
Updated documentation for error handling.
-
Added precondition error handling to mathematical functions.
-
Added error handling functionality.
-
Fixed Win64 rounding behaviour in tests.
-
Floating-point exception handling.
-
Updated tests.
-
Release 2.0.0.
-
Release 2.0.0.
-
Tested with gcc and clang.
-
Fixed problems in C++03.
-
Fixed problems with 64-bit integers in fixed point computations.
-
Fixed problems with gcc.
-
Updated documentation for version 2.0.
-
Removed clean branch.
-
Added support for Intel compiler (untested).
-
Reintegrated branch for version 2.0.
-
Fixed error in atan2 reference file.
-
Implemented and tested gamma functions.
-
Improved performance of exponential functions.
-
Improved performance of asin, tanh and atanh functions.
-
Extended constexpr support to comparison and classification functions.
-
Improved performance of conversion functions.
-
Improved performance of comparison functions and operators.
-
Improved accuracy of sincos function.
-
Improved accuracy of cos and tan functions.
-
Improved accuracy of sin function.
-
Improved accuracy of atan function.
-
Improved accuracy of asinh function.
-
Improved accuracy of sinh function.
-
Improved accuracy of asin function.
-
Improved accuracy of tanh and expm1 functions.
-
Tested F16C intrinsics.
-
Improved accuracy and performance of arc functions.
-
Improved accuracy of cosh function.
-
Added worksheet for accuracy and performance statistics.
-
Added override for using builtin floating point types for internal computations.
-
Added support for F16C intrinsics (untested).
-
Ellipses and rounded rectangles aren't closed
-
PdfPainter functions don't update internal variables for current positions
-
Improved accuracy of logarithmic computations.
-
Improved accuracy of error functions.
-
Improved precision of trigonometric functions without 'long long' support.
-
Implemented and verified trigonometric functions for big arguments.
-
Updated documentation.
-
Updated documentation.
-
Hello, As explained in the OpenGI programming guide, you can store pretty much any...
-
There are various resources on the web on how to store images, including in BMP ...
-
Don't worry, it's not really called very often, only when the hash is created or...
-
Updated documentation.
-
Improved inverse trigonometric and inverse hype...
-
Added performance tests.
-
Implemented and verified error functions.
-
Revised reference test format. Tuned iterations...
-
Fixed and tested 3D hypot.
-
Added more reference tests.
-
Added more reference tests.
1 >
