Talk:Determine if a string is numeric: Difference between revisions
Talk:Determine if a string is numeric (view source)
Revision as of 17:45, 15 September 2021
, 2 years ago→Assembly implementation is harder than I thought
No edit summary |
Puppydrum64 (talk | contribs) |
||
| (9 intermediate revisions by 8 users not shown) | |||
Line 1:
== Subtle bug in the C example? ==
Line 38 ⟶ 34:
For those who don't know VB: How exactly is IsNumeric defined?
For example: Is leading/trailing whitespace allowed (i.e. " 123" or "123 ")?
Does it also accept
What about thousands separators (e.g. "10,000")? Is that locale-dependent?
Are numbers in other bases (e.g. hexadecimal) allowed (assuming VB supports them otherwise)?
Line 98 ⟶ 94:
In the past, I have assumed that the number system was decimal and accepted only digits, an optional leading hyphen, and a single decimal point. With that logic, "a numeric string is a string consisting only of digits, an optional leading hyphen and an optional single decimal point". Maybe this is the way to go. Note that in some locales, numeric strings fall outside of this definition, so this also needs to be considered. Under that definition strings containing whitespace return a result of "not numeric", but this does not matter in practice, because code that makes use of the result can easily trim whitespace from the string before feeding it to the evaluator (I have done this before and it has worked well for me). --[[User:Markhobley|Markhobley]] 21:38, 4 June 2011 (UTC)
: If a leading hyphen (minus sign) is OK, why not a leading plus sign as well (but not both, of course)? "A leading hyphen" was mentioned, but I assume you meant a ''single'' leading hyphen (minus sign). However, some languages allow multiple leading signs. -- [[User:Gerard Schildberger|Gerard Schildberger]] ([[User talk:Gerard Schildberger|talk]]) 17:57, 28 September 2013 (UTC)
== Objective-C question ==
Line 118 ⟶ 116:
==Mathematica seems lean?==
It just seems to me that Mathematica should have ways to recognize many more number types than the current entry seems to suggest. compare the E, Forth and Python entries. --[[User:Paddy3118|Paddy3118]] 14:54, 26 August 2010 (UTC)
== Second MATLAB solution might have a problem ==
I don't know if you want to call it "incorrect", but I think the second MATLAB solution would call "...." numeric. I don't see any way of determining that there is only one decimal point in the string. --[[User:Mwn3d|Mwn3d]] 15:59, 2 February 2012 (UTC)
== Problem with the VB.net example ==
The IsNumeric call will not always return a correct answer. Try "1234+" - IsNumeric will return True. Then pass this same value as an argument to Convert.ToDouble: it will fail "unhandled exception". There's no option but to loop thru the String character by character and check that each one is within range. --[[User:LazyZee|LazyZee]] 17:59, 19 October 2012 (UTC)
== R ==
The solution will not work correctly if the string contains "NA" (not a number). But NA can be used in numeric calculations. --[[User:Sigbert|Sigbert]] ([[User talk:Sigbert|talk]]) 13:01, 16 February 2015 (UTC)
== AWK code is wrong ==
<pre>
awk 'BEGIN { x = "01"; print x == x+0 }'
0
awk 'BEGIN { x = "+1"; print x == x+0 }'
0
awk 'BEGIN { x = "1x"; print x == x+0 }'
0
</pre>
But
<pre>
awk 'BEGIN { x = "1x"; print x+1 }'
2
</pre>
== Assembly implementation is harder than I thought==
The way I see it, the code will need to do the following:
Read the first character.
* If it's a null terminator, the program ends and the string is not numeric.
* If it's a minus sign, that's valid and so we can continue
* If it's a decimal point, that's valid and we can continue. However, the presence of a decimal point must be recorded. If the string contains a second decimal point it stops being numeric.
* If it's not a number, at this point the string is not numeric. Otherwise continue.
Read the second character.
* If it's the terminator, the string is numeric if the first character was a numeral. If the first character was a minus sign or decimal point, the string is not numeric.
* If the second character is a numeral, continue.
* If the second character is a decimal point, continue if we haven't seen one already. If there is more than one decimal point the string is not numeric.
* If the second character is anything else, the string is not numeric.
Loop through the rest of the string.
* If we encounter the terminator, the string is numeric.
* If we encounter a numeral, continue.
* If we encounter a second decimal point, the string is not numeric.
* If we encounter anything besides a numeral, the null terminator, or the first occurrence of a decimal point, the string is not numeric.
I've attempted this in both 8086 and z80 but it ends up looking like spaghetti no matter what I do.
: @[[User: Puppydrum64]]: Uhm, is this task even applicable for assembly? I don’t thinks so. You know, depending on the assembler used there are ''several'' ways to write numeric literals. In NASM, for instance, I can write <tt>0b0110_1101</tt>. There simply isn’t ''a/the'' programming language “8086 assembly” ''defining'' how to write numeric literals. What you are attempting to do, though, is rather writing an assembly function that accepts a null-terminated string that represents a valid numeric literal ''in C'' (and many ''other'' programming languages), but not “8086 assembly”, you know what I mean? [[User:Root|Root]] ([[User talk:Root|talk]]) 18:10, 20 August 2021 (UTC)
I get what you mean. I figured at least attempting something that represents a valid numeric literal in higher-level languages was as close as I could get. Throwing in the towel and just saying "This is assembly, there are no rules" would disqualify it from almost everything. --[[User:Puppydrum64|Puppydrum64]] ([[User talk:Puppydrum64|talk]]) 17:45, 15 September 2021 (UTC)
| |||