| Re: [eigen] checking for NaN |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/eigen Archives
]
- To: eigen@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [eigen] checking for NaN
- From: Benoit Jacob <jacob.benoit.1@xxxxxxxxx>
- Date: Thu, 5 Jan 2012 22:43:27 -0500
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=x/4prfT58YRYRjVLvKUsQwOpRcBNr1Gnoe/vZfkMRBk=; b=u45CZAebCghpVHVs4op8V8El3tCT+us/ShEl0p08i5hjypaTqBe8ClorT/Q7lWYnhK IxbcS33a730HZKMmbm5uj8JESABRx+IN99OzlL4+X+eP3epCJ5emPmuZNRrnwLRRaBR+ YwWov2ZlV3gi4I9lE0OjV0Q45acM6HpG4Ym5A=
2012/1/5 Radu B. Rusu <rusu@xxxxxxxxxxxxxxxx>:
> I was wondering if there's a need for optimized versions for isNaN, isFinite, etc.
If _you_ have a need for it, then there's a need :) The next question
is how portable/clean can it be (do you need more SIMD intrinsics than
we already have generic wrappers for? see Core/arch/SSE/PacketMath.h),
and the question after is will you write a good unit test for it. If
you address all these questions, I'm sure your patch would get
accepted!
Benoit
> I caught Benoit talking about it
> earlier last year (http://forum.kde.org/viewtopic.php?f=74&t=96166), and did a bit of searching online to find
> discussions here: http://locklessinc.com/articles/classifying_floats/ and here:
> https://bugzilla.mozilla.org/show_bug.cgi?id=416287
>
> Due to the nature of our data, we end up calling isNaN extensively on large datasets, and we end up running things like:
>
> return (pcl_isfinite (p.x) && pcl_isfinite (p.y) && pcl_isfinite (p.z));
>
>
> The article from locklessinc seemed interesting with respect to an optimized SSE version for Vector4f.
>
> Thanks,
> Radu.
>
>
>