I meant fmin, not minf :-)
On Fri, Jan 17, 2020 at 9:46 AM Rasmus Munk Larsen <[email protected]>
wrote:
> As Christoph points out, this refers to the semantic difference between
> std::min and minf (and similar for max*) in the presence of NaN arguments.
> As you can see in the bugs Christoph linked, we agree that it would be nice
> to have packet ops for the various behaviors (possibly chosen using a
> template argument), but currently Eigen follows the std::min semantics,
> which are equivalent to the ternary expression
>
> template<class T>
> const T& min(const T& a, const T& b)
> {
> return (b < a) ? b : a;
> }
>
> See https://en.cppreference.com/w/cpp/algorithm/min
>
> On Fri, Jan 17, 2020 at 8:45 AM Christoph Hertzberg <
> [email protected]> wrote:
>
>> Hi!
>>
>> Which IEEE754 version are you referring to?
>>
>> In IEEE754-1985, there was no min/max, then the 2008 draft suggested
>> introducing minNum/maxNum which propagate numbers, and the 2019 draft
>> suggests replacing those by
>> {min,max}imum{,Number,Magnitude,MagnitudeNumber} which either propagate
>> NaNs or numbers. (All to the best of my knowledge, please correct me, if
>> I'm wrong).
>>
>> Eigen follows the `std::min`/`std::max` convention of propagating the
>> first argument, if one argument is NaN. SSE/AVX propagates the first,
>> which is why we change the order for those.
>> I'm really no expert on Altivec/PPC, so no idea if there is a more
>> efficient instruction consistent with `std::min/max`.
>>
>> For reference: Here is the commit which introduced the lines you are
>> referring to:
>>
>> https://gitlab.com/libeigen/eigen/commit/e91e314347c14774206307a91d1b427e49f9b3e2
>>
>> Also, check these issues for further discussion on the topic:
>>
>> https://gitlab.com/libeigen/eigen/issues/564
>> https://gitlab.com/libeigen/eigen/issues/1373
>> https://gitlab.com/libeigen/eigen/issues/1494
>>
>>
>> Cheers,
>> Christoph
>>
>>
>>
>> On 17/01/2020 16.50, Everton Rufino Constantino1 wrote:
>> > Hi,
>> > looking at the implementation of pmin and pmax for Packet4f on
>> > Altivec/PacketMath.h I came across the following statement to justify
>> not using
>> > VSX's intrinsics:
>> > "// NOTE: about 10% slower than vec_min, but consistent with std::min
>> and SSE regarding NaN"
>> > I fail to understand the reasoning, afaik ppc and stdlib both are IEEE
>> > compatible right? Can somebody please clarify the statement? I think
>> sometime in
>> > the past ppc had a non-IEEE mode that you could turn on or off but
>> that's gone
>> > for a while now.
>> > Best regards,
>> > Everton Constantino
>> > <[email protected]>
>> >
>>
>> --
>> 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 <+49%20421%20178454021>
>> Zentrale: +49 421 178 45-0
>> E-Mail: [email protected]
>>
>> Weitere Informationen: http://www.dfki.de/robotik
>> -------------------------------------------------------------
>> Deutsches Forschungszentrum für Künstliche Intelligenz GmbH
>> Trippstadter Straße 122, D-67663 Kaiserslautern, Germany
>>
>> Geschäftsführung:
>> Prof. Dr. Antonio Krüger (Vorsitzender)
>> Dr. Walter Olthoff
>>
>> Vorsitzender des Aufsichtsrats:
>> Dr. Gabriël Clemens
>> Amtsgericht Kaiserslautern, HRB 2313
>> -------------------------------------------------------------
>>
>>
>>
>>
