$calc error - mIRC Discussion Forums

hi all, i see that $calc identifier have a bug.
When you write $calc(1/0), it returns 0 that is wrong.
1/0 is impossible. How do you resolve this problem?

Thx

Originally Posted By: Noot

hi all, i see that $calc identifier have a bug.
When you write $calc(1/0), it returns 0 that is wrong.
1/0 is impossible.

As far as I know, mIRC doesn't use it's own built calculator, but the system's calculator. So this could be MicroSoft's fault, not Khaled's.

I guess you wanted it to return something like, something in English. Like "not possible." Or not simply return anything at all.

Quote:

How do you resolve this problem?

Thx

You can't change the default $calc() identifier. So you'll have to make your own custom $calculate() identifier or so.

Best of luck with that.

-Neal.

Originally Posted By: LostShadow

As far as I know, mIRC doesn't use it's own built calculator, but the system's calculator.

You probably don't know much then. Where do you even get your "facts" from? You could not be more wrong.

Hint: if you don't know an answer, don't reply. I know your OCD makes it hard for you not to type out every single thought you have, but please, for the sake of civility, stop.

edit:

PS. this isn't a bug. Sure, it's the wrong answer, but its your script logic that is supposed to be responsible for guarding against "impossible" results like those. Infinity cannot be represented numerically, so 0 is substituted, because it makes the most sense (of other possible values)-- 0 or $null. This is an intended behaviour. If mIRC had exception handling, it would raise one. mIRC has :error, but that's really overkill-- most people probably don't want control flow to change just because they divided by 0. For most rational results regarding the world of IRC-- N/0 is "0". $null wouldn't be bad, I suppose...

Originally Posted By: argv0

Where do you even get your "facts" from?

Probably from what someone told me, and, for making the connection that mIRC uses the timestamp clock not from it's own clock, but the system's clock.

Quote:

I know your OCD

Close, autism.

-Neal.

Just about all software clocks use the system clock, so that's a moot point.

As for dividing by 0, like argv[0] said, just improve your script so it handles that possibility and either outputs an error message or else doesn't try to divide by 0 in the first place.

Yes, it really should return $null to indicate an error IMO.

i think so too, because detecting a div by 0 error would otherwise be too involved

Too involved?

Code:

if (%divisor == 0) { echo -a Error: Divide by 0 | return }

lolllllllllllll no

words fail me so i'll draw up an example

Code:

on *:text:!calc *:#:{ msg $chan the answer is: $calc($2-) }

now, show me how to easily detect if a division by 0 occurs

Code:

alias -l isdivzero { return $regex($1,/\d[^+\-*/]*/[ ()]*0++(?=[^1-9]|$)/) }
alias calc2 { return $iif($isdivzero($1),$null,$calc($1)) }

//echo -a $calc2(1 * 3 / 3 ^ 2 / ((00)) * 2) -> $null
//echo -a $calc2(1 * 3 / 3 ^ 2 / ((00002)) * 2) -> 0.333333
//echo -a $calc2(1 * 3 / 3 ^ 2 / ((0)) * 2) -> $null
//echo -a $calc2(1 / 0) -> $null
//echo -a $calc2((1) / 0) -> $null

Quote:

!calc 1/(1-1)

Ouch

Code:

alias -l isdivzero { 
  if (!$regex($1,/\d[^+\-*\^%/]*/[ ()]*0++(?=[^1-9]|$)/)) {
    if ($lf isin $regsubex($remove($1,$lf),//[^+\-*\^%/]*(\d++[^+\-*\^%/]*(?:[+\-*\^%/][^+\-*\^%/]*\d++\51*)+)/,$iif(!$calc(\t),$lf))) { return 1 }
  }
  else { return 1 }
}
alias calc2 { return $iif($isdivzero($1),$null,$calc($1)) }

That's nice, but I think we can all agree at this point that checking for divide-by-zero issues beforehand is non-trivial. In fact it requires you basically to implement your own $calc() just to verify the data before you pass it to the built-in one.

It might be slippery slope to request that what about doing 1/3? And getting .333333.

Couldn't we change it to .3 with a bar on top? Or underlined?

So, 1 + 1/3 returns 1.3.

You just have to have mIRC design an algorithm to check for divisions that trigger infinite sig figs.

Or what about.

The square root of negative 1? Make it return i. Or something fancy.

Or what about e ^ (pi) (i) to return -1, rather than whatever it currently returns.

And so and so forth.

The list continues..

If there was a symbol for infinity, couldn't we use that for the 1 / 0?

-Neal.

Yep. The first was meant to be a "simple" solution, the 2nd one I got a bit carried away with and forgot the purpose of making it in the first place!

What, no recursive descent parser?

$calc2(1 / (1 - 2 * 2 + 2 * 2)) = $null
$calc(1 / (1 - 2 * 2 + 2 * 2)) = 1

I appreciate the attempt, though, hixxy. It is much more productive than simply criticizing one's reasons for claiming the bug. I think, ideally, that checking for 0 divisors should be done alongside the calculation, since only at that point will there be an explicit value for the divisor. This could be reserved for a new, native calculate identifier, as well, so as to not destroy any backward compatibility with older scripts.

lol hixxy :*

$calc() also does things like evaluate variables/identifiers in cases such as $calc(1+$x), then there's $calc(0^-1) to worry about and such ;P

as starbucks said, detecting division by 0 involves almost exactly the same amount of work as re-creating $calc() using basic mathematical operations.. such as those offered in /set, which is no easy task! that's why i laughed at Riamus2's suggestion