mIRC Home    About    Download    Register    News    Help

Print Thread
#227653 17/11/10 05:46 PM
Joined: Jul 2006
Posts: 4,186
W
Wims Offline OP
Hoopy frood
OP Offline
Hoopy frood
W
Joined: Jul 2006
Posts: 4,186
Code:
//var -s %a 12 % 0,%a $calc(12 % 0)

Quote:
* Set %a to 12 % 0
-
* Set %a to 0


When dividing by 0 or using modulo 0, variable routine doesn't return 0.

Tested on mIRC 7.15

Last edited by Wims; 17/11/10 06:00 PM.

#mircscripting @ irc.swiftirc.net == the best mIRC help channel
Joined: Jun 2007
Posts: 933
5
Hoopy frood
Offline
Hoopy frood
5
Joined: Jun 2007
Posts: 933
What output do you get then? Because it does return 0 for me.
Apart from that, it greatly surprises me that mIRC returns 0 for division by 0. crazy

Joined: Jul 2006
Posts: 4,186
W
Wims Offline OP
Hoopy frood
OP Offline
Hoopy frood
W
Joined: Jul 2006
Posts: 4,186
It's a convention, there are several long thread about that, it would cause more problem to halt with an error.


#mircscripting @ irc.swiftirc.net == the best mIRC help channel
Joined: Dec 2002
Posts: 253
T
Fjord artisan
Offline
Fjord artisan
T
Joined: Dec 2002
Posts: 253
division by zero is not possible in math which makes perfect sense why a mathematical equation that is not possible to be treated as plain text rather than implement a false report like returning 0. $calc does it for conveniance to avoid returning an error and halting a script in the case of division by 0

Joined: Jun 2007
Posts: 933
5
Hoopy frood
Offline
Hoopy frood
5
Joined: Jun 2007
Posts: 933
Originally Posted By: Talon
$calc does it for conveniance to avoid returning an error and halting a script in the case of division by 0

I understand that, but then it would make much more sense to return $null instead, imo.
But let's stay on topic. Wims still hasn't answered my question.

Joined: Jul 2006
Posts: 4,186
W
Wims Offline OP
Hoopy frood
OP Offline
Hoopy frood
W
Joined: Jul 2006
Posts: 4,186
I did, I edited my first post

Talon, sure $calc do it for conveniance, but we use the var feature expecting it will work the same, the behavior is different so it's inconsistent.


#mircscripting @ irc.swiftirc.net == the best mIRC help channel
Joined: Dec 2002
Posts: 253
T
Fjord artisan
Offline
Fjord artisan
T
Joined: Dec 2002
Posts: 253
same expression yeilds the same result as far back as I have versions to test it. Looks pretty consistant to me.

Joined: Jul 2006
Posts: 4,186
W
Wims Offline OP
Hoopy frood
OP Offline
Hoopy frood
W
Joined: Jul 2006
Posts: 4,186
It has nothing to do with previous version, it's not because a behavior is the same on previous version that the behavior is correct.


#mircscripting @ irc.swiftirc.net == the best mIRC help channel
Joined: Oct 2004
Posts: 8,330
Hoopy frood
Offline
Hoopy frood
Joined: Oct 2004
Posts: 8,330
The fact that /var can do some math does not mean it can do everything that $calc() does. Just using //var %a = 1 + 2 + 3 will fail as well. That is simply a limitation of /var and isn't a bug. I'm not sure that there is any good reason to extend /var's mathematical abilities when it's just as easy to include $calc(). If you think it should be extended, then that's a feature request rather than a bug report. smile


Invision Support
#Invision on irc.irchighway.net
Joined: Jul 2006
Posts: 4,186
W
Wims Offline OP
Hoopy frood
OP Offline
Hoopy frood
W
Joined: Jul 2006
Posts: 4,186
Quote:
The fact that /var can do some math does not mean it can do everything that $calc() does. Just using //var %a = 1 + 2 + 3 will fail as well.
I never said that nor I want the feature to be extended (pointless as you said, just use $calc) but :
Quote:
That is simply a limitation of /var and isn't a bug
The fact that variable's mathematical abilities doesn't return the same result as $calc for the same expression is a limitation of /var and so it's not a bug ? What are you talking about.. ?

It is expected that both methods return the same results.
If $calc was throwing an error when dividing by 0, wouldn't you expect the same thing happening when dividing by 0 with variables ?
When something unexpected happens, it's a bug for me.


#mircscripting @ irc.swiftirc.net == the best mIRC help channel
Joined: Oct 2004
Posts: 8,330
Hoopy frood
Offline
Hoopy frood
Joined: Oct 2004
Posts: 8,330
/var is limited in what it can calculate. Anything it cannot calculate is treated as text. That's a limitation, not a bug. 12 % 0 isn't calculating incorrectly in /var... it's just being treated as text because /var doesn't support % in the calculation. It's the same as the example I showed with 1 + 2 + 3, where it would set the variable to that instead of to 6.

A bug is something that is not working as intended. Since /var is working as intended (i.e. it has very basic math support, but % isn't supported), then it's not a bug regardless if you think it should support that. As said, if you think % should be supported in /var, then it's a feature request to expand what /var can handle mathematically. It isn't as if /var is performing some incorrect calculation that is different than $calc()... it just isn't performing any calculation at all and treating it as text. That's simply how /var is supposed to work... if it doesn't think it's a basic math operation, then it treats it as text (i.e. it's working as intended).


Invision Support
#Invision on irc.irchighway.net
Joined: Oct 2003
Posts: 3,918
A
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
IMHO this is inconsistent behaviour regardless of how division by zero should work.

If A % B returns value C, then $calc(A % B) should be equivalent to var %var = A % B. Furthermore, if A and B are both numeric, mIRC should not return a non-numeric return value.


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
Joined: Oct 2003
Posts: 3,918
A
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
Originally Posted By: Riamus2
/var is working as intended (i.e. it has very basic math support, but % isn't supported)


% is supported in /var:

Code:
/var -s %x = 6 % 4


%x becomes 2 in the above statement. That is what I call "support". The fact that it doesn't work properly for all inputs (namely 0) doesn't mean it's "not supported", that means it's a bug.

Common sense would dictate that if A % B works in /var, you should expect A % B to function as it does in $calc. Otherwise you have inconsistent behaviour ($calc does X, /var does Y) which by definition defies standard expectations. Therefore A % 0 does not do what someone would reasonably expect it to.


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
Joined: Oct 2003
Posts: 3,918
A
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
To expand on the subject, this is from the help:

Originally Posted By: mirc.hlp
And you can perform the following operations on variables when using the equal sign:

%x = 5 + 1
%x = 5 - %y
%x = %x * 2
%x = %z / $2
%x = $1 % 3
%x = 2 ^ %w

You can only perform a single operation in an assignment at this time.

You can also use the $calc() identifier which allows you to perform complex calculations.


From the language used, I interpret this as follows:

  • Any variable declared in the form A <op> B where A and B are *numeric* values should result in the code being treated as a mathematical calculation. Numeric values include 0, and can be variables (%z where %z is a number including 0).
  • $calc() is an alternative identifier to accomplish calculations, and therefore $calc() should maintain a SUPERSET of the %x = A <op> B behaviour. Namely, assuming both A and B are numeric, %x = A <op> B should function the same as $calc(A <op> B), since it is documented as an alternative way to specify these calculations.


The help file therefore:

  • Has explicit support for A % B
  • Leaves A / 0 and A % 0 behaviour undefined, however:
  • Uses an example of %z / $2 in which $2 could reasonably expected to be a numeric value such as 0, or even $null. Given that it's posed as an example, the expectation is that this will still work as a calculation.
  • (Implicitly) refers the scripters to $calc() for the behaviour of these calculations.


I think it's pretty clear that there is an inconsistency here.


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
Joined: Jul 2006
Posts: 4,186
W
Wims Offline OP
Hoopy frood
OP Offline
Hoopy frood
W
Joined: Jul 2006
Posts: 4,186
You replied two times making statements about something you don't know, this is very frustrating.
Please stop doing so, please triple check your statements before clicking the submit button.


#mircscripting @ irc.swiftirc.net == the best mIRC help channel
Joined: Oct 2004
Posts: 8,330
Hoopy frood
Offline
Hoopy frood
Joined: Oct 2004
Posts: 8,330
Originally Posted By: Wims
You replied two times making statements about something you don't know, this is very frustrating.
Please stop doing so, please triple check your statements before clicking the submit button.


And you don't make mistakes? I've seen you do so as well. So don't be rude. Yes, I should have checked other numbers, but as it only said that $calc and /var were different for those two examples, I didn't think to. If the post had ignored $calc altogether and just said that /var %a = 4 % 0 and /var %a = 4 % 2 don't calculate the same, the mistake wouldn't have been made. In any case, being rude about a mistake doesn't help anything.

@argv0 - Ok, I tested just the original examples, which didn't mention it worked without it being 0. With clarifying that it works without 0, then yes, it's a bug.


Invision Support
#Invision on irc.irchighway.net
Joined: Jul 2006
Posts: 4,186
W
Wims Offline OP
Hoopy frood
OP Offline
Hoopy frood
W
Joined: Jul 2006
Posts: 4,186
Of course I do, but if I decided to be rude (I apologize) it's because it's not the first time I noticed this from you.
People make mistake, but they don't answer to a report stating it's not a bug with wrong statements.
Again, sorry, but I did that hoping things like that won't happen anymore


#mircscripting @ irc.swiftirc.net == the best mIRC help channel
Joined: Dec 2002
Posts: 5,490
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,490
Thanks this has been fixed for the next version. This issue also affected / which has also been fixed.


Link Copied to Clipboard