Forums Bug Reports Possible $calc Bug?

//echo -a $calc(1 * (10^50)) returns 100000000000000010000000000000000000000000000000000
//echo -a $calc(2 * (10^50)) returns 200000000000000020000000000000000000000000000000000
//echo -a $calc(3 * (10^50)) returns 300000000000000020000000000000000000000000000000000
//echo -a $calc(4 * (10^50)) returns 400000000000000030000000000000000000000000000000000
//echo -a $calc(5 * (10^50)) returns 500000000000000000000000000000000000000000000000000
//echo -a $calc(6 * (10^50)) returns 600000000000000050000000000000000000000000000000000
//echo -a $calc(7 * (10^50)) returns 700000000000000090000000000000000000000000000000000
//echo -a $calc(8 * (10^50)) returns 800000000000000060000000000000000000000000000000000
//echo -a $calc(9 * (10^50)) returns 900000000000000030000000000000000000000000000000000
//echo -a $calc(10 * (10^50)) returns 999999999999999990000000000000000000000000000000000

I use mIRC v6.21 Khaled Mardam-Bey and Windows 98 second Edition.

While this is a bug, it's not with mIRC, but rather Windows, as the numbers that you're dealing with are so large they exceed the maximum calculation for a number using a 32 bit base (which is what Windows 95 - XP use.. NB: Excepting Windows XP Pro 64)

The largest number that works on 32 bit OS (which is what you're using) is equal to 2^56

This is, fairly obviously, going to be a smaller number than the 10^50 level that you used as your start point.

btw: 2^56 = 72,057,594,037,927,936
Seventy-two quadrillion fifty-seven trillion five hundred and ninety-four billion thirty-seven million nine hundred and twenty-seven thousand nine hundred and thirty-six.

For 64 bit OS's the number would be a lot larger, however, I don't have access to a system running a 64 bit OS at this time in order to figure it out.

Sorry, but it has nothing to do with your OS or even your CPU. I'm kind of curious about how you think a 56-bit number is the largest possible on a 32-bit base though. :p

mIRC in fact uses the 64-bit IEEE 754 'double' type to store numbers, which is integer-exact up to 2^53 or 9,007,199,254,740,992.

If you really need math on numbers that large it's possible to parse the math yourself, processing only one number at a time step-by-step, although this would take more CPU that just using $calc...

I got that number by using $calc(2^<N>), where I manually increased <N> until it got to the point where the number displayed via mIRC did not match that of manual calculations (pencil and paper).

damn, now that's devotion. I'd have just skipped to the next thread! lol

btk

Hurray for Windows Vista's $calc(2^1023) ? :p

To clarify my last post, here is an example alias...

Adds two integers: $add($str(2, 100), $str(2, 100)) returns 100 4's

How do you explain the bug //echo -a $calc(1/0) ?

Division by zero is not possible in mathematics. I believe Khaled changed the function of $calc to return 0 not to long ago.

Actually division by zero is more-or-less infinity, since you can constantly divide something into/by nothing and still have something... 'A' not divided still equals 'A', no matter how many times you don't divide it...

Also on another topic possible bug , I can't get $not to work correctly returns 4294967193.
1/0 on some os returns 0 and some returns 1. 1/0 is still undenfine or $null.


Here a puzzle for you.
You may have seen this little proof that 2=1:
a = x [true for some a's and x's]
a+a = a+x [add a to both sides]
2a = a+x [a+a = 2a]
2a-2x = a+x-2x [subtract 2x from both sides]
2(a-x) = a+x-2x [2a-2x = 2(a-x)]
2(a-x) = a-x [x-2x = -x]
2 = 1 [divide both sides by a-x]
You may doubt that 2=1. So, where is the mistake? Think about it

No thanks..I've got better things to do with my time.

Since a = x, then a-x is zero.
So when you divide both sides by [a-x], you're dividing by zero, and the result is "undefined" (not necessarily infinity).

As maroon pointed out, the 'problem' with this puzzle is in the assumption that a-x=1, when infact if a=x then a-x will always be 0...

2(a-x) = a-x [x-2x = -x]...
2/a-x = a-x/a-x [divide both sides by a-x]...
2/0 = 0/0 [substitution given the proof that when a=x, a-x will always be 0]

mIRC's binary operations are 32-bit.

I don't like this at all!!!

Division by zero should not return 0, or $null, or ANYTHING. It should generate an error. It upsets me that Java allows this too.

don't like that too but it should return $null since it's impossible

$null in $calc evaluates to zero, so $null and 0 would be equal. Saying $null in this case would not be a good indication of an error.

$calc(4 + $calc(1/0)) == $calc(4 + $null) == 4

Although this isn't much better....

$calc(4 + 1 / 0) == 0

It seems that $calc returns 0 for all invalid calculations, not just for divide by zero errors.

//echo -a $calc(1 / 0)
//echo -a $calc(1 / !)
//echo -a $calc(1 / -)
//echo -a $calc(1 / banana)
//echo -a $calc(1 /x 1)
//echo -a $calc(1 /! 1)
etc..


although... some just return the first value and ignore the invalid parts.

//echo -a $calc(1 +d 1)
//echo -a $calc(2 +d 4)
//echo -a $calc(4 -d 1)

-genius_at_work