//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...
alias add {
var %retval | var %stepsum | var %carry 0
var %num1 $1 | var %num2 $2
while (%num1 != $null) || (%num2 != $null) {
set %setsum $calc(%carry + $right(%num1, 1) + $right(%num2, 1))
set %num1 $left(%num1, -1)
set %num2 $left(%num2, -1)
if (%setsum >= 10) { set %carry 1 | dec %setsum 10 }
else { set %carry 0 }
set %retval %setsum $+ %retval
}
if (%carry) { set %retval 1 $+ %retval }
return %retval
}
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]
Also on another topic possible bug , I can't get $not to work correctly returns 4294967193.
mIRC's binary operations are 32-bit.
1/0 on some os returns 0 and some returns 1. 1/0 is still undenfine or $null.
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
odd, if $calc(1 / banana) returns 0 then shouldnt $calc(1 +d 3) return 0.
Unless because the d is in the same parameter as the addition sign. This might cause everything after the first parameter to become invalid, returning only the first parameter, 1.
looks like there's a lot more happening here than it seems:
$calc(1 -+-- 2) -> 3
$calc(1 -+- 2) -> -1
$calc(1 -/- 2) -> 1
$calc(1 -/-- 2) -> 0
$calc(1 ++--++-- 2) -> 3
$calc(1 +++--++-- 2) -> -1
$calc(1 ++--++--/ 2) -> 0
some weird results
would be less confusing if every invalid operator was treated as such, and caused itself and the rest of the expression to be ignored
Weird results indeed. I'm not sure if this is part of what you were pointing out, but plus and minus signs should be chainable. However mIRC is still getting the wrong values for some of the calculations you gave. ie.
$calc(1 -+-- 2) -> 3 (should be -1)
$calc(1 -+- 2) -> -1 (should be 3)
$calc(1 -/- 2) -> 1 (should be an error)
$calc(1 -/-- 2) -> 0 (should be an error)
$calc(1 ++--++-- 2) -> 3 (correct)
$calc(1 +++--++-- 2) -> -1 (should be 3)
$calc(1 ++--++--/ 2) -> 0 (should be an error)
mIRC appears to incorrectly treat the additional plus signs with the same behaviour as if they were minuses, whereas they should all be discarded from the calculation.
Actually, looking at some of those numbers logically, they seem correct.
Assuming that + and - = cancel, and - and - = +
It also seems that mIRC takes the last extra minus sign and assumes it is the +- indicator on the last number (2 in this case).
$calc(1 -+-- 2) -> $calc(1 - -2) -> 3
$calc(1 -+- 2) -> $calc(1 - 2) -> -1
$calc(1 ++--++-- 2) -> $calc(1 + -2) -> -1 (wrong)
$calc(1 +++--++-- 2) -> $calc(1 ++ -2) -> $calc(1 + -2) -> -1
(It is hard to know the order of operations that mIRC uses with the extra + and -.
-genius_at_work
A plus and a minus don't cancel each other out though. Once a minus is introduced all of the plus signs can be ignored (ie. $calc(2 - 3) could also be expressed as $calc(2 + -3) or any number of pluses without changing the result)
$calc(1 +++--++-- 2) is equivalent to $calc(1 ---- 2) which might be easier to think of as this: $calc(1 - (-(-(-2)))). Another way to think about it is that two minuses equal a plus, so $calc(1 ---- 2) is the same as $calc(1 ++ 2), or more simply: $calc(1 + 2).
Regardless of whether it is mathematically correct or not, the answers mostly follow a logical pattern (as I described above). That fact could help determine why $calc is returning the values that it returns. I don't know if Khaled simply passes $1 from $calc to the programming language's calculation function, or if he parses it first.
In any case, it is just an observation.
-genius_at_work
$1- not $1 :P
And you are right. The way $calc is used might be through the language's calculations therefore there is very little he can do without parsing it first. And then there is parsing it, and just the way he parses it is a little bit dodgy.
There's no equivalent to $calc() in C++. It's being parsed either by Khaled's own code or via a third-party library. Most likely Khaled's own since there's nothing listed in the "Acknowledgements" section in the help file.
Okay so i'm thinking...
$calc(2 - 3) = $calc(+2-+3) = -1
$calc(2 + -3) = $calc(+2+-3) = $calc(+2-+3) = -1
$calc(1 +++--++-- 2) = $calc(+1+++--++--+2) = $calc(+1++-+-+-+2) = $calc(+1+-2) = $calc(+1-+2) = -1
$calc(1 ---- 2) = $calc(+1----+2) = $calc(+1+-+-+-+-+2) = $calc(+1+2) = 3
I think I arrived at this by placing a + to the left of every character that isn't +. But my brain is scrabled. I can't make sense of anything now. I do know that this was really a waist of time. mIRC has a ton of inconsitanies that wreck havoc when you start doing some complicated stuff. I mean just look at /set and /var...
/var <var> = 1 + 2 ; <var> = 3
/set <var> = 1 + 2 ; <var> = = 1 + 2
And they both call the /set alias too! WTF!?! (I'm starting another thread about this)
Actually, it is just $1 (in mIRC terms). $calc is an identifier, therefore $1 $2 etc are populated by the comma-delimited arguments within the () of $calc().
Example:
alias idtest { echo -a 1: $1 | echo -a 2: $2 }
//noop $idtest(1 + 2)
$calc only supports one argument (the equation). If you add a comma (to populate $2 $3 etc) you will get an invalid format error.
-genius_at_work