Conversion from string to number.

[jpm]

I prefer Number() return only if a valid number as

[sign] digits [.[digits]] [ {d | D | e | E }[sign] digits]

perhaps with leading and trailing spaces

so the answer is Number("5abc") return 0

as it is a function it can set the @error in this case.

In fact if we want to have consistency with

If "0abc" = 0 Then

and

If Number("0abc") = 0 Then

The return of 0 is not so good as AutoIt is converting string to number before comparison with Numbers.

It could have been the other way around convert number to string when comparing to string but is not.

I will suggest Number() return a indeterminate float number as 0.0/0.0 -> -1.#IND

Comparison with such return value must always fail unless the 2 values are equal to #1.#IND

If -1.#IND is returned and such comparison is done, there is no need to set @error

The only remaining question is

If Number("0abc") = "5abc" Then

will be true but well it is the designer responsability to do the comparison according to the type of values.

Edited October 25, 2009 by jpm
add more information

[Jon]

The return of 0 is not so good as AutoIt is converting string to number before comparison with Numbers.

It could have been the other way around convert number to string when comparing to string but is not.

It doesn't matter which way you choose, something will always work not as expected. If you forced autoit to compare a number and a string as strings then this would be false:

0.123 = ".123"

That's just as bad, if not worse than the current behavior. This is the reason that we have the String/Number casts to workaround these situations.

How things are compared is slightly off-topic anyway. The issue is that Number/IsNumber and implicit string to number conversions currently don't work the same way and that is wrong. Let's fix that first and then start a new argument over comparison logic.

Edit: The indeterminate number thing is - to put it bluntly - utterly crazy. That's not going to happen.

Edited October 25, 2009 by Jon

[jpm]

I agree except the crazy is not so crazy. Just think about it.

That solving almost all situation We will see what comparison thread will say.

Let fix first the Number/IsNumber issue.

[Nutster]

I am thinking that we may need two functions. Number("5abc") = 0, which is the same as doing the implicit conversion. But there are times we want to extract the digits as a number, so something like Val("5abc") = 5. Note that this would not count as a casting function, but maybe a function in the same way as Asc or Chr, convertion.

Func _Number($x)
    If StringIsInt($x) = 0 And StringIsFloat($x) = 0 Then
        return 0
    Else
        return Number($x)
    EndIf
EndFunc

How come I find it easier to explain things in code instead of English?

Edited October 25, 2009 by Nutster
Add more detail and clarity (I hope)

[GerrOrneq]

This poll is to gauge what user expectations are for the conversion from a string to a number when the string starts with numbers but also contains non-numbers. I do not care about what the current behavior is, I am only interested in what the expected behavior from you in the community is.

Edit: The poll will be open for a 3 or 4 days.

Hi, this may be a moote point and/or too late to count in the outcome of the poll.

I have just voted that I expect it should return 5 as per the example (with a caveat), my reasoning is as follows:

There are times when it is advantageous to have the actual number contained in the string returned instead of a zero for example if you were adding a list of weights but some were entered/available with the "mg" string part e.g. 15mg or 23.6mg then the value would be a valid one and would prevent having to do extra coding to then get the value if the default action was to return zero.

Plus just getting a zero returned would I imagine lead to hard to detect errors if the input was mostly proper numerical strings and had occassional alphanumerics giving a zero that may be misleading or downright inaccurate.

I would also expect that @error would be set to X [a non-zero value - indicating that the actual number is derived from a mixed alphanumeric string.]

Sample Data: (In this case assume that all your data is expected to be milligrams)

5mg

15.5

996mg

1E3

1E3MP3

0.56something4nothing

2^2

R45hw

0.0.0.0

For example (in pseudocode)

NumVar = Number(DataString)

if @error<>0 then

;The value derived was from a mixed alphanumeric string

;either accept the value and do nothing or process it in some way

;maybe just informing the user or aborting gracefully with an explaination.

;

;Say you wanted it to behave as though number() returned 0 then

NumVar = 0

@error = 0

endif

display NumVar - [Displayed value = 5 (for string = 5mg)]

Using the other values in the sample data then the displayed values from the pseudocode would be:

SampleData

15.5

996mg

1E3

1E3MP3

0.56something4nothing

2^2

R45hw

0.0.0.0

Displayed Data

15.5 (@error = 0)

996 (@error = X)

1000 (@error = X)

1000 (@error = X)

0.56 (@error = X)

4 (@error = X)

0 (@error = Y, Where Y = code for invalid conversion)

0 (@error = X)

As you can see the @error value is crucial (but being a function then setting it should Not be a problem)and allows the best of both worlds, one for those that prefer 0 returned and also allows the returning of the actual parsed value from an alphanumeric string for those that want to use that method.

This will mean that scripting for both situations is simple, just add the if @error<>0 and mission accomplished.

All without major hassles to changing the AutoIt source code.

So to summarise:

Return the actual numerical value of the string as parsed (left to right) stopping at the first non numerical character, excluding ".^E" the ^ and E I would expect to be evaluated into its full numerical value (e.g. 1E3 = 1000 or 2^8 = 256)

Good Luck.

[jpm]

I am thinking that we may need two functions. Number("5abc") = 0, which is the same as doing the implicit conversion. But there are times we want to extract the digits as a number, so something like Val("5abc") = 5. Note that this would not count as a casting function, but maybe a conversion function.

Func _Number($x)
    If StringIsInt($x) = 0 And StringIsFloat($x) = 0 Then
        return 0
    Else
        return Number($x)
    EndIf
EndFunc

How come I find it easier to explain things in code instead of English?

I support the Val() it can NumberString().

PS your trouble is you are speaking canadian, Don't you ...?

[Valik]

Edit: The indeterminate number thing is - to put it bluntly - utterly crazy. That's not going to happen.

I agree with your "not going to happen" with one caveat: We could implement NaN as a new keyword. That's the only way it can be implemented correctly so that the string representation is something like "NaN", the number representation can be anything we want (because it is irrelevant) and the internal comparison implementation can fail when compared to everything but another NaN. In theory the generalized keyword implementation should make it trivial to implement. But that largely depends on if your issue with NaN is based on JP's implementation (I don't like it) or the concept itself (I'm 50/50 on the concept).

Anyway. Okay, we get it. When we change how Number() works we need to add some other way of extracting the leading numbers from a string. In other words we need to provide a function that behaves how Number() currently does. We can take care of that.

Edit: Note, we don't actually have to expose a NaN keyword in the language if we don't want to. It could just be a purely internal type. We could add an IsNaN() function to test if a variable is NaN or we could add a NaN keyword and let users compare. Either way, we have plenty of options.

Edited October 25, 2009 by Valik

[Jon]

Edit: Note, we don't actually have to expose a NaN keyword in the language if we don't want to. It could just be a purely internal type. We could add an IsNaN() function to test if a variable is NaN or we could add a NaN keyword and let users compare. Either way, we have plenty of options.

One thing I thought of doing ages ago was to give our variant a proper null type. Currently our base state is 0 or "" rather than a proper undefined value.

[Valik]

Replace "NaN" with "Null" or "ThereIsNoDataOnlyZuulMotherFucker" and what I said is pretty much the same.

Edit: Null could be added in 10 minutes. It would literally take longer to write and hook-up the documentation than the code to implement it.

Edited October 25, 2009 by Valik

[Richard Robertson]

Would the null state be the same as the "default" keyword?

[Mat]

How would null compare to false?

[Valik]

Would the null state be the same as the "default" keyword?

No?

How would null compare to false?

Null should compare False to everything but Null.

Guys, don't read into what Jon and I are talking about. Let's not turn this into a can of worms with a bunch of questions and comments about a new keyword.

[GEOSoft]

I suggest that we forget all about any reference to Null in this thread.

[Valik]

Agreed because it's not happening anytime soon if at all.

[Nutster]

I would also expect that @error would be set to X [a non-zero value - indicating that the actual number is derived from a mixed alphanumeric string.]

Generally, if @error is set to something other than 0, the return value is useless. It indicates that there was a problem processing the input. So I do not see this happening.

[jpm]

Generally, if @error is set to something other than 0, the return value is useless. It indicates that there was a problem processing the input. So I do not see this happening.

it depend how you interpret Number()

if it is a conversion process working on only valid representation of a number @error make sense

[GerrOrneq]

Generally, if @error is set to something other than 0, the return value is useless. It indicates that there was a problem processing the input. So I do not see this happening.

Hi, I guess I explained it badly

What I meant was if @error was set to a value that has a specific meaning attached then the @error can be used to detect if the number was converted from a 'pure' numeric string or extracted from a mixed number and charater string.

say for example if number() returned the actual parsed number AND set @error as:

0 = No errors and data string was 'pure' numeric. ("123.45")

1 = No errors and data string was alphanumeeric. ("77.2mg")

2 = Errors detected in that the string being parsed did not start with numeric data. ("Apples30")

3 = Errors detected in that the string being parsed contains No numeeric data. ("Just@work")

then just use number() as normal, it will return the numeric value, now you only need to do an IF @error<>0 to either accept

the returned value (depending on the @error value) or zero the returned value.

In this usage people who want zero returned can have that result or those that want to be able to use the returned value can do so with a simple check against the @error code to see if the number is acceptable.

The only changes to AutoIt SC then would be to have number() return an @error value

It would be valuable if it also processed ^ and E so that 1E3 and 2^8 returned numbers from a string.

I hope that has clarified things.

[Mat]

Or you could just make that function yourself based on the current number function, and save over complicating things.

[Valik]

Or you could just hush and keep your opinions to yourself until you see what we actually do... in a few months.

[Inverted]

I voted for return 0 and would also like to add that I think that @error should be set.

+1

This seems the most proper way.