 |
AutoHotkey Community
Let's help each other out
|
| View previous topic :: View next topic |
| Author |
Message |
Lexikos
Joined: 17 Oct 2006
Posts: 2526
Location: Australia, Qld
|
 Posted: Sat Apr 14, 2007 5:32 am Post subject: inconsistencies with blank variables and numeric operators |
 |
|
I've noticed an inconsistency with the numeric operators when dealing with blank variables. It's probably easiest to use an example:
| Code: | ; all vars are blank at this point
x := a + 1
y := b | 1
za += 1
zs -= 1
zm *= 1
zd /= 1
zdd //= 1
zo |= 1
zn &= 1
zx ^= 1
zr >>= 1
zl <<= 1 |
| Code: | ; Results:
; x=, y=, za=1, zs=-1, zm=0, zd=0, zdd=, zo=, zn=, zx=, zr=, zl= |
So most numeric operations seem to yeild blank results when given a blank operand, but not all. Also note (x := a+1) returned blank, while (za += 1) did not.
After looking in the help file, I found this:
| Quote: | Note: In expressions, any blank value (empty string) involved in a math operation is not assumed to be zero. Instead, it is treated as an error, which causes that part of the expression to evaluate to an empty string.
...
The operators +=, -=, and *= treat blank values as zero only when not part of a multi-statement expression (otherwise, such operations produce blank results). |
While that seems to be true, perhaps it should be mentioned that the other assignment operators (except for /=) never (afaik) treat blank values as zero.
It is confusing to have some numeric operators treat blank as zero, and others treat it as an error... |
|
| Back to top |
|
 |
corrupt
Joined: 29 Dec 2004
Posts: 2393
|
|
| Back to top |
|
|
Lexikos
Joined: 17 Oct 2006
Posts: 2526
Location: Australia, Qld
|
| Posted: Sat Apr 14, 2007 7:34 am Post subject: |
|
|
| Haha, hadn't read that, actually. The blank results are perfectly understandable (now that I'm aware of them.) It's just the inconsistency between operators that bothers me. |
|
| Back to top |
|
|
majkinetor
Joined: 24 May 2006
Posts: 3622
Location: Belgrade
|
| Posted: Sat Apr 14, 2007 12:18 pm Post subject: |
|
|
lexikos, its best if you think about AHK as an language full of excepetional rules and you will save yourself a little time.
So, things are LIKE THAT if they are not LIKE THAT. Thats the philosphy good enough for typical user who is majority here.
_________________
 |
|
| Back to top |
|
|
Lexikos
Joined: 17 Oct 2006
Posts: 2526
Location: Australia, Qld
|
| Posted: Sat Apr 14, 2007 6:18 pm Post subject: |
|
|
| majkinetor wrote: | | lexikos, its best if you think about AHK as an language full of excepetional rules and you will save yourself a little time. |
How's that? For it to save time, you'd have to know what the "exceptional rules" are. Now that I know they are there, the inconsistencies aren't likely to cause me any problems. On the other hand, new users that don't know of them may run into the same problems I did.
I was actually editing ExtractInteger - I'd noticed it couldn't possibly work with signed 8- or 16-bit integers. In the process of fixing that, I "optimized" (made the following change, which I believed to be technically correct):
| Code: | Loop %pSize% ; Build the integer by adding up its bytes.
result += *(&pSource + pOffset + A_Index-1) << 8*(A_Index-1) |
to
| Code: | Loop %pSize% ; Build the integer by adding up its bytes.
result |= *(&pSource + pOffset + A_Index-1) << 8*(A_Index-1) |
Notice the use of bit-wise OR instead of addition. It actually makes no difference to the functionality, except for one thing: the aforementioned inconsistency. blank |= integer results in a blank string, whereas blank += integer results in an integer. It took me a while to figure out why my ExtractInteger was returning nothing... (It works if result is initialized to 0, but I changed it back to using +=).
By the way, the rest of the code I'm using is:
| Code: | ExtractInteger(ByRef pSource, pOffset = 0, pIsSigned = false, pSize = 4)
{
Loop %pSize% ; Build the integer by adding up its bytes.
result += *(&pSource + pOffset + A_Index-1) << 8*(A_Index-1)
if (!pIsSigned OR pSize>7 OR result<(2**((pSize*8)-1)))
return result ; Signed vs. unsigned doesn't matter in these cases.
; Otherwise, convert the value to its signed counterpart:
return -(2**(pSize*8) - result)
} |
The original function assumed the result was 32-bit after the "if." This was causing incorrect results for integers of any size other than 32-bit and 64-bit (see below). The above function has been tested with 1, 2, 3, 4, 5, 6, 7 and 8-byte signed integers, and it works. 
It took me a while to figure out why 64-bit signed integers automagically worked... AHK doesn't support integers outside the range of a 64-bit signed integer. Would I be right in assuming this is the format used in math operations?
S'pose I should've posted an ExtractInteger bug report? |
|
| Back to top |
|
|
Chris
Site Admin
Joined: 02 Mar 2004
Posts: 10467
|
| Posted: Sat Apr 14, 2007 6:28 pm Post subject: |
|
|
The inconsistencies in AutoHotkey are due to backward compatibility. Simply changing the rules to make everything consistent would break a lot of existing scripts.
Relieving the burden of backward compatibility is what AutoHotkey v2 is all about. That is why v2 has the highest priority compared to other features.
If there's still a bug report that I should look into, please restate it as concisely as possible. |
|
| Back to top |
|
|
Laszlo
Joined: 14 Feb 2005
Posts: 4001
Location: Pittsburgh
|
| Posted: Sat Apr 14, 2007 8:16 pm Post subject: |
|
|
| lexikos wrote: | | I was actually editing ExtractInteger... |
You can make it a little more compact along this line (untested) | Code: | ExtractInteger(ByRef pSource, pOffset = 0, pIsSigned = false, pSize = 4) {
p := &pSource + pOffset - 1, s := 64-8*pSize
Loop %pSize%
result += *(p + A_Index) << 8*A_Index-8
Return pIsSigned ? result<<s>>s : result
} |
- or, if you like C-like syntax: | Code: | ExtractInteger(ByRef pSource, pOffset = 0, pIsSigned = false, pSize = 4) {
p := &pSource + pOffset + pSize, r := *--p, s := 64-8*pSize
Loop % pSize-1
r := *--p + (r << 8)
Return pIsSigned ? r<<s>>s : r
} |
|
|
| Back to top |
|
|
majkinetor
Joined: 24 May 2006
Posts: 3622
Location: Belgrade
|
| Posted: Sat Apr 14, 2007 8:29 pm Post subject: |
|
|
| lex wrote: | | How's that? For it to save time, you'd have to know what the "exceptional rules" are. Now that I know they are there, the inconsistencies aren't likely to cause me any problems. On the other hand, new users that don't know of them may run into the same problems I did. |
Like this: if you know this is a general AHK attribute, you can deduce that some of the errors you get from the code are due to the AHK's behavior. Otherwise, you will get the same conclusion after searching and destorying number of bugs, asking here, etc, just for ppl to tell you that it is excpetion. If you know this from the start,you will have different start-up scene in bug detection.
Well... you will see it anyway....
| Chris wrote: | | The inconsistencies in AutoHotkey are due to backward compatibility. |
Not quite true. Inconsistencies in AHK are also due to the bad design of some syntax elements that are freshly introduced and before that througly discussed by some community memebers. Exceptions are by the great deal phenomena that occurs as a side-effect of supporting certain programming audience, as "perfect" grammars may not be so perfect if the AHK is your first language. During the previous year, I proposed number of features dealing with language sophistication, but your common response to almost all of them was that typical user can live without it. I know that you must choose priorization methods as you are the only developer and AHK is OMG big, for single person. I think that you just need to be aware of the loss that your current priority model made to the sophistication of AHK language. Ver 2 will most definitely fix just some, probably those most anoying things.
_________________
|
|
| Back to top |
|
|
Lexikos
Joined: 17 Oct 2006
Posts: 2526
Location: Australia, Qld
|
| Posted: Sun Apr 15, 2007 3:03 am Post subject: |
|
|
| Chris wrote: | | The inconsistencies in AutoHotkey are due to backward compatibility. |
That's fine--no bug to report. 
| Laszlo wrote: | | lexikos wrote: | | I was actually editing ExtractInteger... |
You can make it a little more compact along this line (untested) |
Thanks. Neat trick with the bit-shifting. All the tests passed. |
|
| Back to top |
|
|
|
|
You can post new topics in this forum
You can reply to topics in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ
Search
Memberlist
Register
Profile
Log in to check your private messages
Log in
