www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 4673] New: Bug in std.string (isNumeric)

reply d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=4673

           Summary: Bug in std.string (isNumeric)
           Product: D
           Version: unspecified
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Phobos
        AssignedTo: nobody puremagic.com
        ReportedBy: petitv.isat gmail.com



CEST ---
Created an attachment (id=725)
Source code (from description)

Hi. I was doing some recursivity with D and I probably found a bug with the
isNumeric() function.


Here's the source code (also in attach) :

import std.stdio;
import std.string;
import std.conv;

int main(string[] args)
{
    if(args.length > 1)
    {
        int number;

        foreach(item; args)
        {
            if(isNumeric(item))
            {
                number = parse!(uint)(item);    // seems to have a bug with 'L'
and 'F' values
                writeln("Facto of ", number, " is ", facto(number));
            }
        }
    }
    else
    {
        writeln("You must specified a number.");
    }
    return 0;
}


uint facto(uint number)
{
    uint result;

    if(number <= 1)
    {
        result = 1;
    }
    else
    {
        result = number * facto(number - 1);
    }
    return result;
}




See the result when running the compiled executables with these args : 5 8 A F


facto 5 8 A F


Facto of 5 is 120
Facto of 8 is 40320
std.conv.ConError : std.conv(1070) : Can't convert 'F' of type string to type
uint


It seems that "F" and "L" alone are recognized as Float and Long specifier but
... there's no digit. I accept that 0F, 1L are digits but F and L alone are
not.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Aug 18 2010
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=4673


bearophile_hugs eml.cc changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bearophile_hugs eml.cc



This reduced case shows that parse() doesn't accept "F" or "L", so I don't see
the problem yet:


import std.conv;
void main() {
    int n1 = parse!uint("F");
    int n2 = parse!uint("L");
}

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Aug 18 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=4673




CEST ---


 This reduced case shows that parse() doesn't accept "F" or "L", so I don't see
 the problem yet:
 
 
 import std.conv;
 void main() {
     int n1 = parse!uint("F");
     int n2 = parse!uint("L");
 }


Some changes in your reduced case :

import std.conv;
import std.string;

void main() {
    if(isNumeric("F"))    // isNumeric("F") return True : since when "F" is a
numeric ?
    {
        int n1 = parse!uint("F");
    }
    if(isNumeric("L"))    // same for "L"
    {
        int n2 = parse!uint("L");
    }
    if(isNumeric("U"))    // same here ...
    {
        uint n3 = parse!uint("U");
    }
}

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Aug 18 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=4673




You are right, my reduced version was useless, this shows the problem:

import std.string: isNumeric;
void main() {
    assert(isNumeric("F"));
    assert(isNumeric("L"));
    assert(isNumeric("U"));
}

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Aug 18 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=4673


kennytm gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kennytm gmail.com





 You are right, my reduced version was useless, this shows the problem:
 
 import std.string: isNumeric;
 void main() {
     assert(isNumeric("F"));
     assert(isNumeric("L"));
     assert(isNumeric("U"));
 }


The following strings are also wrongly classified as numeric:

    import std.string;
    void main () {
      assert(isNumeric("i"));
      assert(isNumeric("fi"));
      assert(isNumeric("ul"));
      assert(isNumeric("li"));

      assert(isNumeric("."));
      assert(isNumeric("-"));
      assert(isNumeric("+"));
      assert(isNumeric("e-"));
      assert(isNumeric("e+"));
      assert(isNumeric(".f"));
      assert(isNumeric("e+f"));
    }

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Aug 18 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=4673




CEST ---
Created an attachment (id=733)
Maybe a patch which works.

Well this is way to improve the current isNumeric function.

It works well for these kinds of numerics :

(+/-) 1, 1L, 1UL, 1i, 1Fi, 1Li, 1F
1.55
1e+52
1_500_250

nan, nani, nan+nani


(+/-) inf


At least, this patch correct bugs found in the std.isNumeric function.

Sure we can (should !) improve it but at least it works (except for numerics
like .5e-52 but 0.5e-52 works)

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Aug 20 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=4673




Should complex literals ("3.4+5.6i") _still_ be considered numeric? As the
built-in complex types are scheduled for deprecation...

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Aug 20 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=4673


Jonathan M Davis <jmdavisProg gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jmdavisProg gmail.com



14:42:21 PDT ---
I though that they were doing the same with complex numbers that they did with
associative arrays, which was to remove it from the language itself but have
the compiler use a library solution for it (kind of like it using the object
module with Object in it rather than just knowing the definition). So, the
syntax would be the same, but how it would be dealt with internally would be
different. I could be wrong on that though.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Aug 20 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=4673


Petit Vincent <petitv.isat gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------

           obsolete|                            |



CEST ---
Created an attachment (id=740)
Improvements of the proposed patch

Well, I checked the lexical page about D2 and it seems that something like
1_2_3_4_5_._5_4e-5_2_ is a numeric, so I decided to make some changes to the
regex to allow this kind of numerics.

But I wonder, should we consider hex things like 0xFFF as numerics or should we
have to make another function like "isHexadecimal" ?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Aug 25 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=4673






 Created an attachment (id=740) [details]
 Improvements of the proposed patch
 
 Well, I checked the lexical page about D2 and it seems that something like
 1_2_3_4_5_._5_4e-5_2_ is a numeric, so I decided to make some changes to the
 regex to allow this kind of numerics.
 
 But I wonder, should we consider hex things like 0xFFF as numerics or should we
 have to make another function like "isHexadecimal" ?


The current isNumeric function also considered "123,456,789" numeric (with the
bAllowSep parameter set to true). May be there should be another function or
switch that handles "human-readable numeric string" and "number literals in D
syntax" differently.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Aug 25 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=4673


Andrei Alexandrescu <andrei metalanguage.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
                 CC|                            |andrei metalanguage.com
         AssignedTo|nobody puremagic.com        |andrei metalanguage.com


-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 09 2011
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=4673


Rob T <alanb ucora.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |alanb ucora.com



isNumeric still thinks strings containing only "-" "+" and "." are numeric.

Here is a related bug report with additional thoughts and a suggestion that the
conversion library should add a function to check if a given conversion will
succeed or not.
http://d.puremagic.com/issues/show_bug.cgi?id=3610

If isNumeric won't be fixed, then it should be depreciated rather than keep it
broken in the library. 

--rt

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Sep 03 2013