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

specialized Float32 == Float64 comparison? #335

Closed
StefanKarpinski opened this issue Jan 12, 2012 · 1 comment
Closed

specialized Float32 == Float64 comparison? #335

StefanKarpinski opened this issue Jan 12, 2012 · 1 comment
Labels
needs decision A decision on this change is needed

Comments

@StefanKarpinski
Copy link
Sponsor Member

julia> float32(1/7)
0.14285715

julia> 0.14285715 == float32(1/7)
false

julia> float32(0.14285715) == float32(1/7)
true

I would expect 0.14285715 != 1/7 since the latter has lots of extra digits and the former ought to be presumed to have zeros in all those places.

StefanKarpinski added a commit that referenced this issue Jan 12, 2012
This means that what we print for Float64s will *always* eval
to the same floating-point value we originally had. Moreover,
the printed form uses the least number of digits possible to
accomplish this for any floating-point value.

There are still some unresolved issues around 32-bit floats.
See issue #335.
@StefanKarpinski
Copy link
Sponsor Member Author

Having poked around a bit, I think we have to live with this:

julia> float32(1/7)
0.14285715

julia> bits(0.14285715)
"0011111111000010010010010010010010100001100111111111100001011000"

julia> bits(float32(1/7))
"00111110000100100100100100100101"

julia> bits(float64(float32(1/7)))
"0011111111000010010010010010010010100000000000000000000000000000"

The only viable alternative is to print Float32 values by upcasting to Float64 first, but then printing them gives long, nasty strings with extra digits:

julia> float64(float32(1/7))
0.1428571492433548

The only other thing that would make this work out is to compare Float32 and Float64 by truncating to Float32, but that's clearly unacceptable.

cmcaine pushed a commit to cmcaine/julia that referenced this issue Nov 11, 2022
* Add blurb to Practice Exercise .meta/config.json files

Each Practice Exercise will have to define a blurb, which is a short description of the exercise.
The blurb will be displayed on a track's exercises page (e.g. https://exercism.lol/tracks/csharp/exercises).

For Practice Exercises that are based on an exercise defined in the problem-specification repo, the blurb must match the contents of the problem-specifications exercises, which is defined in its `metadata.yml` file. In this commit, we'll do an initial syncing of the blurb. The new [configlet](https://github.com/exercism/configlet) version will add support for doing this syncing automatically.

If the Practice Exercise was _not_ based on a problems-specifications exercise, we've used the blurb from its `.meta/metadata.yml` file as the blurb in the .meta/config.json file.

See [the spec](https://github.com/exercism/docs/blob/main/anatomy/tracks/practice-exercises.md#file-metaconfigjson) for more information.

* Add placeholder blurb to Concept Exercise .meta/config.json files

Each Concept Exercise will have to define a blurb, which is a short description of the exercise.
The blurb will be displayed on a track's exercises page (e.g. https://exercism.lol/tracks/csharp/exercises).

This commit adds a placeholder blurb to the .meta/config.json file of each Concept Exercise.

See [the spec](https://github.com/exercism/docs/blob/main/anatomy/tracks/concept-exercises.md#file-metaconfigjson) for more information.
Keno pushed a commit that referenced this issue Oct 9, 2023
This is a temporary workaround for #330
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
needs decision A decision on this change is needed
Projects
None yet
Development

No branches or pull requests

1 participant