incircle results in NaN result

[frewsxcv]

Is this expected? Does the C version do this?

Found via #18

let data = [
    (
        0.00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000602151646108571f64,
        -517539169279288000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000.0f64,
    ),
    (
        0.000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000008335571366403185f64,
        0.00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000569f64,
    ),
    (
        0.000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000008309872195179385f64,
        0.000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000008309872194912985f64,
    ),
    (
        -24214045710673702000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000.0f64,
        0.000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000008309872195179618f64,
    ),
];

let pa = robust::Coord { x: data[0].0, y: data[0].1 };
let pb = robust::Coord { x: data[1].0, y: data[1].1 };
let pc = robust::Coord { x: data[2].0, y: data[2].1 };
let pd = robust::Coord { x: data[3].0, y: data[3].1 };

let result = robust::incircle(pa, pb, pc, pd);

assert!(result.is_finite());

thread '<unnamed>' panicked at 'assertion failed: result.is_finite()', fuzz_targets/incircle.rs:13:5

[tinko92]

The C version does this and it is (imho) not unexpected because Shewchuk's algorithms only handle round-off errors, not overflow/underflow in intermediate results. The test for the correctness of the approximate result (

robust/src/lib.rs

Line 615 in 6cead7c

if det > errbound || -det > errbound {

) can succeed even if it is incorrect due to underflow and none of the exact computations (two_{sum, product}, expansion_sum, etc.) will handle overflow or underflow well.

Covering such inputs would require non-trivial changes in the implementation. For the tests of the approximate results there would be changes needed to cover underflow (such as in https://doi.org/10.1007/s10543-015-0574-9 or https://doi.org/10.1007/s10543-023-00975-x) but more problematically, for the exact computations an alternative would be required with extended exponent range.