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 21:38:00 -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=gsi3nQuaJtd9NRYSp7rwjgsiVC0mR+2KyOCJhaFuuec=; b=CwrlggyU/+HjtFEMC7In1JixiuEn5EF7OVK3N4tadd1rcLSTkti4+MyijrJDxXb6YC bDDlxy0vFD/iZpSWWt4vh9KZisbevVvASrYs3TfbbGT8KEczop31+FfFqSDYVT4QsNGL P8eQqbci4Zic7qDcxTXlAwwfMwNwojnU/MXQU=
2012/1/5 Benoit Jacob <jacob.benoit.1@xxxxxxxxx>:
> Notice that isfinite can be implemented simply in terms of plain arithmetic:
>
> bool isnotnan(float x) { return x == x };
>
> bool isfinite(float x) { return isnotnan(x-x); }
>
> So you can implement that using Eigen array operations. I don't
> remember if we already have a utility function for that.
>
> template<typename Derived>
> bool isnotnan(const ArrayBase<Derived>& x)
> {
> return x == x;
> }
>
> template<typename Derived>
> bool isfinite(const ArrayBase<Derived>& x)
> {
> return isnotnan(x - x);
> }
And to get the expression you mentioned in your email (a single bool,
true if all entries are finite), you just have to call .all() on the
result.
Benoit
>
> Cheers,
> Benoit
>
> 2012/1/5 Radu B. Rusu <rusu@xxxxxxxxxxxxxxxx>:
>> I was wondering if there's a need for optimized versions for isNaN, isFinite, etc. 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.
>>
>>
>>