Berry - converting a string to a number

[wjohn007]

Hello,

I thought the function 'number' would be a good candidate for the task.

But I found following

assert(number('abc')==0) # expected nil
assert(number('0')==0)

Thus, the function is useless for an unambiguous conversion.

Are there better solutions ?

John

[s-hadinger]

If I understand well you would it to return nil if it's not a number?

What about number('12a'). Should it be 12 or nil?

[s-hadinger]

Great

[sfromis]

For simple cases, with the input already a string without leading zeros, or trailing decimal zeros, a simpler version would be
if value == str(number(value))

[wjohn007]

once again, this relates to all to-number conversion functions in berry: (number,int,real)
according documentation:

"If it is a string, try to convert the string to an integer in decimal. Other types return nil."

Fact: number("abc") returns 0
number("0") returns 0

I would expect a nil if conversion is not possible.
Documentation is here unclear, because a not convertible string returns the number 0, what is ambigous.

toNumber, toReal methods would be very helpful, but not this implementation.

[sfromis]

As I read the docs, what you quoted from (int function) is pretty clear about nil just being when the type of the argument is neither a number nor a string, except when the class has a toint() method to convert. Thus, the meaning of nil is that it did not even know how to start converting to an integer.
m={} print(int(m)) gives nil, as expected.

Bad data is a pretty different use case, and I see how invalid data resulting in 0 is not great. If it simply returned the input when failing, you could use the type() function to check the result. But.... breaking changes and all that.

The value undefined might make sense; this is a module meant for usage with virtual members, where returning undefined is different from having a nil value. However, I'm not so sure that this would be "better" than nil from the string parsing functions. I was looking for a NaN value like some languages have for not-a-number, but did not find such.

[wjohn007]

I understand the problem with the breaking changes.
But it would be possible to extend berry with a new method toNumber(), which delivers clear results.
That would be an item on my wish list.
Despite everything: Berry is great.