Float64Range/Float64Set and Float32Range/Float32Set over finite values only, mapped to custom float8range and float4range #153

Decided 2026-10-18 after research: a float range is well-defined once NaN and the two infinities are refused at construction, the way DecimalRange already cannot hold numrange's NaN. Rescheduled 2026-10-18 (maintainer): ships in 10.0.0 (epic #58), merged forward to the 11 line, as Float64Range/Float64Set and Float32Range/Float32Set (see Naming and scope below).

Why the current exclusion was imprecise. docs/why.md says IEEE operators and CompareTo disagree. The engines use CompareTo consistently, so that is not where it breaks. The break is that .NET sorts NaN first and PostgreSQL sorts it last. Measured on PostgreSQL 17.10 and 18.1 with CREATE TYPE float8range AS RANGE (subtype = float8, subtype_diff = float8mi):

So NaN is the only value that disagrees, and infinity-as-a-value only duplicates what CreateUnboundedEnd and Infinite already say. Refuse all three and the remaining doubles are a total order on which CompareTo and the IEEE operators agree.

Design

• Float64Range (and Float64Set), element double, continuous like DecimalRange. A RequireFinite(double) guard in CreateFinite, CreateUnboundedStart, CreateUnboundedEnd (and Float64Set.From/NormalizeElement): ArgumentException for NaN, PositiveInfinity, NegativeInfinity. Every construction path funnels through them: the literal parser (RangeFormat.Parse), the JSON and TypeConverter readers, RangeProviderConversion.FromProvider on the EF read leg, and the engines. YearMonthRange.RequireIso is the precedent. TryParse returns false for those literals.
• The same guard on every scalar operand, because [0,) under CompareTo does not contain NaN while PostgreSQL's @> does: Contains(T), RangeSet.Contains(T), value set Contains/Add/Remove, IValueSet<T>.NormalizeElement and the EF definition's normalizeValue (a NaN parameter fails at query time, loudly). An unsupported operand throws; it never answers false.
• Continuous, never canonicalized: PostgreSQL treats (1,1.0000000000000002) as non-empty although no double lies strictly between the endpoints. No BitIncrement step; exact comparisons, no epsilon.
• Length may overflow to infinity ([-MaxValue, MaxValue]); it returns the IEEE result, documented. Infinity as an output is not a bound.
• A stored Infinity or NaN bound therefore throws on load, loudly; document it under "Where is the model stricter than the database?" next to the numrange NaN case.
• EF: store type float8range / float8multirange, declared by the consumer with modelBuilder.HasPostgresRange("float8range", "double precision") plus EnableUnmappedTypes(), exactly as timerange, without subtypeDiff: float8mi overflows (value out of range: overflow) when PostgreSQL builds a GiST index over extreme finite values, and the index builds and answers correctly without it. The integration test builds a GiST index over [-MaxValue, MaxValue]. Float64Set is double precision[], native. Constant element operands typed (::double precision) per the polymorphic-operator rule. Literal text is the shortest round-trip form on both sides (PostgreSQL 12+ extra_float_digits 1, .NET Core 3.0+).
• Docs: a "custom types" table in docs/efcore.md listing timerange and float8range with their setup and caveats (that is the "supported, mind the quirks" tier, without a new name); docs/why.md rewritten to the measured reason above; the README's "why double is absent" line goes.
• Tests: the discovered sweeps (ShapeMatrixParityTests, LiteralCultureContractTests, TemporalLiteralStrictness… not applicable, JsonDefaultContractTests, CapturedCollectionProbeTests, HostCultureProbeTests) pick the type up by reflection; claims.json gets the new sentences; a seed that drops the guard must fail the parity sweep (the [5,NaN) row is the obvious seed).
• Float32Range / Float32Set are in scope (float4range, real; real[] native). Same finite-only guard over float. Its literal parity is a separate measurement (6 to 9 significant digits; .NET's shortest round-trip float text vs PostgreSQL's float4out with extra_float_digits 1): measure on 16 and 18 before writing the parser, and seed a defect that formats float through double.

Demand, for the record. No issue asks for a float range on Npgsql, efcore.pg, Hypersistence, Django, Rails or pgx; Django removed FloatRangeField because it was numrange in disguise; one real user found (opendatacube, float8range). Npgsql's own docs example is HasPostgresRange("floatrange", "real"). The AI/ML hypothesis (score thresholds as range columns) found no evidence. Intervals.NET is a direct .NET competitor that accepts doubles under Comparer<T>.Default, i.e. .NET order, with no PostgreSQL-parity promise; one sentence in docs/why.md. An independent review (2026-10-18) measured 4,096 sampled singleton ranges, including extremes, subnormals, infinities and NaN, round-tripping exactly through Npgsql's binary path and PostgreSQL's text path; the alternative it preferred, a PostgreSQL-ordering comparer with NaN greatest, was rejected in favour of finite-only because it would have to govern every comparison path in the engines.

Naming and scope (decided 2026-10-18)

• Float64 / Float32, not Double / Single. The integer families are named by width (Int16Set, Int32Range, Int64Range), and PostgreSQL's float types are too (float4, float8). SingleRange would also read as "one range".
• No Float16. PostgreSQL has no two-byte float, so there is no domain to mirror: a real column could hold values a Half cannot, which would round or fail on load. It is the same reason there is Int16Set (smallint[]) but no Int16Range (no int2range).
• docs/why.md and the README's "why double is absent" text are rewritten to the measured reason.