Xojo Math badly broken: 32bit problems in a 64bit environment

[Christian_Schmitz]

Thanks. So you got an upgrade to Compiler engineer, I assume.

[anon20074439]

@Thom_McGrath

Oh THIS one they fix, but comparisons suffering the same problem is vehemently not a bug? Come on…

#11935 and #2218. Both closed because Xojo doesn’t want to fix it.

Maybe you need to write an article in xdev about it, perhaps it’ll get fixed then?

@Thom_McGrath

I have a blog post about the issue, but I’m not going to link it due to forum rules.

This site ? https://thezaz.com/ I don’t see why that would break the rules. If I can’t link there, then I can’t also link to twitter or google

[Eric_Wilson]

@Christian_Schmitz

And it looks like double conversion uses EDX as target instead of RDX for 64-bit. And later the 32-bit number is extended to 64-bit as division needs that as input.

You’re a rocket scientist Christian!

[Markus_Winter]

@DerkJ

It’s a major waste of time, not knowing what to expect from the compiler while your brain says the value is for example:

// In a 32-bit app the following happens:
Var Value As UInt32 = 4294967295
If Value > 100 Then
// Won't Reach Here 
End If

My brains where exploding almost…

It’s not a fix, but the problem should be somewhat alleviated if you replace all your UInt32 with UInt64.

[Markus_Winter]

@anon20074439

Maybe you need to write an article in xdev about it, perhaps it’ll get fixed then?

Yes please!

[Thom_McGrath]

@Markus_Winter

It’s not a fix, but the problem should be somewhat alleviated if you replace all your UInt32 with UInt64.

Until you reach beyond the upper boundary of Int64, then the problem comes back.

[Markus_Winter]

@Thom_McGrath

Until you reach beyond the upper boundary of Int64, then the problem comes back.

That’s why I wrote “alleviates the problem”.

Nowadays 2 or 4 billion are not large numbers anymore (Bill Gates has more money, the US deficit is a thousand times larger) so with 32 bit Maths you will run more and more often into overflow errors. Using 64 bit (even on 32 bit systems) pushes out the threshold by a considerable distance …

[DerkJ]

Ok sure i’ll let you do that, at no charge please. Since we have so many sockets and protocols using UInt8, Uint16, Uint32 etc… even Int32 etc…

I’t not funny if you don’t get what you expect in comparison results! You get what i mean right?
There is no such solution as search, and replace all in this.

[Markus_Winter]

@Paul_Lefebvre

Yes, the fix applies to both the Mod and Integer Division operators.

@Paul_Lefebvre Was the fix applied to any other functions? I was going to check some more functions tomorrow, but that would be pointless if they are already fixed …

[Paul_Lefebvre]

No, just Mod and integer div.

[Robert_Weaver]

From the original post:

@Markus_Winter

result = doubleValue mod intValue

When I read that, my first thought was, what possible purpose could there be to use a mod operation with a floating point number?
Regardless of whether Xojo converts the values to Int32 or Int64, using a value that started life as a floating point number is fraught with danger, and would need some serious testing to make sure that it behaves as intended.

[Markus_Winter]

@Robert_Weaver

When I read that, my first thought was, what possible purpose could there be to use a mod operation with a floating point number?

Well, I hope I made clear what the purpose was (especially with with 32 bit systems). Sometimes you have no choice as people (incl Xojo) chose Double for their properties (like TotalSeconds) instead of Int64 (I explain a bit more about the historical and technical reasons in a forthcoming xDev article).

Regardless of whether Xojo converts the values to Int32 or Int64, using a value that started life as a floating point number is fraught with danger, and would need some serious testing to make sure that it behaves as intended.

Not really. If you use Double as an Integer then you also have ways to ensure that it can only be input as an integer (eg masks for user input, some easy tests).

But it would be so much better if Xojo used and/or coerced to 64bit Integer where it was appropriate.

[Eric_Wilson]

I saw in the release notes 2020r2 that xojo.math functions have been depreciated.

Is there a list of what functions and what their replacements (if any) are?

[Greg_O_Lone]

If you go to the docs for the individual Xojo.Math methods a red box at the top of the page will show you what the replacement is.

[Eric_Wilson]

Thanks!

[Markus_Winter]

It’s not the math functions that have been deprecated but the Xojo namespace. The math functions are now in the global namespace where they previously were, so you can just use e.g.

y = sin(x)

instead of

y = Xojo.sin(x)