KeithRB:
isNan() is not what you want. That only checks to see if it is the special value you get when a math operation goes bad like dividing by zero.
include ctype.h and use isdigit() on all the characters in the string. If one of them is a digit, you have a number.
read character c:
If c is whitespace: get next character
if c is +, - or . (decimal point): get next character
if c is digit: stop it is a number
if c is something else: stop it is not a number
if there are no more characters: stop, it is not a number
I suppose you could use atof() although the 0.0 return value seems ambiguous. You could validate the string before the conversion if you like - it would be a relatively simple parsing job, or you could use a regular expression to do it (I seem to remember somebody posted a regex library for Arduino recently).
PeterH:
I suppose you could use atof() although the 0.0 return value seems ambiguous. You could validate the string before the conversion if you like - it would be a relatively simple parsing job, or you could use a regular expression to do it (I seem to remember somebody posted a regex library for Arduino recently).
The problem here is not the conversion, but the validation.
.toFloat() is working just fine on 1.5.5. But i think it should return a "NAN" or similiar if the input is not a valid number-(in string).
It is the simplest solution. The real one is much harder. It works for his two test cases, which is all I am asked to do as a programmer. 8^)
It's a good thing you don't work for me, then. Programmers are NOT supposed to handle just the identified test cases. They are supposed to anticipate additional test cases.
Checking that all the characters in the String (or string) are '-', '.', >= '0' and <= '9', or 'e' or 'E' will work for all inputs. Developing a function that tested for strings that are valid as floats would be easy. Developing a function that tested for strings that are valid as ints would be easy. Developing a function that tested for strings that are valid as numbers would be easy. Knowing which function to develop is harder, but not by much.
What I had in mind was that the strings may be delimited, perhaps by a carriage return/linefeed or some other character. In which case you may be able to be certain that the string you are reading is numeric or not by virtue of its position in the overall string being received. What does the overall string that you receive consist of ?
It's a good thing you don't work for me, then. Programmers are NOT supposed to handle just the identified test cases. They are supposed to anticipate additional test cases.
You did see the smiley, right?
In this case, since we are just looking for a "parseable" number, E's don't matter, since you will not encounter an E before a digit.