mIRC Home    About    Download    Register    News    Help

Print Thread
Page 1 of 2 1 2
#200354 04/06/08 03:17 AM
Joined: Jun 2008
Posts: 12
K
Pikka bird
OP Offline
Pikka bird
K
Joined: Jun 2008
Posts: 12
Possible bug 1:
/echo 4 $sin($calc($pi / 1)) yells minus zero.

Possible bug 2:
/echo 4 $window(@test).w doesn't give width of @test if another window is active. Is it a work around? (I do not consider activating @test as a work around)


Krumelure #200369 04/06/08 10:45 AM
Joined: Jan 2003
Posts: 2,523
Q
Hoopy frood
Offline
Hoopy frood
Q
Joined: Jan 2003
Posts: 2,523
#1 isn't really a bug in my opinion, as $calc($pi / 1) returns 3.141593, which is slightly greater than the actual value of pi (it's rounded up), so the sine of that angle is slightly less than zero, but that negative value is smaller than 0.000001, which is the default output precision of mirc's number identifiers. In other words, the actual result -0.000000346410207.... is rounded to 6 decimal digits, resulting in -0.000000 = -0. I suppose mirc could take the extra step of removing the minus sign in this case, it doesn't really matter though (-0 is still 0).

I cannot reproduce #2; I can retrieve the width of inactive windows fine.


/.timerQ 1 0 echo /.timerQ 1 0 $timer(Q).com
Krumelure #200429 05/06/08 10:18 AM
Joined: Dec 2002
Posts: 5,411
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,411
Thanks I've fixed the +/-0 issue for the next version. I wasn't able to reproduce the second $window().w issue however. I tested with @test window active/non-active, minimized/maximized/restored and it returned the correct value.

qwerty #200430 05/06/08 10:24 AM
Joined: Jun 2008
Posts: 12
K
Pikka bird
OP Offline
Pikka bird
K
Joined: Jun 2008
Posts: 12
#1 qwerty: Then I can tell you, you're not a math guy. Minus zero doesn't exist periode, so this is not at all a rounding issue.

Khaled: thx.


#2
Khaled:
Clean mirc 6.32 installed.
/window -pe @test
maximize @test
Ctrl+Tab (going back to status window)
/echo 4 $window(@test).w
result: width of @test before maximizing.

I found a work around for this, but the code is ugly. I need to know if treebar is active and the size of borders.

Last edited by Krumelure; 05/06/08 10:34 AM.
Krumelure #200431 05/06/08 11:53 AM
Joined: Jan 2003
Posts: 2,523
Q
Hoopy frood
Offline
Hoopy frood
Q
Joined: Jan 2003
Posts: 2,523
Originally Posted By: Krumelure
#1 qwerty: Then I can tell you, you're not a math guy. Minus zero doesn't exist periode, so this is not at all a rounding issue.
Thank you for letting me know what kind of guy I am. Regarding your claims about the existence of -0, Wikipedia disagrees; this looks very much like a rounding issue.


/.timerQ 1 0 echo /.timerQ 1 0 $timer(Q).com
qwerty #200432 05/06/08 12:27 PM
Joined: Dec 2002
Posts: 5,411
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,411
Yes, this is really just a rounding issue. I'm correcting it mainly because most users won't need the sign in this case.

Khaled #200439 05/06/08 06:45 PM
Joined: Jun 2008
Posts: 12
K
Pikka bird
OP Offline
Pikka bird
K
Joined: Jun 2008
Posts: 12
qwerty {
Thank you for letting me know what kind of guy I am. Regarding your claims about the existence of -0, Wikipedia disagrees; this looks very much like a rounding issue.
}

I didn't tell you what kind of guy you are, but what kind you cannot be. Your flexible relationship with presision gave me another confirmation you're not a math guy.
Normally I don't accept Wikipedia as an authority in math or any sciene, but when it confirm my statement so clearly allready in the second statement I could make an exception.


Khaled {
Yes, this is really just a rounding issue.
}

In relation to math, it is not.

Khaled {
I'm correcting it mainly because most users won't need the sign in this case.
}

You would stood safer if you said you're correcting it because minus zero does not exist in math, and math is context here, but I'm practical with this. I'm ok as long you're correcting it.

BTW, how are you doing replicating my second bug issue, where custum window do not report correct width while window is maximized and inactive? Did you follow my testbed?


Last edited by Krumelure; 05/06/08 06:47 PM.
Krumelure #200441 05/06/08 07:10 PM
Joined: Dec 2002
Posts: 2,962
S
Hoopy frood
Offline
Hoopy frood
S
Joined: Dec 2002
Posts: 2,962
Quote:
I didn't tell you what kind of guy you are, but what kind you cannot be. Your flexible relationship with presision gave me another confirmation you're not a math guy.
Normally I don't accept Wikipedia as an authority in math or any sciene, but when it confirm my statement so clearly allready in the second statement I could make an exception.

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.

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.


Spelling mistakes, grammatical errors, and stupid comments are intentional.
Krumelure #200444 05/06/08 07:55 PM
Joined: Jan 2003
Posts: 2,523
Q
Hoopy frood
Offline
Hoopy frood
Q
Joined: Jan 2003
Posts: 2,523
Putting aside your preposterous conclusions about my math-guyhood, negative zero very much exists in mathematics, it's just not distinct from positive zero: they are both zero. The first Wikipedia article I linked says the same thing in the second sentence (and if you think it confirms your statement, I suggest you re-read it, although I suspect that will automatically invalidate the article, non-authoritative as it is). I'm genuinely curious as to which authoritative sources claim that -0 is undefined in mathematics.


/.timerQ 1 0 echo /.timerQ 1 0 $timer(Q).com
Krumelure #200447 05/06/08 08:33 PM
Joined: Apr 2004
Posts: 871
Sat Offline
Hoopy frood
Offline
Hoopy frood
Joined: Apr 2004
Posts: 871
Originally Posted By: Krumelure
[..] but I'm practical with this. I'm ok as long you're correcting it.

phew! so glad you approve. we almost had a major crisis here.


Saturn, QuakeNet staff
Joined: Jun 2008
Posts: 12
K
Pikka bird
OP Offline
Pikka bird
K
Joined: Jun 2008
Posts: 12
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.

Krumelure #200455 05/06/08 09:58 PM
Joined: Oct 2003
Posts: 3,918
A
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
Krumelure:

the $calc(0 / 0) issue has been reported before. A discussion ensued. The conclusion was that mIRC is not Mathematica, MATLAB or Maple. mIRC doesn't care about "mathematical correctness" or axioms of whatever real space you seem to. You see, in case you missed it, mIRC is an IRC client. The scripting language is used for IRC. As such, mIRC cares about the most natural representation of the math operations in the context of the IRC medium. In the case of -0, 0 is the better representation. However, in the case of 0 / 0, most scripters and users would expect the output to be "0", not "infinity", or "NaN" like so many broken Javascript pages display. Given the context of most $calc operations (%nicks / %total_nicks, %sent_bytes / %total_bytes, etc.). This would be counterintuitive, not intuitive, and intuition is more important than mIRC getting 100% on a math test.



- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
argv0 #200465 06/06/08 01:51 AM
Joined: Jun 2008
Posts: 12
K
Pikka bird
OP Offline
Pikka bird
K
Joined: Jun 2008
Posts: 12
I do realize mIRC is an IRC client. Pardon yourself for stating the obvious. mIRC use math. mIRC needs math. And mIRC's scripts don't only need math as a tool but even for it's own good. There are no reason why the math should not be correct. (I can deal with decimal errors and won't complain about such. Decimals to a real math guy is only a matter og chosen accuracy). With minus zero and zero as a result from dividing by zero there is a completely different story. Here mIRC breaks against the very foundation of math.

And let's check if it's true that dividing by zero gives zero is really what's intuitive...

1 / 1 = 1
2 / 2 = 1
X / X = 1
Banana / Banana = 1
...
0 / 0 =

You fill it in, mate.

I can't reply precisely to your examples where it looks like you want zero when dividing something by zero motivated it's is more meaningfull than NA or 1. This is because it doesn't clearly show this is the case. In fact, quite the oposite. If you want a relationship between actual nicks and total nicks ever, and both are zeros, it makes alot of sense to get 1. Just as it is with 3 nicks and 3 nicks total, it tells you that of all nicks that is here now equals total nicks ever been here. With other words: we are at 100% of total. Just the same as with downloading bytes. If zero of zero, you have downloaded 100% of a file. With zero divided by zero was zero it shouldn't be possible to transfer zero byted files. Since we know this in fact is possible, another principle must be used for DCC, but there was a time when mIRC's DCC was not able to transfer files without data.

So, if you're not able to come up with some examples that support your view, or give a richer explaination that show your example support your view, I cannot escape the conclusion: you must share my view on this. That is if you're a reasonable guy. That's not a given.

If we solve this problem perfectly we would do it by an exception handler, where the user himself can chose what should happend when dividing by zero. This handler could have the result of 1 as default. They who live in another world than I do, could change this to zero.

Why the denominator is more important than numerator in division, I save for another post, when someone walks into my trap with the most obvious, but invalid, objection. You have been warned.


Written but not read,

Kru MacLure

Krumelure #200488 06/06/08 08:31 AM
Joined: Oct 2003
Posts: 3,918
A
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
0 / 0 = 0.

%sent = 0 | %total = 0
echo - You sent $calc(%sent / %total * 100) $+ % of the file

Pick one:

You sent 100% of the file
You sent NA% of the file
You sent 0% of the file

Only one of them is accurate. How much of a file have you sent if you've sent no files? None of it-- 0%. Makes sense to me.

Similarly:

I am opped on $calc($chan(0,o) / $chan(0) * 100) of the channels I'm on

Pick one:
I am opped on 100% of the channels I'm on
I am opped on NA% of the channels I'm on
I am opped on 0% of the channels I'm on

Once again, 100% would mean "all", and if you're not on any, you're not opped on any-- intuitively the answer is "none", or "0%".

If you want to be pedantic, you could argue that "all of the channels" is just as meaningful as "none of the channels"-- in which case you would be admitting that 0 is *equally* valid an answer as 1-- so please, make that claim.

Of course, the result 1 does fit into this scenario:

%sent = 0 | %timediff = 0
I am sending data at a rate of $calc(%sent / %timediff) bytes per second

Pick one:

I am sending data at a rate of 1 bytes per second
I am sending data at a rate of NA bytes per second
I am sending data at a rate of 0 bytes per second

In this case, the winner is once again 0. 1 isn't even sensical here. You could claim that NA is valid in this case-- it is the most valid of the above examples. However it's important to realize that in *all* scenarios described above 0 is a reasonable value. 1 works sometimes and fails miserably other times. NA works decently but makes the result seem more ambiguous than a scripter would desire-- forcing them to handle the 0/0 case when they usually don't need or want to. This is likely why 0 was chosen over 1 or NaN/NA.. it almost always makes a good amount of sense.


These are but few of the examples. The theoretical meaning of 0/0 does not apply to the semantic meaning in practical situations. Khaled designed $calc to be easy to use in a case where most scripters who use mIRC are not familiar with programming or mathematics and most likely don't even care what "NaN" means or why 0/0 is not truly 0. To them it makes sense. It is done intentionally to reduce the amount of input handling someone would need to do in the majority case while giving reasonable results. Most scripters don't want to handle exceptions. That's why they're scripting in mIRC and not some other language. This simplicity is seen not just in $calc, but all across mIRC. This is absolutely *not* against the fundamentals of the language-- in fact it is quite at the core of the purpose of the language.



- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
argv0 #200491 06/06/08 12:10 PM
Joined: Jun 2008
Posts: 12
K
Pikka bird
OP Offline
Pikka bird
K
Joined: Jun 2008
Posts: 12
argv0{
0 / 0 = 0.

echo - You sent $calc(%sent / %total * 100) $+ % of the file

Pick one:

You sent 100% of the file
You sent NA% of the file
You sent 0% of the file
}


I see. You want 0 / 0 to be 0.

Then you will get correct answer for all positive values of %total, but now if %total is zero, then you get wrong answer if 0 / 0 = 0.

If 0 / 0 = 1, you will get correct answer for all positive values of %total, but also when %total is zero. If the file does not hold data, you have sent 100% of the file when you have sent 0 bytes of it.

Conclusion:

Your examples support my view that 0 / 0 = 1 is more meaningful than if 0 / 0 = 0.


Krumelure #200493 06/06/08 01:04 PM
Joined: Oct 2003
Posts: 3,918
A
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
I'm not sure where you learned your logic, but the statement "0/0=1 is more meaningful than 0/0=0" cannot be proven by example. In any case, my last example specifically contradicts your conjecture that the value 1 is more meaningful than 0 which explicitly disproves your conclusion. You can never send '1 bytes per second' when %bytes = 0. That is a clearly invalid result, hands down. Perhaps you should re-read my post in its entirety rather than selectively choosing one of the three examples, and come to the proper conclusion.

As I said in my previous post, you could make the reasonable argument that the first example can be 100%. However, to claim that 0% is "wrong" is in itself wrong. Technically speaking, you have not sent any of the file. No packets belonging to the file have left your machine-- because there were none to send. You have therefore NOT sent 100% of the file because you have not sent ANY of the file-- it is theoretically impossible to make the claim that you sent something you did not send. In this case, 100% is equally meaningless to 0%, and that was my point. Neither of them are wrong, however. The only strictly *wrong* value in my examples comes from the "1 bytes per second" result of using 0/0 = 1, which you've completely ignored, by the way.

If you were smart you would realize that the conclusion is actually: "0 / 0 = 1 works in one specific case only: a subset of quantities represented as percentages". In every other scenario, it fails miserably. 0/0 meters per inch, 0/0 bytes per second, 0/0 pounds per dollar, etc. None of these values could be 1.


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
Krumelure #200495 06/06/08 01:23 PM
Joined: Jan 2003
Posts: 2,523
Q
Hoopy frood
Offline
Hoopy frood
Q
Joined: Jan 2003
Posts: 2,523
Originally Posted By: Krumelure
It sais perfectly clear that minus zero does not exist, when you combine it with the axiom of identity.
It would be better for you if you avoided this pseudo-rigorous, "math-guy", jargon nonsense. If you really want a formal approach, look up the additive inverse axiom (here's one link, here's another). In short, the additive inverse is defined for every element in an additive group. Now the additive inverse of a number A is commonly written as -A. Thus -0 is the additive inverse of 0. That does not mean -0 is distinct from 0, which is essentially what Wikipedia is saying, and what you keep misinterpreting: -0 does not exist as distinct from 0. Notice the italics: they are part of the sentence and not something for you to ignore. Wikipedia even included the equalities -0 = +0 = 0, which you also conveniently ignored. If the author thought -0 was invalid/undefined, (s)he wouldn't use it in a mathematical expression.

Originally Posted By: Krumelure
You cannot have two symbols that represent the same concept.
So is +5 incorrect too? +5 and 5 both represent the same thing. How about sqrt(1)? That represents the same concept as 1.

Originally Posted By: Krumelure
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.
So now you're saying that the actual problem is that the answer is not reduced (although the non-reduced answer is valid mathematically)? Which is it? Is the answer correct but merely not reduced or is it flat out incorrect?


/.timerQ 1 0 echo /.timerQ 1 0 $timer(Q).com
argv0 #200497 06/06/08 01:49 PM
Joined: Jun 2008
Posts: 12
K
Pikka bird
OP Offline
Pikka bird
K
Joined: Jun 2008
Posts: 12
argv0 {
I'm not sure where you learned your logic, but the statement "0/0=1 is more meaningful than 0/0=0" cannot be proven by example. In any case, my last example specifically contradicts your conjecture that the value 1 is more meaningful than 0 which explicitly disproves your conclusion. You can never send '1 bytes per second' when %bytes = 0. That is a clearly invalid result, hands down. Perhaps you should re-read my post in its entirety rather than selectively choosing one of the three examples, and come to the proper conclusion.
}

I can read you claim saying 0 + 0 = 1 cannot be proven by example, but this is just a claim, because I just proved it by example. If you've got op in 0 of 0 channels, you got op in all channels you're on: 100%. The fact that you're not op anywhere, is not relevant, because the question doesn't ask for whether or not you're an op somewhere, but the relationship between op and channels joined. If you are sending 0 bytes per 0 sec you are sending 1 byte at a time (supported by your own "objection" saying it's not possible to _send_ nothing). And finally, when you're saying 0 of 0 isn't 100% of a file, you are correctly interpretting what you're asking by your function. You ask: what is -bytes divided by bytes total-. The answer for any positive values holds -how great portion of a file has been sent-, but holds no information about how many bytes that actually leave your computer, as you like to think. Where you think you ask for number of bytes, you're actually asking for a proportion.

The conclusion is still unescapeable. 0 / 0 = 1 makes much more sense in all your examples. You get the values correct most of the times, but not when total is zero.

And remember, I already said that NA would be even more meaningful, but if there is a goal to give a numberical answer to any question, 1 is more meaninful than 0.


qwerty #200499 06/06/08 01:57 PM
Joined: Jun 2008
Posts: 12
K
Pikka bird
OP Offline
Pikka bird
K
Joined: Jun 2008
Posts: 12
qwerty {
That does not mean -0 is distinct from 0, which is essentially what Wikipedia is saying,
}

agree.

qwerty {
and what you keep misinterpreting:
}

No, qwerty, what I keep telling you is that -0 can never be a final answer. Try to read me well.

qwerty {
So is +5 incorrect too?
}

Yes!

qwerty {
So now you're saying that the actual problem is that the answer is not reduced
}

No, that's what I've been saying all from the start. -0 cannot exist, in a final answer. Let me remind you: When mirc yells sin(Pi/1) is -0, it's a wrong answer.

Are you going to continue trying this escape route pretending you have not understood the problem?


Krumelure #200500 06/06/08 02:13 PM
Joined: Jan 2003
Posts: 2,523
Q
Hoopy frood
Offline
Hoopy frood
Q
Joined: Jan 2003
Posts: 2,523
Quote:
No, qwerty, what I keep telling you is that -0 can never be a final answer. Try to read me well.
If you want to be read well, you should write well. In response to Khaled, you said
Quote:
You would stood safer if you said you're correcting it because minus zero does not exist in math, [...]
You had never said anything about a "final answer" up to that point (which was your 3rd post in this thread). The "final answer" is more recent nonsense that you came up with in your reply to starbucks_mafia. You have been pretty clearly suggesting that -0 is inherently invalid, not just that it's not as reduced as possible.

Anyway, I've done everything in my powers to get my point across, hoping that it was just a misunderstanding on your part. I now suspect that you've already got the point but your ego won't let you acknowledge this. This thread has already gone too far, so this is the last post from me in it.

Last edited by qwerty; 06/06/08 02:45 PM.

/.timerQ 1 0 echo /.timerQ 1 0 $timer(Q).com
Page 1 of 2 1 2

Link Copied to Clipboard