_MathCheckDiv

[JohnOne]

Is this a bug?

#include <Math.au3>

Local $a_i_Array[6] = [11111111111111111111, 1111111111111111111, 111111111111111111, 1111111111111111, 1111111111111111, 111111111111111]

For $i = 0 To UBound($a_i_Array) -1
    ConsoleWrite(_MathCheckDiv($a_i_Array[$i], 2) & " - " & $a_i_Array[$i] / 2 & @LF)
Next

If not, it should be documented that certain numbers are not allowed.

[Tekk]

If you look under "Datatypes" in the help file it seems to me that the largest number value AutoIt internally supports is Int64 which has a max value of 9223372036854775807. 11111111111111111111 exceeds that value so I would call it a limit.  I suppose numbers larger than that are allowed for backward compatibility with UInt64 and such with dllstructs.  idk...

[czardas]

Int() is not reliable towards and beyond the upper bounds of 15 digits. Functions which rely on Int() will sometimes return erroneous results with large numbers.

Edited February 2, 2015 by czardas

[JohnOne]

Had to be one of them.

Probably should be documented I suppose.

[czardas]

I did a fair amount of investigation, and it still isn't exactly clear to me what is happening in extreme cases. I've been trying to remove input size limitations on my Fraction functions, and it has been a slow process. Mainly time restraints are slowing me down. Anyway I came up with the plan of allowing corruption and setting the extended flag when return values are slightly inaccurate. Soon the whole library will do this. This means you can be blasé and not check the flag, or check the accuracy in cases where you think a problem might occur. It's the best solution I could think of for the UDF. It is related to this in some ways. When finished it should be far more user friendly than it is right now (and 100% accurate within clearly defined limits).

Edited February 2, 2015 by czardas

[czardas]

Try running this.

For $i = 0 To 20
    ConsoleWrite(Number('1e+' & $i) & ' = ' & Execute('1e+' & $i) & ' ==> ' & _
            (Int(Number('1e+' & $i))    =     Execute('1e+' & $i)) & @LF)
Next

;

Then compare that with what happens when you remove Int().

Edited February 2, 2015 by czardas

[JohnOne]

Everything becomes  "True" when remove int.

[czardas]

Still thinking about this. Numbers beyond a certain size cannot have a fractional part because a double doesn't hold enough information. Using Int() on large numbers is therefore quite meaningless; and checking divisibility can never be reliable. The question is what to do about it. Returning an out of bounds error seems the most logical. Then again there is always the BigNum UDF.

Edit

I agree with you: at the very least it needs some aditional documentation, the way things are right now.

Edited February 3, 2015 by czardas

[jaberwacky]

If you want to check for whether a number is even or odd try this function:

(assumed because you're using 2 in your example)

Func IsEven(Const $x)
  If BitAND($x, 1) = 0 Then
    Return True
  Else
    Return False
  EndIf
EndFunc

Taken from: http://www.catonmat.net/blog/low-level-bit-hacks-you-absolutely-must-know/

Edited February 3, 2015 by jaberwacky

[czardas]

That wil only work on a 32-bit integer.

Edited February 3, 2015 by czardas

[jaberwacky]

oh, durrr

[jaberwacky]

Hmmm, I wonder if that should be reported as a feature request to expand BitAND to work with 64 bit ints?  Or is that something real silly?

[water]

Why do you use "==" for comparison?
According to the help file "==" is for string comparison, whereas "=" is for value comparison.
 

[jaberwacky]

Hmm, but since all we care about is the LSB, then we shouldn't care if the first half is scalped off.  Right?

 

Why do you use "==" for comparison?
According to the help file "==" is for string comparison, whereas "=" is for value comparison.
 

Because I made an oversight.

[czardas]

Hmmm, I wonder if that should be reported as a feature request to expand BitAND to work with 64 bit ints?  Or is that something real silly?

 

It's not a silly question at all. I think Jon is aware of this but I'm not sure what his next priorities will be. It is possible to create a 64-bit bitwise UDF, if there isn't one already.

[czardas]

Hmm, but since all we care about is the LSB, then we shouldn't care if the first half is scalped off.  Right?

 

It matters when you're trying to test divisibility by numbers not equal to 2 (or 5 with decimal).

Edited February 3, 2015 by czardas

[jaberwacky]

I made an assumption on the off chance that JohnOne wanted to test for odd or even.

I tested it and it seems that it will still work for 64 bit ints too.

For $i = 9223372036854775807 To 0 Step -1
  ConsoleWrite(IsEven($i) & @CRLF)
Next

Func IsEven(Const $x)
  If BitAND($x, 1) = 0 Then
    Return True
  Else
    Return False
  EndIf
EndFunc

Edited February 3, 2015 by jaberwacky

[czardas]

I think John wanted to test _MathCheckDiv and used odd numbers to expose the inconsistency.

I tested it and it seems that it will still work for 64 bit ints too.

 

Another mystery, LOL.

Edited February 3, 2015 by czardas

[jaberwacky]

ohhhh, ok, makes sense now

[jaberwacky]

It isn't too mysterious I think.  All we care about is the 1 in this number: 0x00000001, anything before that can be cut off and it wouldn't matter in this instance.  but anyways, yeah, back to the topic now 

Edited February 3, 2015 by jaberwacky