Sorry, my earliest and latest references were wrong. Here are the papers I am aware of with the known algorithm names in parentheses:
1972 - http://kurtstephens.com/files/p372-steele.pdf (dragon) 1990 - http://ampl.com/REFS/rounding.pdf (dtoa) 2010 - http://www.cs.tufts.edu/~nr/cs257/archive/florian-loitsch/printf.pdf (grisu) 2016 - https://cseweb.ucsd.edu/~lerner/papers/fp-printing-popl16.pdf (errol) *José Valim* www.plataformatec.com.br Skype: jv.ptec Founder and Director of R&D On Fri, Dec 2, 2016 at 4:08 PM, José Valim <[email protected]> wrote: > > String.Chars.to_string/1 is only implemented by default for types that > can be represented with unambiguous precision… with the exception of Float > . > > A float number can be represented as a string with no ambiguity. There are > many papers that explain how to do so quickly and accurately, the earlier > and latest I am aware are: > > http://www.cs.tufts.edu/~nr/cs257/archive/florian-loitsch/printf.pdf > https://lists.nongnu.org/archive/html/gcl-devel/2012-10/pdfkieTlklRzN.pdf > > What is not possible is the opposite: to get a string representing a > number and represent that accurately as a float. So the ambiguity in your > example is not from when the float is converted to a string but from when > we parse the string in your Elixir source code and attempt to represent it > as a float. > > Therefore to_string is behaving as expected. > > *José Valim* > www.plataformatec.com.br > Skype: jv.ptec > Founder and Director of R&D > > On Fri, Dec 2, 2016 at 3:33 PM, Bryan Enders <[email protected]> > wrote: > >> String.Chars.to_string/1 is only implemented by default for types that >> can be represented with unambiguous precision… with the exception of >> Float. The ambiguity with regards to representing tuples and maps (and >> by extension structs) would seem to be the primary reason for omitting a >> default implementation for those types. The same could be said of floats. A >> programmer attempting to interpolate 1_000.0 into a string might be very >> surprised to discover that the string representation is "1.0E3". They >> might be even more surprised to discover that interpolating >> 12_123_123_123_123_123_123.0 will be rounded in its representation as >> "1.2123123123123122e19". The protocol implementation must make >> formatting assumptions with regards to precision when it comes to floats. I >> would recommend the eventual deprecation of the default String.Chars >> implementation >> for Float. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "elixir-lang-core" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To view this discussion on the web visit https://groups.google.com/d/ms >> gid/elixir-lang-core/a2c0dfa4-97ec-4f97-8953-ce8660d2bedd% >> 40googlegroups.com >> <https://groups.google.com/d/msgid/elixir-lang-core/a2c0dfa4-97ec-4f97-8953-ce8660d2bedd%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> For more options, visit https://groups.google.com/d/optout. >> > > -- You received this message because you are subscribed to the Google Groups "elixir-lang-core" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4JfxgGnC5ErvUbQQ5vVZ1DKhg3__zh2zkszQxmqbE5j5A%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
