Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[ base ] Add bindings for ieee Double number consts #3116

Merged
merged 11 commits into from
Nov 9, 2023

Conversation

CodingCellist
Copy link
Collaborator

MVP (afaict) for having these constants available to those who want it, along with some tests that I think check they behave as expected

Closes #29

Should this change go in the CHANGELOG?

  • If this is a fix, user-facing change, a compiler change, or a new paper
    implementation, I have updated CHANGELOG.md (and potentially also
    CONTRIBUTORS.md).

Racket provides a builtin for the epsilon `epsilon.0`. Chez Scheme does
not, but we can calculate it manually.

The (machine-)epsilon is the minimum distance between floating-point
numbers. The rounding unit is the smallest number which does not move a
float (iiuc), typically defined as eps/2 (or rather, eps is sometimes
2ru).
With accompanying tests for schemes and node
Seems to be the technical term; I'd just misremembered what it was.
Combined, the IEEE-related commits close idris-lang#29
Copy link
Member

@gallais gallais left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think our standard approach has been to call the naked foreign primitive
something like prim__xxx and then defining an xxx toplevel function.
We can attach documentation to that xxx.

Then again this may be because we typically have PrimIO involved and we
use these toplevel definitions to wrap the call into a nicer IO...

@CodingCellist
Copy link
Collaborator Author

I think our standard approach has been to call the naked foreign primitive something like prim__xxx and then defining an xxx toplevel function. We can attach documentation to that xxx.

Then again this may be because we typically have PrimIO involved and we use these toplevel definitions to wrap the call into a nicer IO...

That was almost exactly my rationale; don't wrap the names with prim because they're not going via PrimIO. Then again, if it makes documentation and/or workings clearer, should there be a redirect anyway?

For SOME reason, using `epsilon.0` in `support.rkt` trips the totality
checker but only on `libs/papers/Data/Description/Regular.idr` ???

Idk man, computers were a mistake...
@CodingCellist
Copy link
Collaborator Author

(Copying from Discord so it doesn't get lost in the aether):

Issue 1 is that the new bindings require math/flonum from the Racket libraries in order to use epsilon.0. And for some reason using epsilon.0 anywhere in support.rkt, even if it's never linked to anything in Idris and just hanging out as unused code in the support file, trips the totality checker.

Now why that causes the totality checker of all things to trip, and why it only trips it on papers' Data/Description/Regular.idr I have no clue. It makes no sense to me, and I don't know where to begin trying to figure out what/how it happens. I thought it was because bootstrap/idris2_app/idris2.rkt does not require the library in its header. But I reran the bootstrap with (require math/flonum) manually added to the bootstrap file and it still crashed

CodingCellist added a commit to CodingCellist/Idris2 that referenced this pull request Nov 3, 2023
For some reason, having `epsilon.0` from `(require math/flonum)`
anywhere in the Racket support library trips the totality checker,
regardless of whether the code is used or not. Operations from
`math/flonum` (e.g. `fl/`) do not reproduce this behaviour.

See idris-lang#3116 for the full context.
@gallais gallais merged commit d80bc15 into idris-lang:main Nov 9, 2023
22 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Double IEEE constants: infinity, NaN, epsilon ... where are they?
2 participants