Re: feature/native-comp 5bc0855 2/2: Don't treat '=' as simple equality emitting constraints (bug#46812)

[Pip Cet <pipcet@gmail.com>]

On Tue, Mar 2, 2021 at 2:30 PM Andrea Corallo <akrl@sdf.org> wrote:
> Pip Cet <pipcet@gmail.com> writes:
> > On Tue, Mar 2, 2021 at 1:47 PM Andrea Corallo <akrl@sdf.org> wrote:
> >> > It's not working either, as far as I can tell: (lambda (x) (and
> >> > (floatp x) (= x 0) x)) always returns nil when compiled.
> >>
> >> Right, I think a better approach is to relax the inputs before
> >> intersecting them so intersection is not cutting off already constrained
> >> inputs.
> >
> > That should work.
> >
> >> 8c7228e8cd for now follows this conservative approach and adds
> >> some testing for the case.
> >
> > Indeed, and it breaks trying to compile (lambda (x) (unless (= x
> > 1.0e+INF) (error "")) x). (And please don't forget NaNs, they're
> > numbers too! Except they're not.)
>
> Is there a better way to guard against these cases than catching the
> error around truncate?

I don't think so, but wrapping it into (float-rational-p) or something
would be nice. Even catching the error, by the way, isn't going to
handle the -0.0 / 0.0 special case properly.

(That is because there is no nice way to handle it, because 0.0 and
-0.0 are the same number and always will be.)

Don't forget this one either (currently miscompiled to have subr-type
((t) nil)):

(lambda (x)
  (unless (= x 0.0) (error ""))
  (unless (eql x -0.0) (error ""))
  x)

There are also some aesthetic issues with how you handle integers too
large to be accurately represented as floats and such, but I'm
focussing on correctness right now.

Pip