[eigen] Behavior of min/max if NaNs are involved, and fast-math behavior in general |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/eigen Archives
]
- To: eigen@xxxxxxxxxxxxxxxxxxx
- Subject: [eigen] Behavior of min/max if NaNs are involved, and fast-math behavior in general
- From: Christoph Hertzberg <chtz@xxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Mon, 1 Jul 2019 13:41:16 +0200
- Dkim-signature: v=1; a=rsa-sha256; c=simple/simple; d=uni-bremen.de; s=dkim; t=1561981277; i=@uni-bremen.de; bh=3BKqFMt3xkhZHVqgytWLcUfjrFfr8D2MgDw4NApNepw=; h=To:From:Date; b=Zy2O+wLsW8uXn9fSGmeL5Vtrdfqm2m/lzLsXZEVsx2NvdP4qatiZrzyX42SHCNSHT 4RBsIjqcP/mSzwKGm/bdlnt7a+7YjSWeef+n7tjAbmryUXPOvrfly5R7usyRc2KfK5 Vvojt1/PL88t3eab1DSzt60waL6+5E+j2eHUf9+A=
Hi List!
There has been a DECISIONNEEDED pending on this bug for a while:
http://eigen.tuxfamily.org/bz/show_bug.cgi?id=564
There is also a PR related to that:
https://bitbucket.org/eigen/eigen/pull-requests/658
I'm seeking for some opinions on that topic (if you don't have a
bugzilla-account, ask for one at eigen-core-team@xxxxxxxxxxxxxxxxxxx or
just answer to this list).
The current situation is that min/max functions are documented as
"undefined" regarding their behavior if NaNs are involved, so
technically we would be free to change that. However, (with SSE/AVX) a
number-propagating min/max operations is about twice as slow as the
current unspecified implementation, so we should not burden users with
the overhead if they never have NaNs (or don't care about NaN-behavior).
Essentially, the questions are
* Do you need min/max-behavior which propagates NaNs or numbers?
* Do you want to control that behavior per function or per compilation
unit?
* In the above-mentioned bug, I suggested adding an optional template
parameter to each min/max function. Do you you see any drawbacks, or do
you have alternative ideas?
And then there is a more general question about Eigen's behavior
regarding fast-math in general:
http://eigen.tuxfamily.org/bz/show_bug.cgi?id=1687
i.e., EIGEN_FAST_MATH is currently enabled by default which is probably
barely noticed since it mostly influences behavior of SIMD-math for
calculating sine and cosine of arrays.
Some more general questions regarding that:
* Does anyone actually rely on being able to disable EIGEN_FAST_MATH?
* Would anyone like to have more control over fast-math behavior?
(setting ERRNO, always ignoring NaN/infinities/denormals, ...)
Cheers,
Christoph
--
Dr.-Ing. Christoph Hertzberg
Besuchsadresse der Nebengeschäftsstelle:
DFKI GmbH
Robotics Innovation Center
Robert-Hooke-Straße 5
28359 Bremen, Germany
Postadresse der Hauptgeschäftsstelle Standort Bremen:
DFKI GmbH
Robotics Innovation Center
Robert-Hooke-Straße 1
28359 Bremen, Germany
Tel.: +49 421 178 45-4021
Zentrale: +49 421 178 45-0
E-Mail: christoph.hertzberg@xxxxxxx
Weitere Informationen: http://www.dfki.de/robotik
-------------------------------------------------------------
Deutsches Forschungszentrum für Künstliche Intelligenz GmbH
Trippstadter Strasse 122, D-67663 Kaiserslautern, Germany
Geschäftsführung:
Prof. Dr. Jana Koehler (Vorsitzende)
Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats:
Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313
-------------------------------------------------------------