DON'T USE .ToInteger or ToInt64!

General
1

From Norman’s blog (worth keeping an eye on!):

So a quick test in 2021r2.1 with

Dim s As String = "3.0e+2"

Dim i1 As Int32 = Val(s)
Dim i2 As Int32 = s.Val
Dim i3 As Int32 = s.ToInteger
Break

shows that indeed i1 = 300, i2 = 300, and i3 is 3 not 300 like I would have expected. I changed my use of ToInteger to Val and things work as expected.

http://feedback.xojo.com/case/65567

Incredible. :man_facepalming:

Does Xojo not use unit tests? How is it possible that such a bug slips through?

Time for another emergency fix release …

1 Like
2

Actually, I am more surprised i1 (the Val(s) method) comes up with 300. I don’t need scientific notation often, but my general view of Val() on a string it is will quit at the first character that is not a digit, +/- sign, or decimal separator (period in the USA).

So I am more surprised that i1 is 300; I would have guessed it said 3.

Not that is will impact any of my programs either way…

3

This is expected behaviour since it converts to an integer. It’s also explained in the docs:

https://documentation.xojo.com/api/data_types/string.html.ToInteger

Aleast they mention to use val where possible.

It’s more likely unexpected behaviour to get the scientific notification for such short value…

4

Sorry, Scientific Notation is a valid number, and Val works just fine with it.

String.ToInteger

From Xojo Documentation

Method

Returns the integer equivalent of the source string. This function is the same as the Val function but is international-savvy.

So it is clearly a bug.

5

It’s clearly in the docs:

Numbers are converted only if they are found at the beginning of the string. Any numbers that follow a non-numeric value are ignored.

6

It is not that difficult to understand that Scientific Notation IS a numeric value. Please don’t apply primary school maths concepts of numbers to modern programming, that’s ridiculous. Numbers are more than 0 to 9.

And in case you didn’t even read the documentation let me spell it out for you:

  • toInteger is stated to work the SAME as Val (I even had bolded it in the original post).
  • Val does it correctly
  • toInteger does NOT do it correctly
  • So toInteger is NOT working the same as Val

THAT IS A BUG and leads to WRONG RESULTS

1 Like
7

And just try:

Var b As Boolean
b = IsNumeric("3e2")  // <- b is TRUE
Break

QED

1 Like
8

In general though, I shy away from Val() too because it also has never correctly handled separators. Have you ever tried Val(1,000.00) ?

The string 1,000.00 is a primary school math concept, and it fails too.

I’ll agree the docs say .ToInteger should be the same as Val() and it evidently is not. Will that lead to wrong results? Not in my code. But yes, I will concur it is a bug.

9

Yep. This does seem to be a bug. It certainly is not equivalent to Val.

I think it should be corrected rather than the the docs being altered.

4 Likes
10

Nice little bug.

I also don’t understand this at the top of String.ToInteger

This function is the same as the Val function but is international-savvy.

Neither 3,000.12 nor 3.000,12 come out with 3000 for me is that what international-savvy is meant to be or am I missing something there?

Then there’s For localized number formatting, use the ToInteger function instead.

I think that should be Integer.ToString not ToInteger ?, as we’re already on the ToInteger page #confusing

11

That is actually mentioned in the Val documentation:

For localized number formatting, use the CDbl function instead. Generally, you will use Val for converting internal data and use CDbl for converting data for input and output of user data.

12

Same with .ToInt64
If you see the note:

The ToInt64 function stops reading the string at the first character it doesn’t recognize as part of a number. All other characters are automatically stripped.

it looks like ‘e’ is not recognized as part of a number.

1 Like
13

:scream: :man_facepalming:

Time for a new “Xojo Maths is badly broken” thread …? :thinking:

14

There is Integer.FromString but that doesn’t work, not even the “1,234” sample code on that page:
63596 - Integer.FromString macOS API 2 locale bug causing exception on formatted strings

Edit: Windows works, mac doesn’t work (mentioned in the report)

15

Wow, I tried it in Windows and it worked ok, guess not on mac, oof, February, damn.

16

Really? You mean this:

Var Locale As New Locale("en-US")
Var value As Integer
value = Integer.FromString("1,234", Locale) // value = 1234

On my Mac with Xojo 2021R2.1 and MacOS X Mojave:

RunTimeException on the third line with “1,234 is not a valid integer.”

And “someone” at Xojo thinks Xojo does not have a bug problem …

17

I realize that, and is one reason I tend to NOT use Val() for anything unless I am really sure the data will be converted as expected. Since I have not needed scientific notation in over 40 years of my programming, it is not on my radar.

YMMV.

I’m not saying it should not be fixed; .ToInteger clearly does not act the same as Val() as the docs state. I just think Val() is also not as useful as some people assume it is. And if .ToInteger is fixed to operate the same as Val(), I’d avoid it too for most purposes.

18

:slight_smile:

19

It does. Scientific Notation is very common in - surprise - Science :wink:

… and that view is clearly wrong. So time to adopt a better one. :nerd_face:

20

Together with the SQLite database problem that is now TWO serious errors. Let’s hope they get a new bug fix release out soon.