<div dir="ltr"><div>Small point: float_to_list/2 will get it soon, (OTP25 at most) and i hope we can make it the default in float_to_list/1.</div><div><br></div><div>Something worth pointing out, a lot of these shortest roundtrip without loss of precision are slightly broken. The main reason it is not present in most language is that glibc printf cannot do it (no %g is not the same) and that until fairly recently (2018) it was not known how to make it fast and not need Big Integers.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, 9 May 2021 at 02:05, Bob Ippolito <<a href="mailto:bob@redivi.com">bob@redivi.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Modern JavaScript does have BigInt. No syntax support though, so it is not very ergonomic. <a href="https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/BigInt" target="_blank">https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/BigInt</a><div><br></div><div>Many (most?) modern float-to-string functions will use the minimal number of digits that can represent the float exactly (round-trip without loss of precision). Erlang's float_to_list/1 is a relic that does not, possibly for backwards compatibility reasons. I bet changing it would at least break some brittle tests :) Fortunately the functionality is available in OTP these days, in a roundabout way.</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, May 8, 2021 at 3:37 PM Peer Stritzinger <<a href="mailto:peer@stritzinger.com" target="_blank">peer@stritzinger.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Just reading that you come from a accounting background: this messiness I described is the reason its a quite bad idea to represent monetary values as floats because its also the reason that:<br>
<br>
This is not exactly what was requested by the current tutorial step. Feel free to play with the shell, anyway.<br>
<br>
> 0.1 + 0.1 + 0.1+ 0.1+ 0.1+ 0.1+ 0.1+ 0.1+ 0.1+ 0.1.<br>
0.9999999999999999<br>
<br>
No Erlangs floating point implementation isn’t broken (at least not in this way).  All floating point implementation based on binary fractions behave like this.<br>
<br>
Thats why some languages used for finance have decimal fractions and in languages that don’t the only sane way to represent monetary values are using a integer multiple of some fixed fraction of the currency involved (like pico euro).  Its nice if you have a non overflowing integer representation like in Erlang for that BTW.<br>
<br>
Now imagine JavaScript has no integers but only floats (if they just added integers recently I take that back partially ;-) and are used to represent money quite a bit -> joy!<br>
<br>
Cheers,<br>
-- Peer <br>
<br>
<br>
> On 9. May 2021, at 00:27, Peer Stritzinger <<a href="mailto:peer@stritzinger.com" target="_blank">peer@stritzinger.com</a>> wrote:<br>
> <br>
> I think for the sake of the OP "round trip" needs explaining:<br>
> <br>
> It does not mean that “arbitrary float string X” -> float -> “string identical to X” is true.<br>
> <br>
> It does however mean: float Y -> string representation -> float Y.<br>
> <br>
> One problem is that many fractions like e.g. the simple example of decimal 0.1 are representable as a finite binary fraction:<br>
> <br>
> 0.1 base 10 is 0.00011001100110011… base 2 (where … means its a infinite repetition of the digits 0011)<br>
> <br>
> So converting seemingly harmless base 10 floating point strings result in infinite binary fractions.  Then it depends on how they are rounded if conversion back to base 10 string gives you the same string or a rounding error shows.<br>
> <br>
> Cheers,<br>
> -- Peer <br>
> <br>
>> On 7. May 2021, at 13:57, Thomas Depierre <<a href="mailto:depierre.thomas@gmail.com" target="_blank">depierre.thomas@gmail.com</a>> wrote:<br>
>> <br>
>> That is not true.<br>
>> <br>
>> The formatting used in format ~p is the shortest round trip one. This will be different for every single binary floating point number but also be far shorter and readable. There is work in progress to bring this as an option in float_to_list/2 thanks to the recent work in Ryu and Dragonbox.<br>
>> <br>
>> Having a fixed precision already exist in float_to_list/2. This works as printf %f. I strongly advise to not use it as this precision does not translate well to the binary format precision loss.<br>
>> <br>
>> I understand that float to string and string to float conversion are thought as niche topic, so i will be happy to provide all the bibliography you may need to explore it if you are surprised by my explanations.<br>
>> <br>
>> Kindly,<br>
>> <br>
>> Thomas Depierre<br>
>> <br>
>> <br>
>> On Fri, 7 May 2021, 12:27 Richard O'Keefe, <<a href="mailto:raoknz@gmail.com" target="_blank">raoknz@gmail.com</a>> wrote:<br>
>> No, making float_to_list/1 a wrapper for format... does not make sense.<br>
>> float_to_list/1 is meant to give you an accurate representation of the<br>
>> value.  Two different floats, no matter how small the difference,<br>
>> should result in different lists.  It's meant for converting a float<br>
>> to text that you can send to another machine and reconstitute the<br>
>> same value there.  This will usually result in more digits than a human<br>
>> would normally want to see.<br>
>> <br>
>> If you *want* format ~p, use it!<br>
>> <br>
>> Now perhaps there might be an argument to be made for<br>
>> float_to_list(X: number(), N: integer()) -> string()<br>
>> returning a string that represents X as accurately as<br>
>> possible using N digits.  But that is another discussion.<br>
>> <br>
>> On Thu, 6 May 2021 at 20:56, Themba Jonga <<a href="mailto:themba.jonga@gmail.com" target="_blank">themba.jonga@gmail.com</a>> wrote:<br>
>> Hi, again.<br>
>> <br>
>> Following a response I got from Dmitry Klionsky, perhaps it makes sense for float_to_list(N) to be made into a wrapper for lists:flatten(io_lib:format("~p",[N]))?<br>
>> <br>
>> Eshell V11.1  (abort with ^G)<br>
>> 1> N = 4.4445.<br>
>> 4.4445<br>
>> 2> lists:flatten(io_lib:format("~p",[N])).<br>
>> "4.4445"<br>
>> 3> P = 5.4443.<br>
>> 5.4443<br>
>> 4> lists:flatten(io_lib:format("~p",[P])).<br>
>> "5.4443"<br>
>> 5> Q = 1.2345678.<br>
>> 1.2345678<br>
>> 6> lists:flatten(io_lib:format("~p",[Q])).<br>
>> "1.2345678"<br>
>> 7> float_to_list(Q).<br>
>> "1.23456779999999999298e+00"<br>
>> 8> <br>
>> <br>
>> Regards<br>
>>  <br>
>> Themba Jonga<br>
>>  <br>
>> <br>
>> <br>
>>      Virus-free. <a href="http://www.avg.com" rel="noreferrer" target="_blank">www.avg.com</a><br>
>> <br>
>> On Wed, 5 May 2021 at 18:38, Scott Ribe <<a href="mailto:scott_ribe@elevated-dev.com" target="_blank">scott_ribe@elevated-dev.com</a>> wrote:<br>
>> > On May 5, 2021, at 10:20 AM, <a href="mailto:2QdxY4RzWzUUiLuE@potatochowder.com" target="_blank">2QdxY4RzWzUUiLuE@potatochowder.com</a> wrote:<br>
>> > <br>
>> > In short, no.<br>
>> <br>
>> Although many (most, actually nearly all) real numbers cannot be represented precisely as a float, any float can be round-tripped to text and back exactly. This is part of the IEEE floating point standard, actually. (And it's not easy...)<br>
>> <br>
>> <br>
>> <br>
>>      Virus-free. <a href="http://www.avg.com" rel="noreferrer" target="_blank">www.avg.com</a><br>
> <br>
<br>
</blockquote></div>
</blockquote></div>