B4J Question Product of 2460601801000 is negative and incorrect

xulihang · Jun 15, 2021

B4X:

Dim result As Long
result=24*60*60*180*1000  
Log(result)
Log(Abs(result))
Dim direct As Long=1627869184
Log(direct)

Output:

B4X:

-1627869184
1.627869184E9
1627869184

I encountered a problem that a large product using a formula becomes negative while it is positive by directly assigning the value.

Actually, the result value is not correct, as well.

xulihang · Jun 15, 2021

I have to define one of the numbers as long to get the correct result:

B4X:

Dim x As Long=1000
Dim result As Long
result=24*60*60*180*x

B4X:

15552000000

agraham · Jun 15, 2021

Interestingly that seems to be a problem/feature with Java itself. B4A/J compiles the calculation as

Result = (long) (24*60*60*180*1000);

By default Java assume literal numbers are 32 bit integers. Java promotes values to that of the most precise type in the expression before doing a calculation and so is doing the calculation as 32 bit integers then casting the result to a long. Making one of the values a long doesn't apparently change the compiled code but does force Java to promote the other values to longs before calculating the result.

x = (long) (1000);
Result = (long) (24*60*60*180*x);

Daestrum · Jun 15, 2021

You can help the compiler (if you know the value will be large) by giving it a hint.

B4X:

result=24*60*60*180*1000.0d

Forces the 1000 to be considered as a double.
1000l (L) should work too but the ide sees it as an syntax error

Erel · Jun 15, 2021

The result of multiplying Ints is an Int. You must explicitly set the type of one of the number as you did.

Magma · Jun 15, 2021

Nice question! Sometimes breaking my head why works and why not...

Erel answered that with "A Solution"

I am not extending the question ... but are the numbers "counted" as INTs because: for less memory ?
is it something that we can change and set them all by default double perhaps - am i asking too much ?

Erel · Jun 15, 2021

Large whole numbers, larger than the maximum value an Int can hold, are treated as Longs.
You don't want to treat whole numbers as double by default. It will have bad side effects.

Magma said:
but are the numbers "counted" as INTs because: for less memory ?

99.9% of the numbers that you use in your code are in the range of int. Treating them as long will have some performance and memory impact.

MegatenFreak · Jun 19, 2021

That problem happened to me once and I solved it by defining "all" the involved numbers and elements as longs and then calculating the result. Will it always work as long as only ONE of them is a long and the rest are all ints?

agraham · Jun 19, 2021

MegatenFreak said:
Will it always work as long as only ONE of them is a long and the rest are all ints?

Yes

agraham said:
Java promotes values to that of the most precise type in the expression before doing a calculation

Markus Winter · Jun 19, 2021

Erel said:
You don't want to treat whole numbers as double by default. It will have bad side effects.

Which ones? As doubles can represent quite a large integer range precisely (much larger than 32bit Integers) I’m curious which side effects you are referring to?

OliverA · Jun 19, 2021

MegatenFreak said:
Will it always work as long as only ONE of them is a long and the rest are all ints?

No. If you want to avoid overflow issues, the first number must be a Long. This can be either by ensuring that the first number is a long variable or that the first number is a string literal that must be converted to a long (it is large enough not to fit into an Int).

For explanations on this, see

[SOLVED a bit embarrassing] Is this a bug or am I going stark raving mad?

Private junk As Long = 30 * 24 * 3600 junk = junk * 1000 Log(junk) 'get 2592000000 junk = 30 * 24 * 3600 * 1000 Log(junk) 'get -1702967296

www.b4x.com

[SOLVED a bit embarrassing] Is this a bug or am I going stark raving mad?

Private junk As Long = 30 * 24 * 3600 junk = junk * 1000 Log(junk) 'get 2592000000 junk = 30 * 24 * 3600 * 1000 Log(junk) 'get -1702967296

www.b4x.com

[SOLVED a bit embarrassing] Is this a bug or am I going stark raving mad?

Private junk As Long = 30 * 24 * 3600 junk = junk * 1000 Log(junk) 'get 2592000000 junk = 30 * 24 * 3600 * 1000 Log(junk) 'get -1702967296

www.b4x.com

agraham said:
Making one of the values a long doesn't apparently change the compiled code but does force Java to promote the other values to longs before calculating the result.

If Java does this, B4X does not mimic that behavior. In order to avoid overflow, the first number used in the calculation should be of the desired output type (in this case Long). See the second link I posted above for proof by code.

Erel · Jun 20, 2021

Markus Winter said:
Which ones? As doubles can represent quite a large integer range precisely (much larger than 32bit Integers) I’m curious which side effects you are referring to?

1. Changing the behavior of numeric literals, at this point, is not something that can happen as it will break backward compatibility ( [B4X] Backward Compatibility )
2. The performance of doubles (= 8 byte) calculations is worse than ints (= 4 bytes) calculations. This is not problematic in most cases, but it can be relevant in some compute-intensive tasks.
3. Comparing equality of doubles is a bit risky as small rounding errors can cause two numbers that are expected to be the same to be not equal.
4. It will break many JavaObject usages where the passed value is expected to be an Int. Int is the "standard type" for whole numbers.

Markus Winter · Jun 20, 2021

To be honest I am looking at B4 because I hoped it wouldn't have the same 32bit problems that Xojo has (and I'm not talking about the inherent phenomen of 32bit integer overflows, but how to deal with it)..

The problem is that 32bit integer overflows have caused planes to crash - so they really need to be taken seriously.

The following table lists the largest whole number that can be **accurately** represented by the different numeric types:

[Early PCs had a mathematical co-processor that sped up floating point calculations - and programmers often used Doubles to avoid 32bit integer overflows on 32bit systems, and without any real speed penalties.]

Doubles and 64bit Integers have MUCH larger ranges of Integers that they can accurately represent than 32bit Integers.

Nowadays 2 Billion is not a big number anymore, so my (personal) opinion is that everything should use or at least allow 64bit Integers where "Integers" are expected - even on 32bit systems.

1) "Backwards Compatibility" in this context means keeping 32bit Integer overflows around, something that I don't find acceptable in Xojo or B4, especially as a 32bit system can deal with 64bit integers just fine. Is it some work? Yes. Can it be done? Yes. Should it be done? Definitely.

Funnily enough the suggested workaround for 32bit integer overflows is to turn it into a double … which kind of negates the argument that you can't do that because of backwards compatibility …

2) Performance? That's an argument that sounds sensible but that stopped being an argument about 15-20 years ago. Even a 10 year old computer is so fast that you won't notice whether you use 64bit integers or Doubles instead of 32bit integers (and as a Molecular Biologist I used to routinely analyse multi-gigabyte sized files of data on my 2010 Mac Pro).

3) the doubles accurately represent those integers - no problem with comparisons

4) That might be an argument. But I would argue that even on 32bit systems those objects should accept 64bit Integers. Sure, that's work - but with the current situation you might get different results on your 64bit system at home and the 32bit system at work … and that is just crazy.

Security and reliability should be the prime concern. If you can't trust the computer to do Maths correctly …?

agraham · Jun 20, 2021

OliverA said:
, the first number used in the calculation should be of the desired output type (in this case Long).

Interesting. Thank you. You learn something new everyday (or should if you don't)!

Erel · Jun 20, 2021

@Markus Winter note that B4X type system doesn't depend on the CPU architecture (with the exception of B4R in some cases). An Int is always a 32 bit integer.

Markus Winter said:
ven a 10 year old computer is so fast that you won't notice whether you use 64bit integers or Doubles instead of 32bit integers (and as a Molecular Biologist I used to routinely analyse multi-gigabyte sized files of data on my 2010 Mac Pro).

A 2010 Mac Pro is likely to be faster than many mobile devices.

You can add .0 to all numbers if you want numeric literals to be treated as doubles. You can also add a sub that converts numbers to double:

B4X:

Public ToDouble(d As Double)
 Return d
End Sub

MegatenFreak · Jun 21, 2021

Erel said:
You can add .0 to all numbers if you want numeric literals to be treated as doubles.

So turning integers into doubles will also produce the correct result when it falls within the 'long' range, right?
Just to make things clearer for myself, which one of these methods is 'better', professionally? :

B4X:

'Method 1
dim n1 as long = 24
Log(n1*60*60*180*1000)
'Method 2
Log(24.0 * 60 * 60 * 180 * 1000)

Erel · Jun 21, 2021

Method 1 is better. Doubles cannot represent accurately all values.

MegatenFreak · Jun 21, 2021

Erel said:
Method 1 is better. Doubles cannot represent accurately all values.

Yeah, I had forgotten about an annoying experience I'd had with doubles, namely:

Very strange problem adding two numbers

Hi. I do some additions in my app, and I ran into this strange problem: when I add 1.3 and 0.1, I get 1.4000000000000001 instead of just 1.4: Log(1.3 + 0.1) Log(1.3 + 0.11) Log(1.3 + 0.102) All of the above result in a large number just like the example. What is strange is that IT...

www.b4x.com

B4J Question Product of 24*60*60*180*1000 is negative and incorrect

Active Member

Active Member

Expert

Expert

B4X founder

Expert

B4X founder

Active Member

Expert

Member

Expert

B4X founder

Member

Expert

B4X founder

Active Member

B4X founder

Active Member

Privacy & Transparency

Privacy & Transparency

B4J Question Product of 2460601801000 is negative and incorrect