confusion about real vs not real zero

[Stephen Chang]

In the following, why is the first considered a real number but the
second considered not real

> (real? 0.0+0i)
#t
> (real? 0.0+0.0i)
#f

[Sorawee Porncharoenwase]

I had this exact same question when I looked at the RacketScript issue lol.

The answer is https://docs.racket-lang.org/reference/numbers.html:

a complex number with an exact zero imaginary part is a real number.

Since 0.0 is not exact, 0.0i is not a real number.

--
You received this message because you are subscribed to the Google Groups "Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to racket-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/CAFfiA1%2BYygGrLH2rtwby8AWg7Edyvq-tzmANTNypq5Rqd-eXFw%40mail.gmail.com.

[Stephen Chang]

Lol I read that page and still didn't get it.

Any opinion for a potential workaround?

[Stephen Chang]

Sorry, the "workaround" was in regard to complex numbers. How to
support them in a minimal way so that programs that dont use them are
not blocked by lack of full support.

On Fri, Nov 19, 2021 at 3:20 PM Sam Tobin-Hochstadt <sa...@indiana.edu> wrote:

>
> On Fri, Nov 19, 2021 at 3:13 PM Stephen Chang <stcha...@gmail.com> wrote:
> >
> > Lol I read that page and still didn't get it.
> >
> > Any opinion for a potential workaround?
>

> It depends what you mean by "workaround". The distinction between
> exact and inexact numbers is pretty deeply built-in to how Racket
> numbers work, so there's not going to be a simple workaround that
> fixes this issue.
>
> For RacketScript I think the choices are (a) use floats for everything
> and have semantics that diverge substantially from Racket or (b) have
> a separate implementation of integers that's not JS numbers (maybe JS
> bigints would work).
>
> Sam

> > To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/CAFfiA1%2B3yRzzh%3DKhcOddt0geMezNsxQGHqzwGTYbZjLekUQ8kQ%40mail.gmail.com.

[Sorawee Porncharoenwase]

Yeah, I was about to reply that I don't think there's a workaround, too.

What is your goal, though? Do you intend to support complex numbers properly right now? In particular, that problematic code is random generation from contracts, which is rarely invoked anyway. Intuitively, there's no reason why the complex number feature is required to get the code running.

So one potential solution is to not support complex numbers right now, and compile all complex number literals to a JS expression that throws an exception at runtime.

On Fri, Nov 19, 2021 at 12:20 PM Sam Tobin-Hochstadt <sa...@indiana.edu> wrote:

On Fri, Nov 19, 2021 at 3:13 PM Stephen Chang <stcha...@gmail.com> wrote:
>

> Lol I read that page and still didn't get it.
>
> Any opinion for a potential workaround?

It depends what you mean by "workaround". The distinction between
exact and inexact numbers is pretty deeply built-in to how Racket
numbers work, so there's not going to be a simple workaround that
fixes this issue.

For RacketScript I think the choices are (a) use floats for everything
and have semantics that diverge substantially from Racket or (b) have
a separate implementation of integers that's not JS numbers (maybe JS
bigints would work).

Sam

>

> To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/CAFfiA1%2B3yRzzh%3DKhcOddt0geMezNsxQGHqzwGTYbZjLekUQ8kQ%40mail.gmail.com.

[Stephen Chang]

I dont want to fully support complex numbers. I just want to do the
minimum so that programs that dont use them are not blocked by the
lack of support

On Fri, Nov 19, 2021 at 3:30 PM Sorawee Porncharoenwase

[Alain De Vos]

Check if the distance from (0,0) is "small enough" ?