That’s a good point, José. It does make unexpected assumptions with regards to formatting (scientific notation when it’s shortest, decimal otherwise), but I was incorrect in asserting that it makes assumptions with regards to precision. The String.Chars implementation for Date makes formatting assumptions, but at least they are backed by the ISO 8601 standard. Most programmers would not be surprised that interpolating ~D[1970-01-01] results in "1970-01-01". I do think they’d be surprised that interpolating 1000.0 would result in 1.0e3 while interpolating 1000.5 would result in "1000.5". The default implementation would seem to violate the Principle of Least Astonishment.
If providing obvious representations of basic types that can be represented obviously is not the purpose of String.Chars.to_string/1 (as opposed to Kernel.inspect/1), then shouldn’t there be default implementations for all the primitive types in Elixir? On Friday, December 2, 2016 at 10:09:17 AM UTC-5, José Valim 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] > <javascript:>> 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] <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/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/9033fd21-1ffc-44fa-a7c2-02f92f54699c%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
