220 24831 <89c4ad80-fd43-4c00-87fd-8dc38ba50739@isocpp.org> article Path: news.gmane.org!not-for-mail From: d.h.gottwald@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 07:47:51 -0800 (PST) Lines: 766 Approved: news@gmane.org Message-ID: <89c4ad80-fd43-4c00-87fd-8dc38ba50739@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_179_173916395.1456760871783" X-Trace: ger.gmane.org 1456760888 22033 80.91.229.3 (29 Feb 2016 15:48:08 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 29 Feb 2016 15:48:08 +0000 (UTC) Cc: u97234@gmail.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDZ27EHJ34JRBKGQ2G3AKGQEABYWNTY@isocpp.org Mon Feb 29 16:47:58 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-vk0-f72.google.com ([209.85.213.72]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aaQ3A-0003LT-3Z for gclcip-std-proposals@m.gmane.org; Mon, 29 Feb 2016 16:47:56 +0100 Original-Received: by mail-vk0-f72.google.com with SMTP id e6sf252321442vkh.0 for ; Mon, 29 Feb 2016 07:47:55 -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=XczULBTlbSR/r+YGjiGbf/2AArM0f2wIL9i3S1VFoJw=; b=x+TeoALiWtWNAbaoB0ywfg5KD4VsxxahyXk/m1hfOwMbpg0m4ufzZkUpx2hUmo1Hfh ephpWdGyqhKuOz1rhxLt3Un01Xcmo37B/XCUxuPzKdATwUTIvgi8Q8cK4lgfgpO3wTxu qAj6q2LXOIM/clhFrWMw5U/KSOttV6/1ROlDQi/AJzBNltgt2jyPF2HXGZGLS2XQj4sF Lovimtzk6A+5VEJHE+XPqDp1nc9yk4XRBZSf2M4L2Rz9BYoC5mABsSZ8CGX4UddtMpCf ZogtVy8qMZco7ladt/eTnLMOJn8cjQxKd88/RW6v38l0p99j9IMpw60ZE0kXdC20KU+z xeOA== 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=XczULBTlbSR/r+YGjiGbf/2AArM0f2wIL9i3S1VFoJw=; b=msoTQbK7ytgrXG0YjKYysrdSY+xstyLRSomTMN4Duk9h8BF/BWVpXlEwOefd6xcS0B j9jJ3A1ea0V+G43QzcFoVRSgMaKdFCm2rv/UsB4LdOzQvAxgFuZ1stJhc8AAJ1SsQgV3 EiiCPU+0QyoQyKlMXU+k08GKkX3JPYC3v9KXkMYfFypikr1I0o7lYxFcxCSRzEDjrDqF mu21XJlyyqb+dV4erqIH0bW7VQ5SI6spmaN2yPzN2pLD19hDawkjaRPjgvA4jLYevkhS 3zR0jbLNbPoDiY03B/WYJfDPUlgoz6Y+Do7ldKGG9qeHhm/bRSxXNdUhDtymSx1ANPj0 AX4w== 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=XczULBTlbSR/r+YGjiGbf/2AArM0f2wIL9i3S1VFoJw=; b=jWO3jIl/ibuqzP8RdwNDkAzOr3+MPftXzmghBCq68K7P9aYV9lt2jWf9Ceo6QHzUan IiPdEuzWj1pmSdJog8S819QNE1wu6754SibQwPKPAMz2MbCKmyTFR10+hd/xvG6LUih2 9GVx6HbKg0tH3i/ATmJRz5UDAIxivxlTxKb5nnwa0jDp5AYeIJ5ceRt1Y4UnqCpKGqI3 YpcNBBxyGaKnxmVPjMBylFQHVyg1ZopIdDSUPvzYeg3CxPX0NQVdHGyHo9Op6rdFNqj3 2aoESKaswKx81oaBhponl8F4qo8AehJDRpIIZKMl+qDxDMY32OYzErEdS6fg/lSI2SZ/ wz2w== X-Gm-Message-State: AD7BkJIenAw/E+Wi1zBo0TP+dPB/Q25Ek/i0O55lFsjx+fX/YbflcwuCSe97ZstCBehiHQ== X-Received: by 10.140.253.198 with SMTP id y189mr13511862qhc.9.1456760875238; Mon, 29 Feb 2016 07:47:55 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.39.206 with SMTP id n197ls1483697ion.52.gmail; Mon, 29 Feb 2016 07:47:52 -0800 (PST) X-Received: by 10.50.103.68 with SMTP id fu4mr181545igb.9.1456760872498; Mon, 29 Feb 2016 07:47:52 -0800 (PST) In-Reply-To: <7c6c597d-6d77-4675-8560-295c7feacc04@isocpp.org> X-Original-Sender: d.h.gottwald@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:24831 Archived-At: ------=_Part_179_173916395.1456760871783 Content-Type: multipart/alternative; boundary="----=_Part_180_1243467156.1456760871783" ------=_Part_180_1243467156.1456760871783 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Have you read the paper "How to print floating point numbers accurately",= =20 e.g. from here: http://kurtstephens.com/files/p372-steele.pdf This seems to cover some of the problems you described. On Sunday, February 28, 2016 at 2:06:29 PM UTC+1, u97...@gmail.com wrote: > This post continues Deprecate to_string() for floating point types?=20 > > > The original thread served it purpose and it seemed more appropriate to= =20 > start a new thread in this forum with a more proposal-like text for=20 > evaluation. > > ------------------------ > > Summary > -------------- > > This document introduces the current behaviour of std::to_string()=20 > pointing out it's fundamental problems with floating point types and=20 > suggests a change to standard. > > Introduction > ----------------- > > Converting numeric values to string is a common task in contexts like UI'= s=20 > and human readable files and common enough to be listed as a newbie=20 > question in C++ FAQ =20 > [6]. Before C++11 there was no clear choice for conversion and some of th= e=20 > options suggested [4]=20 > =20 > [5]=20 > =20 > for the task were: > > 1. std::ostringstream > 2. sprintf > 3. boost::lexical_cast > > These have problems ranging from complexity and performance to buffer=20 > handling hazards and external dependency. With std::to_string() the gener= al=20 > answer got easy: use std::to_string(). > > This, however, is not a good answer for floating point types. > > Floating point types are by their nature trickier to deal with and it's= =20 > harder to define what std::to_string() should do with floating point type= s. > > The papers introducing std::to_string() [1]=20 > [2]= =20 > [3]= =20 > does= =20 > not discuss the purpose of std::to_string() (i.e. what problem it is=20 > intended to solve) and the current standard simply defines that return=20 > string of std::to_string(double val) is identical to what sprintf(buf,=20 > "%f", val) would generate with sufficient buffer size buf. > > This paper argues that the decision is highly questionable, impractical= =20 > and a source of bugs thus suggesting a change to the standard. > > Problem > ------------ > > In form of examples, the definition of std::to_string(double val)=20 > essentially as sprintf(buf, "%f", val) has the following implications: > > 1. std::to_string(double(0)) =3D=3D "0.000000" > 2. std::to_string(double(10000)) =3D=3D "10000.000000" > 3. std::to_string(double(1e300)) =3D=3D=20 > "100000000000000005250476025520442024870446858110815915491585411551180= 245798890819578637137508044786404370444383288387817694252323536043057564479= 218478670698284838720092657580373783023379478809005936895323497079994508111= 903896764088007465274278014249457925878882005684283811566947219638686545940= 0540160.000000" > 4. std::to_string(double(1e-9)) =3D=3D "0.000000" > > While it's not obvious how the conversion should work for floating point= =20 > types, it's hard to see that any acceptable implementation would have=20 > behaviour as shown above. The problems are: > > - Redundant characters from information preservation point of view (1,= =20 > 2, 3, 4). > - Unreadable output (3) > - Failing to preserve even a single significant digit (4). > > While redundant decimal characters may be even desired in some use cases,= =20 > the failure to preserve any significant digits is a serious issue=20 > especially as it is not a rare corner case issue but affects a big=20 > proportion of the whole double domain. How big a proportion? At least in= =20 > common implementations of double, base 10 exponent can get values in rang= e=20 > [-308, 308]. All values where exponent is in range [-308, -8] are convert= ed=20 > to "0.000000" by std::to_string(). And given that readability of values= =20 > with tens of digits is bad as demonstrated in example 3, the exponent ran= ge=20 > where std::to_string() creates acceptable string representation is quite= =20 > small although the good range may well cover the most frequent use cases. > > For comparison, here's a short survey of related implementations using=20 > double (or similar type) value 1.23456789e-9: > > > - Visual Basic (VS2015) ToString() : "1.23456789E-09" > - C# (VS2015) ToString() : "1.23456789E-09" > - Java toString() : "1.23456789E-9" > - JavaScript toString() : "1.23456789e-9" > - boost::lexical_cast(1.23456789e-9):=20 > "1.2345678899999999e-09" > - Qt 5.4 QString::number(1.23456789e-9) : "1.23457e-09"=20 > - Qt 5.4 QVariant(1.23456789e-9).toString() : "1.23456789e-09" > - C++ to_string(1.23456789e-9) : "0.000000" > > > 8 implementations, in 5 the result is precision-wise identical to value= =20 > written to source code, in 1 the result is non-lossy but longer than sour= ce=20 > code version, in 1 the value is rounded to 6 significant digits and then= =20 > there's std::to_string() that simply wipes out all significant digits. > > Ideal > ------- > > If std::to_string() for floating point types was created from scratch, th= e=20 > question would be: what should it do? The following starting point is=20 > assumed: > > > - std::to_string() for integer types is defined and their=20 > implementations are what they currently are. > - to_string() is required to print (human readable) decimal=20 > representation also of floating point values. > > > Some ideas: > > > 1. With integer types, the following condition is true: x !=3D y <=3D>= =20 > to_string(x) !=3D to_string(y). Also for related from_string() impleme= ntation=20 > such as stoul(), stoul(to_string(x)) =3D=3D x for all x of type T. In = plain=20 > words this means that one can convert integer to string and read it ba= ck to=20 > get exactly the same item from which the string representation was cre= ated=20 > from. To keep the semantics the same for floating point types, require= the=20 > same property for floating point types. > 2. std::cout -like implementation that uses a standard defined default= =20 > number of significant digits that is less than needed for non-lossy=20 > conversion. > 3. Use fixed decimal count. > 4. Print value as close to mathematically exact value as possible. > > Option 4 would for example imply hugely long string representations as=20 > demonstrated earlier so it's not viable option. > > Option 3 is the current one and is obviously out of question. > > In option 2 to_string() is allowed to create an approximation meaning tha= t=20 > to_string(x) =3D=3D to_string(y) for many different x and y thus changing= the=20 > semantics compared to integer implementation. This is an essential=20 > difference so there should be a very good reason for choosing this. The= =20 > argument is that there's none: prettiness and practicality arguments are= =20 > use case specific that can't be defined on standard level. > > With this reasoning the only reasonable choice would be option 1. Notes o= n=20 > it's implications: > > > - The string representation is allowed to be ambiguous. > - The string representation is not required to be mathematically=20 > exact: e.g. "1e300" is accepted because from_string(to_string(1e300)) = =3D=3D=20 > from_string("1e300") even though mathematically double(1e300) !=3D 1e3= 00. > - Resulting string may be long but even in worst case is much shorter= =20 > than what current to_string() prints for big values. For smaller value= s the=20 > resulting string may be shorter than with current to_string() because= =20 > redundant decimals can be shortened (e.g. "1.0" vs "1.000000") > > In this context the ideal could be formulated as follows: > > to_string() with floating point types shall create such a string=20 > representation that for related from_string() implementation such as=20 > stod(), from_string(to_string(x)) =3D=3D x for all x in floating point ty= pe=20 > domain. The string representation shall be portable across all=20 > implementations that use the same floating point implementation in the=20 > sense that reading the string in another implementation shall result to= =20 > value exactly the same as from which the string was created from. The=20 > string representations are not, however, required to be identical on such= =20 > implementations, but is it recommended to be shortest possible using=20 > similar scheme as defined in %g-family format in sprintf(). > > How to change the standard > ---------------------------------------- > > Big complication is that to_string() can't be changed without introducing= =20 > a (breaking) change. The change could be of various type: > > > 1. Behaviour change on runtime: may break any existing code using the= =20 > current definition. > 2. Compilation breaking or deprecation change: safer alternative=20 > implemented by API-change causing a compilation failure. > 3. Keep current behaviour but introduce parameters to make it possible= =20 > to get a better behaviour. > > > Not particularly nice choices, but the runtime behaviour change can be=20 > ruled out for starter leaving only two options. Breaking compilation or= =20 > deprecation is undesired, but preferred to having numerous programmers=20 > making bugs due to this for decades to come. Thus the proposal is to=20 > deprecate current to_string for floating point types and introduce a new= =20 > function with name to_string_f() or similar that behaves as described=20 > earlier. to_string_f() shall also take optional parameters that allows=20 > developer to fine tune the conversion like implemented e.g. in =20 > QString::number() [7].=20 > Options for fine tuning is important in the sense that making to_string_f= ()=20 > too simple and restricted will too quickly cause programmer to resort to= =20 > old and lacking alternatives, although at this point the purpose of=20 > to_string_f() is not to act as full featured sprintf-like formatting=20 > implementation. > > Early draft suggestion > ------------------------------- > > (float, long double and wstring omitted for clarity): > > std::string to_string_f(double d, int precision =3D=20 > special_value_requesting_shortest_nonlossy_representation, char format = =3D=20 > 'g') noexcept; > > Precision: Meaning depends on format-specifier as in sprintf in addition= =20 > to special items. > Format: Possible values: a, A, e, E, f, F, g, G as available for sprintf(= ). > > If precision or format is not within accepted range, to_string_f() return= s=20 > empty string. > > > Notes and open questions > -------------------------------------- > > -Usage examples and possible return values: > to_string_f(1.0) -> "1.0" > to_string_f(1.0, 10) -> "1.0" > to_string_f(1.0, 2, 'f') -> "1.00" > to_string_f(1.23456789e-9) -> "1.23456789e-9" > to_string_f(1.23456789e-9, 2) -> "1.2e-9" > to_string_f(1e300) -> "1e300" > > > -The essential question: is it feasible to implemented the=20 > from_string(to_string(x)) =3D=3D x requirement given all the possible flo= ating=20 > point implementations permitted by the C++ standard? If not, can the=20 > condition be fulfilled by not requiring it for some corner cases such as= =20 > NaN's (e.g. having only single NaN instead of multiple)? > > -Having int and char as parameters instead of string such as "%.3f" is=20 > chosen for safety and simplicity: eliminates the need to do string parsin= g=20 > and avoids possibility for errors in the users defined format string. > > -Shortest necessary string representation can't be acquired using=20 > sprintf() with maximal precision, but such implementation would be=20 > acceptable because shortest possible string is not required. This is chos= en=20 > to avoid the need to define "shortest possible" which is not expected to= =20 > have essential relevance for the usage of to_string_f(). Also the=20 > implementation effort from library implementers to guarantee the shortest= =20 > possible on all standard conforming C++ implementations might be=20 > unnecessarily high. > > -For portability of string representation, see the end of section 'Ideal' > > -Should the default value for precision be, say, -1 or an enum given the= =20 > conventions used for enums in std-namespace?=20 > > -Handling of out-of-range parameter values should be revised and defined.= =20 > The noexcept-property should however be preserved. > > -How to handle locale: implicitly use the same as sprintf or require that= =20 > the output is locale independent? Locale-dependency would cause portabili= ty=20 > issues so having locale-independent output would be desirable and in=20 > accordance with the design intention as to_string_f() is not intended to = do=20 > full featured locale aware formatting. > > -Would to_string_f() be appropriate name? > > > Details on examples > ----------------------------- > > Visual Basic (VS2015) > Dim aDouble As Double > aDouble =3D 0.00000000123456789 > Dim s As String =3D aDouble.ToString() > Console.WriteLine(s) > =20 > C# (VS2015) > double a =3D 1.23456789e-9; > String s =3D a.ToString(); > Console.Write(s); > =20 > boost::lexical_cast (boost 1.55) > auto s =3D boost::lexical_cast(1.23456789e-9); > std::cout << s; > =20 > Java (sun-jdk-8u51) > Double a =3D 1.23456789e-9; > String s =3D a.toString(); > System.out.println(s); > =20 > JavaScript (tested in Firefox 44) > var dA =3D 1.23456789e-9; > var sA =3D dA.toString(); > =20 > Qt (5.4) > QString s =3D QString::number(1.23456789e-9); > auto s2 =3D QVariant(1.23456789e-9).toString(); > > > References > ---------- > > [1] N1803: Simple Numeric Access.=20 > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1803.html > [2] N1982: Simple Numeric Access Revision 1.=20 > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1982.html > [3] N2408: Simple Numeric Access Revision 2.=20 > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2408.html > [4] How to convert a number to string and vice versa in C++.=20 > http://stackoverflow.com/questions/5290089/how-to-convert-a-number-to-str= ing-and-vice-versa-in-c > [5] How do I convert a double into a string in C++?.=20 > http://stackoverflow.com/questions/332111/how-do-i-convert-a-double-into-= a-string-in-c > [6] How do I convert an integer to a string?=20 > https://isocpp.org/wiki/faq/newbie#int-to-string > [7] QString::number(). http://doc.qt.io/qt-5/qstring.html#number-6. > =20 > --=20 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 e= mail 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/89c4ad80-fd43-4c00-87fd-8dc38ba50739%40isocpp.or= g. ------=_Part_180_1243467156.1456760871783 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Have you read the paper "How to print floating p= oint numbers accurately", e.g. from here: http://kurtstephens.com/files/p372-steele.pdf=
This seems to cover some of the problems you described.
<= br>On Sunday, February 28, 2016 at 2:06:29 PM UTC+1, u97...@gmail.com wrote= :
This post continues=C2= =A0Deprecate to_string() for flo= ating point types?

The original thread served it purpose and it = seemed more appropriate to start a new thread in this forum with a more pro= posal-like text for evaluation.

------------------------

Summ= ary
--------------

This document introduces the current behaviour= of std::to_string() pointing out it's fundamental problems with floati= ng point types and suggests a change to standard.

Introduction
--= ---------------

Converting numeric values to string is a common task= in contexts like UI's and human readable files and common enough to be= listed as a newbie question in C++ FAQ [6]. Before C++11 there was no clear choice fo= r conversion and some of the options suggested=C2=A0[4] [5] for the task we= re:
  1. std::ostringstream
  2. sprintf
  3. boost::lexical_ca= st
These have problems ranging from complexity and performance to = buffer handling hazards and external dependency. With std::to_string() the = general answer got easy: use std::to_string().

This, however, is not= a good answer for floating point types.

Floating point types are by= their nature trickier to deal with and it's harder to define what std:= :to_string() should do with floating point types.

The papers introdu= cing std::to_string()=C2=A0[1]=C2=A0[2]=C2= =A0[3] does not discus= s the purpose of std::to_string() (i.e. what problem it is intended to solv= e) and the current standard simply defines that return string of std::to_st= ring(double val) is identical to what sprintf(buf, "%f", val) wou= ld generate with sufficient buffer size buf.

This paper argues that = the decision is highly questionable, impractical and a source of bugs thus = suggesting a change to the standard.

Problem
------------

= In form of examples, the definition of std::to_string(double val) essential= ly as sprintf(buf, "%f", val) has the following implications:
=
  1. std::to_string(double(0)) =3D=3D "0.000000"
  2. std::= to_string(double(10000)) =3D=3D "10000.000000"
  3. std::to_st= ring(double(1e300)) =3D=3D=20 "10000000000000000525047602552044202487044685811081591549158= 54115511802457988908195786371375080447864043704443832883878176942523235360430575644792184786706982848387200926575803737830233= 79478809005936895323497079994508111903896764088007465274278014249= 4579258788820056842838115669472196386865459400540160.000000"=
  4. std::to_string(double(1e-9)) =3D=3D "0.000000"
= While it's not obvious how the conversion should work for floating poin= t types, it's hard to see that any acceptable implementation would have= behaviour as shown above. The problems are:
  • Redundant character= s from information preservation point of view (1, 2, 3, 4).
  • Unreada= ble output (3)
  • Failing to preserve even a single significant digit = (4).
While redundant decimal characters may be even desired in som= e use cases, the failure to preserve any significant digits is a serious is= sue especially as it is not a rare corner case issue but affects a big prop= ortion of the whole double domain. How big a proportion? At least in common= implementations of double, base 10 exponent can get values in range [-308,= 308]. All values where exponent is in range [-308, -8] are converted to &q= uot;0.000000" by std::to_string(). And given that readability of value= s with tens of digits is bad as demonstrated in example 3, the exponent ran= ge where std::to_string() creates acceptable string representation is quite= small although the good range may well cover the most frequent use cases.<= br>
For comparison, here's a short survey of related implementations= using double (or similar type) value 1.23456789e-9:

  • Visual = Basic (VS2015) ToString() : "1.23456789E-09"
  • C# (VS2015) = ToString() : "1.23456789E-09"
  • Java toString() : "1.2= 3456789E-9"
  • JavaScript toString() : "1.23456789e-9"<= /li>
  • boost::lexical_cast<std::string>(1.23456789e-9): "1= ..2345678899999999e-09"
  • Qt 5.4 QString::number(1.23456789e-9) := "1.23457e-09"
  • Qt 5.4 QVariant(1.23456789e-9).toStr= ing() : "1.23456789e-09"
  • C++ to_string(1.23456789e-9) : &= quot;0.000000"

8 implementations, in 5 the result is prec= ision-wise identical to value written to source code, in 1 the result is no= n-lossy but longer than source code version, in 1 the value is rounded to 6= significant digits and then there's std::to_string() that simply wipes= out all significant digits.

Ideal
-------

If std::to_stri= ng() for floating point types was created from scratch, the question would = be: what should it do? The following starting point is assumed:

    =
  • std::to_string() for integer types is defined and their implementations= are what they currently are.
  • to_string() is required to print (hum= an readable) decimal representation also of floating point values.

    • Some ideas:

    1. With integer types, the following condition= is true: x !=3D y <=3D>=20 to_string(x) !=3D to_string(y). Also for related from_string()=20 implementation such as stoul(), stoul(to_string(x)) =3D=3D x for all x of= =20 type T. In plain words this means that one can convert integer to string and read it back to get exactly the same item from which the string=20 representation was created from. To keep the semantics the same for=20 floating point types, require the same property for floating point=20 types.
    2. std::cout -like implementation that uses a standard defined = default number of significant digits that=20 is less than needed for non-lossy conversion.
    3. Use fixed decimal cou= nt.
    4. Print value as close to mathematically exact value as possible.=
    Option 4 would for example imply hugely long string representatio= ns as demonstrated earlier so it's not viable option.

    Option 3 i= s the current one and is obviously out of question.

    In option 2 to_s= tring() is allowed to create an approximation meaning that to_string(x) =3D= =3D to_string(y) for many different x and y thus changing the semantics com= pared to integer implementation. This is an essential difference so there s= hould be a very good reason for choosing this. The argument is that there&#= 39;s none: prettiness and practicality arguments are use case specific that= can't be defined on standard level.

    With this reasoning the onl= y reasonable choice would be option 1. Notes on it's implications:
    <= br>
    • The string representation is allowed to be ambiguous.
    • Th= e string representation is not required to be mathematically exact:=20 e.g. "1e300" is accepted because from_string(to_string(1e300)) = =3D=3D=20 from_string("1e300") even though mathematically double(1e300) != =3D 1e300.
    • Resulting string may be long but even in worst case is m= uch shorter than what current to_string() prints for big values. For smaller values the=20 resulting string may be shorter than with current to_string() because=20 redundant decimals can be shortened (e.g. "1.0" vs "1.000000= ")
    In this context the ideal could be formulated as follows:<= br>
    to_string() with floating point types shall create such a string rep= resentation that for related from_string() implementation such as stod(), f= rom_string(to_string(x)) =3D=3D x for all x in floating point type domain. = The string representation shall be portable across all implementations that= use the same floating point implementation in the sense that reading the s= tring in another implementation shall result to value exactly the same as f= rom which the string was created from. The string representations are not, = however, required to be identical on such implementations, but is it recomm= ended to be shortest possible using similar scheme as defined in %g-family = format in sprintf().

    How to change the standard
    -----------------= -----------------------

    Big complication is that to_string() ca= n't be changed without introducing a (breaking) change. The change coul= d be of various type:

    1. Behaviour change on runtime: may break= any existing code using the current definition.
    2. Compilation breaki= ng or deprecation change: safer alternative implemented by API-change causi= ng a compilation failure.
    3. Keep current behaviour but introduce para= meters to make it possible to get a better behaviour.

    Not part= icularly nice choices, but the runtime behaviour change can be ruled out fo= r starter leaving only two options. Breaking compilation or deprecation is = undesired, but preferred to having numerous programmers making bugs due to = this for decades to come. Thus the proposal is to deprecate current to_stri= ng for floating point types and introduce a new function with name to_strin= g_f() or similar that behaves as described earlier. to_string_f() shall als= o take optional parameters that allows developer to fine tune the conversio= n like implemented e.g. in=C2=A0 QSt= ring::number() [7]. Options for fine tuning is important in the sense t= hat making to_string_f() too simple and restricted will too quickly cause p= rogrammer to resort to old and lacking alternatives, although at this point= the purpose of to_string_f() is not to act as full featured sprintf-like f= ormatting implementation.

    Early draft suggestion
    ----------------= ---------------

    (float, long double and wstring omitted for cla= rity):

    std::string to_string_f(double d, int precision =3D special_v= alue_requesting_shortest_nonlossy_representation, char format =3D= 'g') noexcept;

    Precision: Meaning depends on format-specifi= er as in sprintf in addition to special items.
    Format: Possible values: = a, A, e, E, f, F, g, G as available for sprintf().

    If precision or f= ormat is not within accepted range, to_string_f() returns empty string.
    =

    Notes and open questions
    ----------------------------------= ----

    -Usage examples and possible return values:
    =C2=A0=C2=A0=C2= =A0 to_string_f(1.0) -> "1.0"
    =C2=A0=C2=A0=C2=A0 to_string_= f(1.0, 10) -> "1.0"
    =C2=A0=C2=A0=C2=A0 to_string_f(1.0, 2, = 'f') -> "1.00"
    =C2=A0=C2=A0=C2=A0 to_string_f(1.234= 56789e-9) -> "1.23456789e-9"
    =C2=A0=C2=A0=C2=A0 to_string_f= (1.23456789e-9, 2) -> "1.2e-9"
    =C2=A0=C2=A0=C2=A0 to_string= _f(1e300) -> "1e300"


    -The essential question: is it= feasible to implemented the from_string(to_string(x)) =3D=3D x requirement= given all the possible floating point implementations permitted by the C++= standard? If not, can the condition be fulfilled by not requiring it for s= ome corner cases such as NaN's (e.g. having only single NaN instead of = multiple)?

    -Having int and char as parameters instead of string such= as "%.3f" is chosen for safety and simplicity: eliminates the ne= ed to do string parsing and avoids possibility for errors in the users defi= ned format string.

    -Shortest necessary string representation can'= ;t be acquired using sprintf() with maximal precision, but such implementat= ion would be acceptable because shortest possible string is not required. T= his is chosen to avoid the need to define "shortest possible" whi= ch is not expected to have essential relevance for the usage of to_string_f= (). Also the implementation effort from library implementers to guarantee t= he shortest possible on all standard conforming C++ implementations might b= e unnecessarily high.

    -For portability of string representation, see= the end of section 'Ideal'

    -Should the default value for pr= ecision be, say, -1 or an enum given the conventions used for enums in std-= namespace?

    -Handling of out-of-range parameter values should be rev= ised and defined. The noexcept-property should however be preserved.
    -How to handle locale: implicitly use the same as sprintf or require that = the output is locale independent? Locale-dependency would cause portability= issues so having locale-independent output would be desirable and in accor= dance with the design intention as to_string_f() is not intended to do full= featured locale aware formatting.

    -Would to_string_f() be appropria= te name?


    Details on examples
    -----------------------------
    Visual Basic (VS2015)
    =C2=A0=C2=A0=C2=A0 Dim aDouble As Double
    = =C2=A0=C2=A0=C2=A0 aDouble =3D 0.00000000123456789
    =C2=A0=C2=A0=C2=A0 Di= m s As String =3D aDouble.ToString()
    =C2=A0=C2=A0=C2=A0 Console.WriteLin= e(s)
    =C2=A0=C2=A0=C2=A0
    C# (VS2015)
    =C2=A0=C2=A0=C2=A0 double a = =3D 1.23456789e-9;
    =C2=A0=C2=A0=C2=A0 String s =3D a.ToString();
    =C2= =A0=C2=A0=C2=A0 Console.Write(s);
    =C2=A0=C2=A0=C2=A0
    boost::lexical_= cast (boost 1.55)
    =C2=A0=C2=A0=C2=A0 auto s =3D boost::lexical_cast<s= td::string>(1.23456789e-9);
    =C2=A0=C2=A0=C2=A0 std::cout <<= ; s;
    =C2=A0=C2=A0=C2=A0
    Java (sun-jdk-8u51)
    =C2=A0=C2=A0=C2=A0 Do= uble a =3D 1.23456789e-9;
    =C2=A0=C2=A0=C2=A0 String s =3D a.toString();<= br>=C2=A0=C2=A0=C2=A0 System.out.println(s);
    =C2=A0=C2=A0=C2=A0
    Java= Script (tested in Firefox 44)
    =C2=A0=C2=A0=C2=A0 var dA =3D 1.23456789e-= 9;
    =C2=A0=C2=A0=C2=A0 var sA =3D dA.toString();
    =C2=A0=C2=A0=C2=A0 Qt (5.4)
    =C2=A0=C2=A0=C2=A0 QString s =3D QString::number(1.23456789e-= 9);
    =C2=A0=C2=A0=C2=A0 auto s2 =3D QVariant(1.23456789e-9).toS= tring();


    References
    ----------

    [1] N1803: Simple Numer= ic Access. http://www.open= -std.org/jtc1/sc22/wg21/docs/papers/2005/n1803.html
    [2] N1= 982: Simple Numeric Access Revision 1. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/= n1982.html
    [3] N2408: Simple Numeric Access Revision 2. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2408.html
    [4] How to convert a num= ber to string and vice versa in C++. http://stackoverflow.com/questions/5290089/how-to-conve= rt-a-number-to-string-and-vice-versa-in-c
    [5] How do I convert = a double into a string in C++?. http://stackoverflow.co= m/questions/332111/how-do-i-convert-a-double-into-a-string-i= n-c
    [6] How do I convert an integer to a string? https://isocpp.org/wiki/faq/n= ewbie#int-to-string
    [7] QString::number(). http://doc.qt.io/qt-5/qstring.html#number-6.
    =C2= =A0=C2=A0=C2=A0

--
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/89c4ad80-fd43-4c00-87fd-8dc38ba50739= %40isocpp.org.
------=_Part_180_1243467156.1456760871783-- ------=_Part_179_173916395.1456760871783-- .