JohnOne

_MathCheckDiv

56 posts in this topic

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.


AutoIt Absolute Beginners    Require a serial    Pause Script    Video Tutorials by Morthawt   ipify 

Monkey's are, like, natures humans.

Share this post


Link to post
Share on other sites



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...

Share this post


Link to post
Share on other sites

#3 ·  Posted (edited)

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 by czardas

Share this post


Link to post
Share on other sites

#5 ·  Posted (edited)

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 by czardas

Share this post


Link to post
Share on other sites

#8 ·  Posted (edited)

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 by czardas

Share this post


Link to post
Share on other sites

#9 ·  Posted (edited)

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 by jaberwacky

Share this post


Link to post
Share on other sites

#10 ·  Posted (edited)

That wil only work on a 32-bit integer.

Edited by czardas

Share this post


Link to post
Share on other sites

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


My UDFs and Tutorials:

Spoiler

UDFs:
Active Directory (NEW 2017-04-18 - Version 1.4.8.0) - Download - General Help & Support - Example Scripts - Wiki
OutlookEX (NEW 2017-02-27 - Version 1.3.1.0) - Download - General Help & Support - Example Scripts - Wiki
ExcelChart (2015-04-01 - Version 0.4.0.0) - Download - General Help & Support - Example Scripts
Excel - Example Scripts - Wiki
Word - Wiki
PowerPoint (2015-06-06 - Version 0.0.5.0) - Download - General Help & Support

Tutorials:
ADO - Wiki

 

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

#16 ·  Posted (edited)

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 by czardas

Share this post


Link to post
Share on other sites

#17 ·  Posted (edited)

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 by jaberwacky

Share this post


Link to post
Share on other sites

#18 ·  Posted (edited)

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 by czardas

Share this post


Link to post
Share on other sites

#20 ·  Posted (edited)

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  :sweating::thumbsup:>_<:rolleyes::dance:

Edited by jaberwacky

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now