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.

Sign up for GitHub

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

Jump to bottom

why use Float32 for GraphQLFloat? #130

Closed
teloon opened this issue May 19, 2016 · 3 comments
Closed

why use Float32 for GraphQLFloat? #130

teloon opened this issue May 19, 2016 · 3 comments
Labels
enhancement
Milestone
v0.5.0

Comments

@teloon
Copy link

teloon commented May 19, 2016

There surely will be cases that need better precision or number range. Just want to know if there's any concern not using Float64 here.
@sogko
Copy link
Member

sogko commented May 31, 2016

Actually this is valid, there is no reason why it should be Float32.

From spec:

The Float scalar type represents signed double‐precision fractional values as specified by IEEE 754. Response formats that support an appropriate double‐precision number type should use that type to represent this scalar.

It only specifies that it has to be IEEE 754, nothing about 32 vs 64-bit.

sogko added a commit that referenced this issue May 31, 2016
@sogko
Updated graphql.Float coercion
c7fc493 
- if value type is explicitly `float32`, return `float32`
- if value type is explicitly `float64`, return `float64`
- if value type is `string`, return `float64`
- for everything else, use system-default

Addresses issue #130
@sogko sogko added this to the 0.5.0 milestone May 31, 2016
@teloon
Copy link
Author

teloon commented May 31, 2016

diff looks good. thanks for your effort!

@sogko sogko mentioned this issue Jun 2, 2016
Merged
@sogko
Copy link
Member

sogko commented Jun 12, 2016

Merged related PR #133.

Thanks @teloon!

Cheers!

@sogko sogko closed this as completed Jun 12, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
enhancement
Projects
None yet
Milestone
v0.5.0
Development

No branches or pull requests
2 participants
@sogko @teloon