Core: Use Expr::is_zero() of AST

[afabri]

Summary of Changes

Accelerate comparison with zero

Release Management

• Affected package(s): Number_types
• License and copyright ownership: unchanged

[mglisse]

Is this implementation of Is_one really faster? From what I can see, doubleInterval itself should already be more costly than ==1.

[afabri]

When comparing to 1 that constructs an Expr(1), and performs a subtraction. I wanted to avoid that.
I am also wondering if one should not use Lazy_exact_nt<Expr> instead of doing a filtering, but I said myself that Expr is somehow the same, but didn't find the interval hardcoded. And I am wondering if I first have to call Expr::approx() as done here

[mglisse]

When comparing to 1 that constructs an Expr(1), and performs a subtraction. I wanted to avoid that.

https://github.com/CGAL/cgal/blob/96f698ca09b61b6ca7587d43b022a0db43519699/CGAL_Core/include/CGAL/CORE/Expr_impl.h#L84-L89

doubleInterval also constructs an Expr from a double and performs a subtraction...

And I am wondering if I first have to call Expr::approx()

Looks like doubleValue already does it? Although the different precision is suspicious. https://github.com/CGAL/cgal/blob/96f698ca09b61b6ca7587d43b022a0db43519699/CGAL_Core/include/CGAL/CORE/Expr.h#L252-L253

but didn't find the interval hardcoded.

IIUC (but I know little about CORE) it stores an approximate value as a Real and a precision, not directly an interval.

[sloriot]

Successfully tested in CGA-6.0-Ic-173

[lrineau]

@afabri @mglisse Can you please go on with the discussion? I think Andreas has to answer to Marc's last remarks.

[github-actions[bot]]

This pull-request was previously marked with the label Tested, but has been modified with new commits. That label has been removed.

[afabri]

For the time being let's reduce it to the initial scope, namely to have a faster test for being zero.

[sloriot]

Successfully tested in CGAL-6.0-Ic-192