Jump to content

_MathCheckDiv


JohnOne
 Share

Recommended Posts

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.

Link to comment
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...

Link to comment
Share on other sites

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
Link to comment
Share on other sites

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 by czardas
Link to comment
Share on other sites

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
Link to comment
Share on other sites

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
Link to comment
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 2022-02-19 - Version 1.6.1.0) - Download - General Help & Support - Example Scripts - Wiki
ExcelChart (2017-07-21 - Version 0.4.0.1) - Download - General Help & Support - Example Scripts
OutlookEX (2021-11-16 - Version 1.7.0.0) - Download - General Help & Support - Example Scripts - Wiki
OutlookEX_GUI (2021-04-13 - Version 1.4.0.0) - Download
Outlook Tools (2019-07-22 - Version 0.6.0.0) - Download - General Help & Support - Wiki
PowerPoint (2021-08-31 - Version 1.5.0.0) - Download - General Help & Support - Example Scripts - Wiki
Task Scheduler (NEW 2022-07-28 - Version 1.6.0.1) - Download - General Help & Support - Wiki

Standard UDFs:
Excel - Example Scripts - Wiki
Word - Wiki

Tutorials:
ADO - Wiki
WebDriver - Wiki

 

Link to comment
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.

Link to comment
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.

Link to comment
Share on other sites

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
Link to comment
Share on other sites

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
Link to comment
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
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...