DON'T USE .ToInteger or ToInt64!

[Rick_Araujo]

I would expect transparent and correct values for the transition between .ToString() and back, independently of locales, by default. And I’m not seeing this in Windows.

Var d As Double = 6.54321e3  // 6543.2100000000000364
d = d.ToString.ToDouble // I would expect 6543.2100 back to d but instead I see 6543210000

The locale set in such machine uses comma as decimal, but a “go and back” should not differ, as all the API should be consistent in a “default” mode.

That’s a Severe “Bug” (inconsistency) that potentially can silently insert bugs in all the user base made apps.

Test done in 21r1.1

[TimStreater]

Using @Rick_Araujo 's code with macOS Mojave, and with Win7 in a VirtualBox VM, and 2021r2.1, I get the expected result with both OSes. The result is displayed using one of:

MsgBox (str(d))
MsgBox (d.ToString)

which differ only in how many extra decimal zeros they put out.

[anon20074439]

Tim, it’s to do with your locale, if you have it set to a region that uses a decimal comma instead of decimal points then it fails, I tested it a while back.

It would seem that a lot of Xojo’s tests are done in North American/English isolation which is probably why this wasn’t picked up on, I’ve not checked feedback to see if its in there yet.

[TimStreater]

Hmm. It should work regardless of locale, certainly.

[Rick_Araujo]

@TimStreater

It should work

Yes. So it’s a bug, severe inconsistency, leading to unexpected behaviors and errors, seemingly random at someone’s user base, but tied to locales.

[Ulrich_Bogun]

@anon20074439

I’ve not checked feedback to see if its in there yet.

Fixed and waiting for verification as of Aug. 18th.

[anon20074439]

<https://xojo.com/issue/63596>

Let’s hope its also tested in windows as this is a macos report.

[Markus_Winter]

@TimStreater

That makes it perfectly clear what “3e2” will be converted to. Well, it was perfectly clear before, Markus is just being obtuse.

No, you’re being obtuse, Markus. I was right the first time.

No you weren’t. It is a bug. A serious one. And Xojo has acknowledged it as a bug.

Personally, I would say that if a user wants to put the number 300 in an input field, that’s what they put. They don’t put 3e2 and then turn around looking for applause for being clever.

3e2 was an easy to grasp example. I could have used 6e15 or 1.38e17 but thought it was better to use a simple example.

The point of Scientific Notation is that it is much less error prone to write 3.5e12 instead of writing 3500000000000, and it makes it also much easier to compare with other values like 9e11 or 900000000000 to see which one is actually larger without counting how many zeroes there are.

Should have been obvious, but seems I was wrong about that.

@Rick_Araujo

That’s a Severe “Bug” (inconsistency) that potentially can silently insert bugs in all the user base made apps.

Yup.

@Ulrich_Bogun

Fixed and waiting for verification as of Aug. 18th.

That’s good news.

.

P.S. And just for the record: at least I don’t complain about others and get them suspended. Which seems even more ludicrous now that the bug has been confirmed and fixed.

[KarenA]

@Markus_Winter

Should have been obvious, but seems I was wrong about that.

Markus,

Us science (and engineering) types have to deal with scientific notation routinely, but most people don’t.

-karen

[Markus_Winter]

@KarenA

Us science (and engineering) types have to deal with scientific notation routinely, but most people don’t.

That’s why I used a simple one, just to have it thrown back at me as an “argument” that nobody writes 300 as 3e2 … go figure.

The question wasn’t whether I was right or wrong, it was that some here didn’t want to change their perception even after I demonstrated that it was a bug.