Why does std.conv not contain methods for string to floating point conversions?

Where in Phobos is this functionality?

"imr1984" <imr1984_member@pathlink.com> wrote in message news:d3jq4r$28g6$1@digitaldaemon.com...
> Why does std.conv not contain methods for string to floating point conversions?
>
> Where in Phobos is this functionality?

std.string has all the toString() functions.  But I agree with you, the toString functions would make more sense to be in std.conv.

"imr1984" <imr1984_member@pathlink.com> wrote in message news:d3jq4r$28g6$1@digitaldaemon.com...
> Why does std.conv not contain methods for string to floating point conversions?
>
> Where in Phobos is this functionality?

std.math2 has atof. Strangly enough this was the topic of a recent post by David L Davis for ConvExt.d. Scroll back a few days to see his thread.

"Jarrett Billingsley" <kb3ctd2@yahoo.com> wrote in message news:d3jrfp$2a78$1@digitaldaemon.com...
>
> "imr1984" <imr1984_member@pathlink.com> wrote in message news:d3jq4r$28g6$1@digitaldaemon.com...
>> Why does std.conv not contain methods for string to floating point conversions?
>>
>> Where in Phobos is this functionality?
>
> std.string has all the toString() functions.  But I agree with you, the toString functions would make more sense to be in std.conv.

Oh, I'm an idiot.  I thought you wrote floating point to string conversions. A D-compatible atof() is also found in std.string.  It's in the form real atof(char[] s).

"Jarrett Billingsley" <kb3ctd2@yahoo.com> wrote
>
> "imr1984" <imr1984_member@pathlink.com> wrote in message news:d3jq4r$28g6$1@digitaldaemon.com...
> > Why does std.conv not contain methods for string to floating point conversions?
> >
> > Where in Phobos is this functionality?
>
> std.string has all the toString() functions.  But I agree with you, the toString functions would make more sense to be in std.conv.

I agree. Mango, for example, has a dedicated package called mango.format, which handles the formatting and parsing of various types, including floating-point (as a bonus it includes David Gay's code as an option, which provides extensive and thorough coverage of conversion between text and floating-point representations).

In article <d3jrl5$2ab2$1@digitaldaemon.com>, Ben Hinkle says...
>
>
>"imr1984" <imr1984_member@pathlink.com> wrote in message news:d3jq4r$28g6$1@digitaldaemon.com...
>> Why does std.conv not contain methods for string to floating point conversions?
>>
>> Where in Phobos is this functionality?
>
>std.math2 has atof. Strangly enough this was the topic of a recent post by David L Davis for ConvExt.d. Scroll back a few days to see his thread.
>
>

Currently I'm applying changes to the code to make it more compatible with the std.conv code as you suggested in the "convext.d thread." And adding in the overflow checking, if possible, cause the floating-point datatypes are very hard to do compare against one another.

A funny side note:
--------------------
The reason I when for using both the std.math2 functions atof() and feq(), instead the using std.string.atof() and std.math.mfeq() functions. Was the fact that when I wrote the code in early November 2004 with dmd v0.105, std.string.atof() only handled float and double but not the real datatype. With std.math.mfeq() I wanted to use it for comparing floating-points, but it was defined as a private function...in which I asked Walter nicely if he would make it public function, in which he said it wasn't good enough for general use. So at this point when I found std.math2 and the two needed functions, otherwise I think I would've stopped my work on the project.

Also today I started looking at the std.string.atof() function again and noticed to my surprise that it now handles real datatype..."HEY! When did that happen?"

The following is what I discovered:

----------------------------------------
std.string in dmd from v0.105 and v0.106
----------------------------------------
extern (C)
{
// Functions from the C library.
double atof(char *);
}

---------------------------------------
std.string in dmd from v0.107 to v0.119
---------------------------------------
real atof(char[] s)
{
// BUG: should implement atold()
return std.c.stdlib.atof(toStringz(s));
}

--------------------------
std.string in dmd v0.120.2
--------------------------
extern (C)
{
// Functions from the C library.
real strtold(char*, char**);
}

/*************************************
* Convert string to float
*/
real atof(char[] s)
{   char* endptr;
real result;

result = strtold(toStringz(s), &endptr);
return result;
}

So it's now clear to me, that Walter has been busy in the area! I can't wait to have a complete std.conv that mirrors the toString() functions for converting from a string (char[]) back into the floating-point datatypes.

David L.

-------------------------------------------------------------------
"Dare to reach for the Stars...Dare to Dream, Build, and Achieve!"

"David L. Davis" <SpottedTiger@yahoo.com> wrote in message news:d3k94m$2lr5$1@digitaldaemon.com...
> In article <d3jrl5$2ab2$1@digitaldaemon.com>, Ben Hinkle says...
>>
>>
>>"imr1984" <imr1984_member@pathlink.com> wrote in message news:d3jq4r$28g6$1@digitaldaemon.com...
>>> Why does std.conv not contain methods for string to floating point conversions?
>>>
>>> Where in Phobos is this functionality?
>>
>>std.math2 has atof. Strangly enough this was the topic of a recent post by David L Davis for ConvExt.d. Scroll back a few days to see his thread.
>>
>>
>
> Currently I'm applying changes to the code to make it more compatible with
> the
> std.conv code as you suggested in the "convext.d thread." And adding in
> the
> overflow checking, if possible, cause the floating-point datatypes are
> very hard
> to do compare against one another.

Hmm. I haven't thought about it too much but I thought the overflow checking was for handling strings with a number with, say, a huge exponent that floating pt numbers couldn't represent and instead puts in real.max or whatever. Which floats are being compared? I don't know the algorithm used by toInt and friends or by toFloat.

> A funny side note:
> --------------------
> The reason I when for using both the std.math2 functions atof() and feq(),
> instead the using std.string.atof() and std.math.mfeq() functions. Was the
> fact
> that when I wrote the code in early November 2004 with dmd v0.105,
> std.string.atof() only handled float and double but not the real datatype.
> With
> std.math.mfeq() I wanted to use it for comparing floating-points, but it
> was
> defined as a private function...in which I asked Walter nicely if he would
> make
> it public function, in which he said it wasn't good enough for general
> use. So
> at this point when I found std.math2 and the two needed functions,
> otherwise I
> think I would've stopped my work on the project.
>
> Also today I started looking at the std.string.atof() function again and
> noticed
> to my surprise that it now handles real datatype..."HEY! When did that
> happen?"
>
> The following is what I discovered:
>
> ----------------------------------------
> std.string in dmd from v0.105 and v0.106
> ----------------------------------------
> extern (C)
> {
> // Functions from the C library.
> double atof(char *);
> }
>
> ---------------------------------------
> std.string in dmd from v0.107 to v0.119
> ---------------------------------------
> real atof(char[] s)
> {
> // BUG: should implement atold()
> return std.c.stdlib.atof(toStringz(s));
> }
>
> --------------------------
> std.string in dmd v0.120.2
> --------------------------
> extern (C)
> {
> // Functions from the C library.
> real strtold(char*, char**);
> }
>
> /*************************************
> * Convert string to float
> */
> real atof(char[] s)
> {   char* endptr;
> real result;
>
> result = strtold(toStringz(s), &endptr);
> return result;
> }
>
> So it's now clear to me, that Walter has been busy in the area! I can't
> wait to
> have a complete std.conv that mirrors the toString() functions for
> converting
> from a string (char[]) back into the floating-point datatypes.

interesting... and here std.math2 has probably been sitting idle all that time, too. How does std.string.atof compare to std.math2.atof? Have you compared them?

In article <d3kieb$2rog$1@digitaldaemon.com>, Ben Hinkle says...
>
>
>Hmm. I haven't thought about it too much but I thought the overflow checking was for handling strings with a number with, say, a huge exponent that floating pt numbers couldn't represent and instead puts in real.max or whatever. Which floats are being compared? I don't know the algorithm used by toInt and friends or by toFloat.
>

Because the std.math2.atof( char[] s ) and std.string.atof( char[] s ) functions both return a real value, it becomes important to test for an overflow for float, ifloat, cfloat, double, idouble, and cdouble datatypes, because the converted floating-point could be in the real datatype's range, but not theirs...thus it should be an error.

>
>interesting... and here std.math2 has probably been sitting idle all that time, too. How does std.string.atof compare to std.math2.atof? Have you compared them?
>

Using the example code below focusing mainly on the real datatype, it would
appear, when using the %a that the std.math2.atof() (written totally in D by the
way) is a bit better than the new improved std.string.atof() (which calls a C
function to do the work). But otherwise they do get the same result in
std.string.toString( real ) and when being printed out with a %g in writefln()
function. I'll have to test the others over the next few days to see if
everything still matches up. :)

# private import std.stdio;
# private import std.string;
# private import std.math2;
#
# // to avoid std.math2.toString( real ) crashing
# // into std.string.toString( real )
# alias std.string.toString toString;
#
# int main()
# {
#     real r1;
#     real r2;
#
#     //real.min=3.3621e-4932, real.max=1.18973e+4932
#     writefln( "real.min=%g, real.max=%g", real.min, real.max );
#
#     writefln();
#     writefln( "toString(\"3.3621e-4932\")=\"%s\",
#                toString(\"1.18973e+4932\")=\"%s\"",
#                toString( "3.3621e-4932" ),
#                std.string.toString( "1.18973e+4932" ) );
#
#     writefln( "toString(real.min)=\"%s\", toString(real.max)=\"%s\"",
#                toString( real.min ), toString( real.max ) );
#     writefln();
#
#     r1 = std.string.atof( toString( real.min ) );
#     r2 = std.string.atof( toString( real.max ) );
#     writefln( "std.string.atof() r1.min=%a, r2.max=%a", r1, r2 );
#     writefln( "std.string.atof() r1.min=%g, r2.max=%g", r1, r2 );
#     writefln();
#
#     r1 = std.math2.atof( toString( real.min ) );
#     r2 = std.math2.atof( toString( real.max ) );
#     writefln( "std.math2.atof()  r1.min=%a, r2.max=%a", r1, r2 );
#     writefln( "std.math2.atof()  r1.min=%g, r2.max=%g", r1, r2 );
#
#     return 0;
# }

Output:
-------
C:\dmd>dmd floattest.d
C:\dmd\bin\..\..\dm\bin\link.exe floattest,,,user32+kernel32/noi;

C:\dmd>floattest.d

C:\dmd>floattest
real.min=3.3621e-4932, real.max=1.18973e+4932

toString("3.3621e-4932")="3.3621e-4932",
toString("1.18973e+4932")="1.18973e+4932"

toString(real.min)="3.3621e-4932", toString(real.max)="1.18973e+4932"

std.string.atof() r1.min=0x1.ffffe0a1926d0c4cp-16384,
r2.max=0x1.ffffd5d36dc5106p+16383
std.string.atof() r1.min=3.3621e-4932, r2.max=1.18973e+4932

std.math2.atof()  r1.min=0x1.ffffe0a1926cf074p-16384,
r2.max=0x1.ffffd5d36dc52c4p+16383
std.math2.atof()  r1.min=3.3621e-4932, r2.max=1.18973e+4932

C:\dmd>

David L.

-------------------------------------------------------------------
"Dare to reach for the Stars...Dare to Dream, Build, and Achieve!"

Again, this is a point for implicit imports.  If a person knows what they need to do, and can find a common function that can do it, then it shouldn't matter whether or not they know what module the function is in.  They should simply be able to use it.

The only times a module should "need" to be explicitly implied is if it's not in the implicit import list, or if the version that's wanted is in a module other than the one that the implicit import list specifies.  In fact, it would even be possible for implicit importing to be "version" sensative, and not implicitly import a module if the list dpecifies that the called function, object, or whatever, doesn't work in the version specified in the last "version()" statement.

TZ

"Ben Hinkle" <bhinkle@mathworks.com> wrote in message news:d3jrl5$2ab2$1@digitaldaemon.com...
>
> "imr1984" <imr1984_member@pathlink.com> wrote in message news:d3jq4r$28g6$1@digitaldaemon.com...
> > Why does std.conv not contain methods for string to floating point conversions?
> >
> > Where in Phobos is this functionality?
>
> std.math2 has atof. Strangly enough this was the topic of a recent post by David L Davis for ConvExt.d. Scroll back a few days to see his thread.
>
>

TechnoZeus wrote:
> Again, this is a point for implicit imports.  If a person knows what they need to do, and can find a common function that can do it, then it shouldn't matter whether or not they know what module the function is in.  They should simply be able to use it.
> 
> The only times a module should "need" to be explicitly implied is if it's not in the implicit import list, or if the version that's wanted is in a module other than the one that the implicit import list specifies.  In fact, it would even be possible for implicit importing to be "version" sensative, and not implicitly import a module if the list dpecifies that the called function, object, or whatever, doesn't work in the version specified in the last "version()" statement.
> 
> TZ

There is absolutely no way that Walter is going to add implicit imports (other than object.d) to D. Here's how I know: many people have asked to allow "import pkg.*" to import all of a directory and he's shown no sign of budging on even that. What you seem to be asking for a hidden "import *" at the beginning of every program. The reason why he hasn't implemented "import pkg.*" isn't because it's hard to implement (I'm fairly certain it'd be quite easy to implement). He hasn't implemented it because he thinks it'd lead to more pesky, weird, and unpredictable bugs in D programs. (FWIW, I think he's right.)

If you really want to have "implicit imports", I think that you can get pretty close using some of D's current functionality (assuming you actually are interesting in using D).

You can create a file (let's call it "all.d") with this content:

public import
std.array,
std.asserterror,
std.base64,
std.compiler,
std.conv,
std.ctype,
std.date,
std.dateparse,
std.file,
std.format,
std.gc
/* etc. */
;

(If this sounds like a lot of typing it'd be pretty easy to write a program to search through the file system automatically creating "all.d".)

Then at the beginning of every program you write, you would simply add "import all.d". One line of code at the top of your program shouldn't be too high of a price to achieve nearly implicit importation.

Nonetheless, there's nothing I can do to prevent you from continuing to ask for implicit importing. If you want it, you want it. I'm just not sure what you find appealing about D, since this kind of legerdemain seems antithetical to the D way of thinking. I'm not telling you you're wrong to want to program this way (how you want to program is your decision), but I'm thinking there might be a programming language that is closer to your goals than D is.

-- 
jcc7
http://jcc_7.tripod.com/d/