We can discuss improving the formatting for floats but it is important to
leave the Principle of Least Astonishment at the door because different
people are going to have different expectations of what is the least
surprising and we would be unable to reach an agreement.
We implement Kernel.to_string for types that have a meaning outside of the
Elixir environment. If I show {1, 2, 3} to a non programmer, it is unlikely
they would understand what it means. Therefore, we don't implement the
to_string protocol for tuples because we want the programmer to think about
how that term should be formatted before printing it in a GUI or a web UI.
On the other hand, the formatting of floats is quite well known and
understood. I can't recall exactly where I learned it but I was certainly
aware of it by high school.
*José Valim*
www.plataformatec.com.br
Skype: jv.ptec
Founder and Director of R&D
On Fri, Dec 2, 2016 at 4:48 PM, Bryan Enders <[email protected]>
wrote:
> 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]> 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%40
>>> googlegroups.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/CAGnRm4K1TQTRgAB2XHrNL%2Bwmwng1bx1HTdmmEtK6MvA79yTi6g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
