32-bit integers converted to doubles after division

[czardas]

Perhaps not everyone will agree with me, but I consider this a bug:

Local $sHex12 = 8987712 ; This is an integer.

While Not Mod($sHex12 ,2) ; Floats are not allowed
    $sHex12 /=2 ; The loop terminates when this value becomes odd
WEnd

MsgBox(0, $sHex12, IsInt($sHex12)) ; This is still an integer: since it has been forced in the code above

; $sHex12 = Int($sHex12) ; Converting to an Integer fixes the problem

$sHex12 = Hex($sHex12, 6) ; 000000 is the wrong answer
MsgBox(0, "", $sHex12) ; The 32-bit int has been converted to a double

The conversion to a double messes up bitwise functionality with 32-bit integers, and it also seems to contradict my (perhaps limited) understanding of consistency with programming language architecture. The division in my code above should never produce a float. This bug first appeared in AutoIt v 3.8.8.1.

Also related to this issue is the inconsistency with IsInt() contradicting IsFloat().

[czardas]

I feel some comments I made in chat need repeating here, because I consider this to be of paramount importance for the maintainability of AutoIt.

Division ought to do EXACTLY the opposite of multiplication. With mixed data types I can see there being the need to make a choice about the data type of the return value - defaulting to double when FP is used as input seems natural.

Arithmetic operators are no longer compatible with bitwise functions in the sense that they can no longer be nested. I can't possibly understate the complications this creates, nor condone the unwieldy patches required to do basic arithmetic using AutoIt. I am all for progress, but not if it goes against basic principles, or has a destructive effect on functionality.

[anonymous]

Some of what I have said here is actually misleading. It seems bitwise functions are accepting doubles. I didn't realise this. Sorry for this misinformation.

[anonymous]

Some of what I have said here is actually misleading. It seems bitwise functions are accepting doubles. I didn't realise this. Sorry for this misinformation.

[Melba23]

We have discussed this in the forum.

As the vast majority of division operations return a value having a fractional component, I do not see how AutoIt can be expected to do other than convert the result into double format. The IsInt or IsFloat functions will determine if the result of the division has a fraction component and could be reconverted to integer format without problem. I agree it would be ideal if AutoIt did this internally, but at the moment it does not - perhaps you should perhaps create a feature request asking for this feature to be added.

Furthermore, you only discovered this as a result of using Hex on the returned value. As the Help file makes it clear that Hex requires integer (or binary) arguments, I would argue that is incumbent on the coder to ensure that any value passed to that function is correctly typed.

M23

[czardas]

I have no problem if you decide not to revert back to the original behaviour of division on whole numbers. Although this change occurred a while ago, and clearly alters a core feature, there was originally a plan to address the return values according to what trancexx said. My first concern was that additional conversions (not dealt with internally) will incur a latency penalty, especially in tight loops. However my main concern is that mathematical operators now appear inconsistent. Why does the multiplication of integers not also produce a double?

[Melba23]

Because multiplying 2 integers will always produce another integer, whereas dividing them will not in many (if not most) cases. From Wikipedia on "Integer"

Algebraic properties
[The integer set] Z is closed under the operations of addition and multiplication,
that is, the sum and product of any two integers is an integer. However, with the
inclusion of the negative natural numbers, and, importantly, 0, Z (unlike the natural
numbers) is also closed under subtraction.
[The integer set] Z is not closed under division, since the quotient of two integers
(e.g., 1 divided by 2), need not be an integer.
Although the natural numbers are closed under exponentiation, the integers are not
(since the result can be a fraction when the exponent is negative).

M23

[anonymous]

Well this is basic maths. The question did not really require a response. I was merely trying to illustrate the inconsistencies which have occurred with the changes made a while ago. I am of the opinion that corruption should be kept to a minimum, and that compatibility should always take precedence. Binary variants are complicated enough already.

If division is not doing the exact opposite of multiplication, then I see only two alternatives: change one or the other to conform as closely as possible with the system of notation (in this case a programming language), or storage options (eg binary variants). Here some leeway is indicated because binary cannot possibly store the results of incommensurable divisions: eg the circumference of a circle divided into its radius. The question is how much compromise has to be made and what is the trade-off?

[czardas]

Corrections to the above post:

... the circumference of a circle divided by its radius

Author - czardas

[czardas]

As an afterthought, a compromise has to be made at some point and, either way, there is always going to be a down side. This much I do understand. Inconsistency is just such a hard pill to have to swallow. If I divide anything by one I expect no change to the input whatsoever. If it's too complicated to implement with the current AutoIt internals, then that's fair enough.

[Melba23]

Replying to anonymous:

The question did not really require a response.

Then I will no longer provide any.

M23

[anonymous]

No worries. I am grateful you responded here, I merely implied that the question was meant to be rhetorical.

[czardas]

I have discovered Floor() is also returning doubles when it used to return 32-bit integers. I imagine Ceiling() will do the same. People seem to have either overlooked these apparently language-breaking alterations, or don't consider them a problem. I personally consider these changes to be major.

Although I haven't upgraded, because it seems it will take me several months I tend to follow discussions. I never saw discussions about changes to the behavior of these functions.

[czardas]

Perhaps someone should close this. I'm not always able to test stuff (temporary situation) and I keep misinterpreting what people say to me. Some things seem not to be working the way I expect and I'm not sure exactly what the problem is. Floor() was not the causing the problem I encountered.

[Jpm]

AutoIt has no Integer only math. addition, multiplication keep integer type is both are integers but for division as the result is mostly a float number the return is always a float number

[jchd]

Note to czardas:

ConsoleWrite(VarGetType(Floor(1/3)) & @LF)
ConsoleWrite(VarGetType(Ceiling(1/3)) & @LF)

both return Int32, as expected. Else it would be an actual bug, contrary to integer division always returning a double: a (questionable) design decision against which we can't do much.

[czardas]

Thank you for looking into this.