starbucks_mafia {
You seem to have read one single sentence out of context and then ignored the rest of the article which goes on to explain why the concept of -0 is in some instances an important and useful means of representing 0. But anyway, the bug is fixed now so no point going on about it.
}
No, that's not what I did. It sais perfectly clear that minus zero does not exist, when you combine it with the axiom of identity. You cannot have two symbols that represent the same concept. This means that when you shall give a final answer to a mathematically question you can never say minus zero. If you do, you have given an answer that is not correct, presumptive an answer that is not completely reduced.
That there exist some math where it is meaningful to control zero with signs used as a memory cell where this is holding information of where you got your zero, is not relevant.
To see how silly this really is you can try this:
a {
//echo 4 $sin($calc($pi / 1))
result: -0
//echo4 $sin($pi)
result: 0
}
First answer is NOT final. The last one is. Assume I used another number for sin, and I got decimal error, I wouldn't dream of complaining, because I do realise that Khaleds math motor is numerical and do not do any symbolic evaluation. I can go for
Now look at this:
b {
//echo 4 $calc(0)
result: 1
//echo 4 $calc(0 + 0)
fictive result: -0
}
a and b are in this context: equivalent.
While we're at -finding bugs in mIRC script's math motor-, let me help you have some more fun, because this motor is corrupt down to the roots. Check this:
//echo 4 $calc(0 / 0)
And again, there are some "math" where this result can be useful, but it's not consistent with the axioms, and can therefor rightfully not be called correct math. Anyway, what has Khaled thought about when he did this? It would at least made some sense when coerced to give a numerical answer, if the answer was 1, but this made non.
If you think this is as fun as me, there may be more to come when (or if) I turn to trigonometry.
***
starbucks_mafia {
I can reproduce your second issue. Simply put, $window().w, $window().dw, and $window().state (and possibly some others I haven't thought of) return values based on inactive windows being in a restored (non-maximised) state. I think it's technically correct since MDI windows aren't considered maximised when they're inactive. Ideally mIRC would provide exceptions to return the expected values in those situations since I think those would probably be more useful. Then again maybe it's more trouble than it's worth to implement.
}
I suspected something like this, but I don't agree with you, not this time either. If your assumption is correct, Even though I'm able to follow your idea when you say a window that is not active isn't considered maximized, it cannot be correct to give me a number that only was true when the window was restored, when I ask what the window is now. Analogic pretty much the same type of error as with the math thing. BTW, I do not consider MS as an authority, so even if Khaled got Bill Gates to say that my width is correct, I won't accept it. I do only allow proofs into my brain.
Written but not read by
Kru MacLure.
