View mode: basic / threaded / horizontal-split · Log in · Help
April 13, 2005
std.conv
Why does std.conv not contain methods for string to floating point conversions?

Where in Phobos is this functionality?
April 13, 2005
Re: 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.string has all the toString() functions.  But I agree with you, the 
toString functions would make more sense to be in std.conv.
April 13, 2005
Re: 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.
April 13, 2005
Re: std.conv
"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).
April 13, 2005
Re: std.conv
"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).
April 13, 2005
Re: std.conv
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!"
April 14, 2005
Re: std.conv
"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?
April 14, 2005
Re: std.conv
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!"
April 14, 2005
Re: std.conv
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.
>
>
April 17, 2005
implicit import (Re: std.conv)
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/
« First   ‹ Prev
1 2
Top | Discussion index | About this forum | D home