220 24854 <47b6a73e-1ead-4536-b2e4-ca00402a2324@isocpp.org> article Path: news.gmane.org!not-for-mail From: u97234@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Deprecating to_string() for floating point types and introducing a replacement Date: Mon, 29 Feb 2016 15:26:49 -0800 (PST) Lines: 316 Approved: news@gmane.org Message-ID: <47b6a73e-1ead-4536-b2e4-ca00402a2324@isocpp.org> References: <7c6c597d-6d77-4675-8560-295c7feacc04@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1064_1984918039.1456788409595" X-Trace: ger.gmane.org 1456788419 4978 80.91.229.3 (29 Feb 2016 23:26:59 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 29 Feb 2016 23:26:59 +0000 (UTC) Cc: u97234@gmail.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCE2PZXXWUFBBOVH2O3AKGQETLPMX4A@isocpp.org Tue Mar 01 00:26:55 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yk0-f199.google.com ([209.85.160.199]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aaXDI-0003io-RL for gclcip-std-proposals@m.gmane.org; Tue, 01 Mar 2016 00:26:53 +0100 Original-Received: by mail-yk0-f199.google.com with SMTP id z7sf267334236yka.2 for ; Mon, 29 Feb 2016 15:26:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:x-original-sender:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=O264vGMkvQ0cL0nxZWLlX3UzuVVfmRgNRCdjMzWNFmU=; b=S9vYyi7IYNPLHrTd1mGZt/PISdFA/gFFCFRxzWc5PtfxhSHzSlZVzyY89kWVm9lnmJ iM+9+qF5fg3fmISxgE5GhIpyDa8evj1ro+l7El/Oow1T1aMB4gNRcbn6DfuD1jGoLkXj ZXWKoifAgusQmaH6/txTo3N/mYHH3uEEm7bIcHFsdM+W2RloMgiDekXAT7qbYacdCMJL kYpSgbNY9xpK7LSdlNE4ybD0yQo7xUzf7bXRiihU6NgYPrU8cd/lQvjzCIi2PQutZ3YW tIACIwBNjWvFASfZi1Qwhx97C3liZq/xovQGPMy1itAQK65biSLT04hbzR/mJhjR7mN1 RfHQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:x-original-sender:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=O264vGMkvQ0cL0nxZWLlX3UzuVVfmRgNRCdjMzWNFmU=; b=hCoGbqO+YwZ6FW3giiRDNBjYAW45KdZWWuGYytvLqqhZtCReVo4jR7SzJNDU3NkUIX cgBWhOrh6N191F4+08fbR3ah8Q86SJfW82q+792pNE+2OFrYiRntgTpPgrV0tAYkVXlS rgJUSl1TCcM4+xrkQE3sYupu9QjXpIz/Lt1MeX66vsT7UjFOWFN8RWpxmOs40e9KR2is YguThbNunMfC7g7M1cEa1u4KE+Coa37gdxvq+lMU6GHj94UjI3YZJdfbGNBUgb0cMg8X sLJMHCbU/9W9jsAjuYIthrtOQrZfzU5oHSn1y29q4XJ0/k8w1CHCcFK9T1qHv1Bmnahu Aqcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version:x-original-sender:reply-to :precedence:mailing-list:list-id:x-spam-checked-in-group:list-post :list-help:list-archive:list-subscribe:list-unsubscribe; bh=O264vGMkvQ0cL0nxZWLlX3UzuVVfmRgNRCdjMzWNFmU=; b=hvN/PQFsSHS8Jt0oHyLRtpxCDbGR7c2Ck/DNThu8cnf4G9PcPMUE/nI1LEnHnIACQ2 w8com3ldCAk5qDlUqJUo5c1KLkgXc3l9ReWdylGT3sw8bJLXcGU5kdQ6QRoEiAYCOaUm shnXagSy7nINovAKYPBvLyplREtXm8hMIPmZyNYcRp87v4ugtE6X02w3vIVakmhhkGZi LAR8FnBNBBGAZ5dB897wT3zqdU/WSIHTYer2B2tpZh8+4L0D2IoP9YVya36ENW6XfBcW sKLy6dZEfaoUTwgBNbfv+Is5ZfRUiVAG3AC2b6ZGIUUtZreMQLghLnRlv510iavTLAQt x34Q== X-Gm-Message-State: AD7BkJIf85Z4i5owyG6C4nar4kuJZMKnIMhGOS5aVBkc9yMOAX/+akhRnf6ypoWMLaXBiQ== X-Received: by 10.140.240.129 with SMTP id l123mr14514224qhc.8.1456788412001; Mon, 29 Feb 2016 15:26:52 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.41.212 with SMTP id p203ls660679iop.5.gmail; Mon, 29 Feb 2016 15:26:50 -0800 (PST) X-Received: by 10.50.153.68 with SMTP id ve4mr14184igb.8.1456788410653; Mon, 29 Feb 2016 15:26:50 -0800 (PST) In-Reply-To: <7c6c597d-6d77-4675-8560-295c7feacc04@isocpp.org> X-Original-Sender: u97234@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Spam-Checked-In-Group: std-proposals@isocpp.org X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:24854 Archived-At: ------=_Part_1064_1984918039.1456788409595 Content-Type: multipart/alternative; boundary="----=_Part_1065_885126106.1456788409596" ------=_Part_1065_885126106.1456788409596 Content-Type: text/plain; charset=UTF-8 Thanks for the responses. @d.h.go... I haven't, might be a good idea to do so. @Moritz Klammler About the inconsistency with integer versions, importance of round-tripping and hexfloat The inconsistency is in some sense hard to evaluate because, as mentioned, the original paper did not specify the purpose of to_string(). In many use cases such as human readable files using hexfloat might be a fundamental change to usability: for example I would reckon that it's quite different for interoperability with other tools (spreadsheet etc.) to have a file with %g-formatted values compared to hexfloats. And using it is even harder to justify when one can use non-lossy decimal representation. But requiring round-tripping might actually be indirect: what if it is not required? What should to_string() do? If the suggestion is a lossy precision, the arguments can directly address the question why the chosen number of digits can be considered a "fits for all" choice. Of course round-tripping format does not fit for all, but I considered loss of information much bigger an issue than having an inconvenience in the output; standard can't make a guarantee that the formatted looks nice and has the right number of digits for everyone, but it could guarantee some aspects of information preservation for everyone. hexfloat is by my understanding available through options 'a' and 'A'. Likelihood of causing breaking changes Generally speaking if a developer has created an application relying on a standard guaranteed behaviour, any change can be a breaking one (here for example one could be assuming that the result does not contain character 'e'). Especially the silent runtime behaviour change is potentially hazardous. Use of exceptions Unfortunately the noexcept seems to be out of question due to the potential allocation of std::string. thanks for pointing that out. Why the (direct) use of exceptions such as std::invalid_argument does not seem appropriate is that it seems a bit too severe a consequence that failing to create a string would in practice often crash the application; i.e. people would forget to use try-catch with to_string(). It's not a serious error if conversion fails as the function can simply report "I got garbage, I can't give an answer and you can check this from the return value if interested". If the failure is a serious error for the application, it should handle it accordingly. But this is more a question of when and why the standard seems appropriate to use exception and how to apply it in this case if this ever proceed to such stage. "Finally, why does it have to be a new function?" Because any change is potentially a breaking change; if experienced standard people feel the expected consequences are negligible, personally I would probably use to_string() more happily than to_string_f(). And while "%g" would have been better than "%f" in some sense, %g implies only 6 significant digits which also has a severe problem: const auto t = std::time(nullptr); const auto d = static_cast(t); if (t == d) { char szBuffer[128]; std::cout << "Values are identical\n" << "to_string(t) = " << std::to_string(t) << '\n' << "to_string(d) = " << std::to_string(d) << '\n'; sprintf(szBuffer, "%g", d); std::cout << "to_string(d) if %g instead of %f = " << szBuffer << '\n'; } Example output: Values are identical to_string(t) = 1456783429 to_string(d) = 1456783429.000000 to_string(d) if %g instead of %f = 1.45678e+09 So with %g identical values would result to fundamentally different strings depending on type. So simply changing %f -> %g might result to loss of precision and severely break existing code on runtime. And if setting a higher precision to avoid this, the question is how precise? The proposal would make it easy: it's precise enough that there's no need to worry about it. -- You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group. To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org. To post to this group, send email to std-proposals@isocpp.org. To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/47b6a73e-1ead-4536-b2e4-ca00402a2324%40isocpp.org. ------=_Part_1065_885126106.1456788409596 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks for the responses.

@d.h.go...

I haven't, might be a good idea to do so.

@Moritz Klammler=

About the inconsistency with inte= ger versions, importance of round-tripping and hexfloat

The in= consistency is in some sense hard to evaluate because, as mentioned, the or= iginal paper did not specify the purpose of to_string(). In many use cases = such as human readable files using hexfloat might be a fundamental change t= o usability: for example I would reckon that it's quite different for i= nteroperability with other tools (spreadsheet etc.) to have a file with %g-= formatted values compared to hexfloats. And using it is even harder to just= ify when one can use non-lossy decimal representation. But requiring round-= tripping might actually be indirect: what if it is not required? What shoul= d to_string() do? If the suggestion is a lossy precision, the arguments can= directly address the question why the chosen number of digits can be consi= dered a "fits for all" choice. Of course round-tripping format do= es not fit for all, but I considered loss of information much bigger an iss= ue than having an inconvenience in the output; standard can't make a gu= arantee that the formatted looks nice and has the right number of digits fo= r everyone, but it could guarantee some aspects of information preservation= for everyone.

hexfloat is by my understanding available through opt= ions 'a' and 'A'.


Likelihood of causing breaking changes

Generally speaking = if a developer has created an application relying on a standard guaranteed = behaviour, any change can be a breaking one (here for example one could be = assuming that the result does not contain character 'e'). Especiall= y the silent runtime behaviour change is potentially hazardous.

Use of exceptions

Unfortunately= the noexcept seems to be out of question due to the potential allocation o= f std::string. thanks for pointing that out. Why the (direct) use of except= ions such as std::invalid_argument does not seem appropriate is that it see= ms a bit too severe a consequence that failing to create a string would in = practice often crash the application; i.e. people would forget to use try-c= atch with to_string().=C2=A0 It's not a serious error if conversion fai= ls as the function can simply report "I got garbage, I can't give = an answer and you can check this from the return value if interested".= If the failure is a serious error for the application, it should handle it= accordingly. But this is more a question of when and why the standard seem= s appropriate to use exception and how to apply it in this case if this eve= r proceed to such stage.

"Fi= nally, why does it have to be a new function?"

Because an= y change is potentially a breaking change; if experienced standard people f= eel the expected consequences are negligible, personally I would probably u= se to_string() more happily than to_string_f(). And while "%g" wo= uld have been better than "%f" in some sense, %g implies only 6 s= ignificant digits which also has a severe problem:

=C2=A0 =C2=A0 const auto t =3D std= ::time(nullptr);
=C2=A0 =C2=A0 const auto d =3D static_cast<double>(t);
=C2=A0 = =C2=A0 if<= /span> (t =3D=3D d)
=C2=A0 =C2=A0 {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 char szBuffer[128];
=C2=A0 =C2=A0 =C2=A0 =C2=A0 std::cout << "Values are identical\n"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 << = "to_string(t) =3D " << std::to_str= ing(t) << '\n'
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 << = "to_s= tring(d) =3D " = << s= td::to_string= (d) << '\n';
=C2=A0 =C2=A0 =C2=A0 =C2=A0 sprintf(szBuffer, "%g", d);
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 std::cout << = "to_s= tring(d) if %g instead of %f =3D " << szBuffer << '\n';=
=C2=A0 =C2=A0 }<= br>


Example output:
Values are identical
to_string<= span style=3D"color: #660;" class=3D"styled-by-prettify">(t) =3D 1456783429
to_string(d= ) =3D 1456783429.000000
to_string(d) if <= /span>%g instead of = %f =3D 1.45678e+09

So with %g identic= al values would result to fundamentally different strings depending on type= .. So simply changing %f -> %g might result to loss of precision and seve= rely break existing code on runtime. And if setting a higher precision to a= void this, the question is how precise? The proposal would make it easy: it= 's precise enough that there's no need to worry about it.
=

--
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposa= ls+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.= com/a/isocpp.org/d/msgid/std-proposals/47b6a73e-1ead-4536-b2e4-ca00402a2324= %40isocpp.org.
------=_Part_1065_885126106.1456788409596-- ------=_Part_1064_1984918039.1456788409595-- .