Boost logo

Boost :

Subject: Re: [boost] [ICL] #6853: boost::icl::contains(NaN) returns true
From: Jeffrey Lee Hellrung, Jr. (jeffrey.hellrung_at_[hidden])
Date: 2012-05-04 14:48:30

On Fri, May 4, 2012 at 8:14 AM, Andrew Hundt <ahundt_at_[hidden]> wrote:

> I had submitted a bug report for icl, and the response I included below
> seemed indicate this is more for the list than a bug report. It deals with
> an issue where boost::icl::contains(NaN) returns true, where any NaN value
> cannot actually be contained within an interval, and so should return
> false.
> I'm dealing with data that comes from a physical device, so each
> measurement the system returns is not guaranteed to be valid. We set those
> invalid measurements to NaN. However, when the data is valid it falls into
> certain intervals that I found icl well suited for, despite not falling
> into the original use case of time scheduling I find it to be a reasonable
> representation to work with. While IEEE floating point numbers is not
> required by the C++ standard, it is a standard that does seem to have
> fairly wide use in C++.
> It seems, at least in my use case, that NaN is a very reasonable value to
> use and fits well with the functionality icl provides. However, I wanted to
> open this to wider opinions to learn about the state of the issue.
> Cheers!
> Andrew Hundt
> ---------- Forwarded message ----------
> From: Boost C++ Libraries <noreply_at_[hidden]>
> Date: Fri, May 4, 2012 at 6:50 AM
> Subject: Re: [Boost C++ Libraries] #6853: [ICL] boost::icl::contains(NaN)
> returns true
> To:
> Cc: boost-bugs_at_[hidden]
> #6853: [ICL] boost::icl::contains(NaN) returns true
> -----------------------------------------------+----------------------------
> Reporter: Andrew Hundt <ATHundt@…> | Owner: jofaber
> Type: Bugs | Status: closed
> Milestone: To Be Determined | Component: ICL
> Version: Boost 1.49.0 | Severity: Problem
> Resolution: invalid | Keywords: icl
> -----------------------------------------------+----------------------------
> Changes (by jofaber):
> * status: new => closed
> * resolution: => invalid
> Comment:
> Hi Andrew,
> icl code is not intended to be NaN complete. NaN is a weird animal that
> breaks concepts the icl is based on. Completing icl for NaN would make the
> code unnecessarily clumsy for cases that are hardly ever used. If you
> desire to complete your code for NaN cases you will have to do it in your
> code or write your own NaN layer around the icl.
> Regards,
> Joachim
> --
> Ticket URL: <>
> Boost C++ Libraries <>
> Boost provides free peer-reviewed portable C++ source libraries.

I'd guess that including and supporting NaN makes floating point types not
conform to the ordering concepts required by the ICL, so it seems
reasonable to me to document NaN's as unsupported.

How well does std::set/std::map interact with NaN when floating point types
are used as keys?

- Jeff

Boost list run by bdawes at, gregod at, cpdaniel at, john at