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

Data.Text.Read.rational no more accurate than Data.Text.Read.double #34

Closed
reinerp opened this issue Jul 22, 2012 · 1 comment · Fixed by #565
Closed

Data.Text.Read.rational no more accurate than Data.Text.Read.double #34

reinerp opened this issue Jul 22, 2012 · 1 comment · Fixed by #565
Labels
question Requires more investigation

Comments

@reinerp
Copy link

reinerp commented Jul 22, 2012

The documentation on double states that it loses accuracy on some inputs, but using rational will fix this. I understood this to mean that if one simply used rational :: Reader Double, then one would get completely accurate results, but this doesn't appear to be the case. For instance, given the input string "5.781884674518029e-2", double :: Reader Double and rational :: Reader Double both produce an output of "5.7818846745180286e-2", whereas Prelude.read :: String -> Double produces "5.781884674518029e-2".

Perhaps the documentation means that one should actually use rational :: Reader Rational and then convert to Double with fromRational? If so, that isn't clear from the documentation.

@bitonic
Copy link

bitonic commented Sep 3, 2015

I've also stumbled upon this problem.

I was wondering if there was some performance concern regarding how the read instance for Double does the parsing (as per the https://hackage.haskell.org/package/base-4.8.1.0/docs/Text-Read-Lex.html module). Otherwise, I can replicate the functionality present there but tuned to parsing Text.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Requires more investigation
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants