SRL Archive - Discussions and Debates

Ok, I've been seeing stuff like this way to much:

Result := (GetColor(532, 244) = 532462);

GetColor should only be used when you need to return the value of a color. It's extremely unnecessary (and slow) to create a canvas of the client and get a pixel off it when you only need to know if the color is there or not; instead you should use FindColor i.e.

Result := FindColor(P.X, P.Y, 532462, 532, 244, 532, 244);

The advantages of this are not only speed and efficiency, but there is also the adjustable parameters of where the color can be located, and, if you needed, a tolerance and/or spiral.

So please, stop using GetColor unless you are trying to return the color of a coordinate for auto color or something, otherwise don't use it, use FindColor.

'Tis true.

Scar's GetColor is just GetPixel I think, I don't think it creates a canvas (unless freddy is really stupid -.-).
And you know how FindColor works? It copies a bitmap of the client to a TBitmap (needs to create that one first), so if you just want to get one or two pixels, GetColor is faster.
For all other purposes you should use FindColor.

begin
  SetupSRL;
  Wait(2000);
  MarkTime(TM);
  if FindColor(x, y, 16777215,400, 314, 400, 314)then writeln('Yes');
  Writeln('FindColor took '+IntToStr(TimeFromMark(TM))+' ms');
  MarkTime(TM);
  if (GetColor(400, 314)= 16777215) then
    writeln('yes');
  Writeln('GetColor took '+IntToStr(TimeFromMark(TM))+' ms');
end.

Yes
FindColor took 0 ms
yes
GetColor took 0 ms

it doesnt matter. And even if it did, GetColor is 1 ms faster(im serious).

//Ran on login screen
begin
  SetupSRL;
  MarkTime(TM);
  if FindColor(x, y, 65535,310, 246, 310, 246)then writeln('Yes');
  wait(25);
  Writeln('FindColor took '+IntToStr(TimeFromMark(TM))+' ms');
  MarkTime(TM);
  if (GetColor(310, 246)= 65535) then
    writeln('yes');
  wait(25);
  Writeln('GetColor took '+IntToStr(TimeFromMark(TM))+' ms');
end.

Yes
FindColor took 32 ms
yes
GetColor took 31 ms

From: Markus
Scar's GetColor is just GetPixel I think, I don't think it creates a canvas (unless freddy is really stupid -.-).
And you know how FindColor works? It copies a bitmap of the client to a TBitmap (needs to create that one first), so if you just want to get one or two pixels, GetColor is faster.
For all other purposes you should use FindColor.

But, you are not trying to get pixels, you are checking to see if they are present.

From: pwnaz0r

begin
  SetupSRL;
  Wait(2000);
  MarkTime(TM);
  if FindColor(x, y, 16777215,400, 314, 400, 314)then writeln('Yes');
  Writeln('FindColor took '+IntToStr(TimeFromMark(TM))+' ms');
  MarkTime(TM);
  if (GetColor(400, 314)= 16777215) then
    writeln('yes');
  Writeln('GetColor took '+IntToStr(TimeFromMark(TM))+' ms');
end.

Yes
FindColor took 0 ms
yes
GetColor took 0 ms

That's a very inaccurate way to test that XD

you mean

Result := FindColor(P.X, P.Y, 532462, 532, 244, 532+1, 244+1);


Edit : nvm i dont know why GetColor is slower

From: SKy Scripter
Result := FindColor(P.X, P.Y, 532462, 532, 244, 532+1, 244+1);

No, because then you would create a 2 x 2 parameter…

From: IceFire908
But, you are not trying to get pixels, you are checking to see if they are present.



That's a very inaccurate way to test that XD

check again. i did on rs screen. getcolor is still faster

//Ran on login screen
begin
  SetupSRL;
  MarkTime(TM);
  if FindColor(x, y, 65535,310, 246, 310, 246)then writeln('Yes');
  wait(25);
  Writeln('FindColor took '+IntToStr(TimeFromMark(TM))+' ms');
  MarkTime(TM);
  if (GetColor(310, 246)= 65535) then
    writeln('yes');
  wait(25);
  Writeln('GetColor took '+IntToStr(TimeFromMark(TM))+' ms');
end.

Yes
FindColor took 32 ms
yes
GetColor took 31 ms

From: pwnaz0r
check again. i did on rs screen. getcolor is still faster

//Ran on login screen
begin
  SetupSRL;
  MarkTime(TM);
  if FindColor(x, y, 65535,310, 246, 310, 246)then writeln('Yes');
  wait(25);
  Writeln('FindColor took '+IntToStr(TimeFromMark(TM))+' ms');
  MarkTime(TM);
  if (GetColor(310, 246)= 65535) then
    writeln('yes');
  wait(25);
  Writeln('GetColor took '+IntToStr(TimeFromMark(TM))+' ms');
end.

Yes
FindColor took 32 ms
yes
GetColor took 31 ms

MarkTime, TimeFromMark, and Wait are all very inaccurate…

From: IceFire908
MarkTime, TimeFromMark, and Wait are all very inaccurate…

then what is the point of this thread? if all time procedures are inaccurate then there is no way to figure this out anyway.

You seem to be pulling points out of the air to cover yourself. If not even the timing in scar are accurate then its not worth it to worry about it. Anyways the inconsistency percentage should be the same for every run( every time i run, get color is 1 ms faster)

From: pwnaz0r
then what is the point of this thread? if all time procedures are inaccurate then there is no way to figure this out anyway.

You seem to be pulling points out of the air to cover yourself. If not even the timing in scar are accurate then its not worth it to worry about it. Anyways the inconsistency percentage should be the same for every run( every time i run, get color is 1 ms faster)

Think about it logically, your tests are inaccurate, there's no other way I can explain it lol?

var
  T, x, y: Integer;
  I: Integer;
begin
  T:= GetSystemTime;
  for I:= 1 to 100000 do
    FindColor(x, y, 16777215,400, 314, 400, 314);
  Writeln('FindColor took '+IntToStr(GetSystemTime - T)+' ms');
  T:= GetSystemTime;
  for I:= 1 to 100000 do
    GetColor(400, 314);
  Writeln('GetColor took '+IntToStr(GetSystemTime - T)+' ms');
end.

It seems that FindColor itself is actually slower…

And even when you do it like this v it's faster

var
  T, x, y: Integer;
  I: Integer;
begin
  T:= GetSystemTime;
  for I:= 1 to 100000 do
    booltostr(FindColor(x, y, 16777215,400, 314, 400, 314));
  Writeln('FindColor took '+IntToStr(GetSystemTime - T)+' ms');
  T:= GetSystemTime;
  for I:= 1 to 100000 do
    booltostr(GetColor(400, 314) = 16777215);
  Writeln('GetColor took '+IntToStr(GetSystemTime - T)+' ms');
end.

From: IceFire908
Think about it logically, your tests are inaccurate, there's no other way I can explain it lol?

then how can your results be accurate.

From: pwnaz0r
then how can your results be accurate.

Fundamentally, the logic we are dealing with (in theory) is faster because of the construct of the method.

Returning a boolean only requires a small amount of information to be gathered, FindColor, only checks if a color is present. It knows exactly what color it is looking for before it begins its operation; it only needs to say a simple 'yes' or 'no' that is fundamentally calculated faster and interpreted faster by SCAR because it does not use anything other than an assignment opposed to an '=' sign pointed out by SKy Scripter. On the other hand, GetColor does not know what color it is looking for before it begins its operation, it doesn't care, it only need to know a coordinate to pick a color at, but now, we have a different purpose, we have to depict the exact color we find and return it as a long integer that can range from -2,147,483,648 to 2,147,483,647 and use 4 bytes of memory (32 bits) apposed to only using the 0 to 1 (boolean) (1 byte) (8 bits) that FindColor uses, on top of that, we must compare it to yet another long integer value (our color we are going to compare the result to) and determine whether or not it is the same with the '=' sign and an assignment to return a true or false value, hence, FindColor(..): Boolean; , GetColor(..): LongInt;.

The amount of time you are arguing over is so minute that its not even worth bothering about…

From: mat_de_b
The amount of time you are arguing over is so minute that its not even worth bothering about…

my point exactly

To actually find the difference in times, you would most likely have to measure it in machine cycles, which I believe is not possible. (Something like a millionth of a millisecond?)


Pwnaz0r, I believe the reason he is saying it is inaccurate is because how much overhead it takes to get the system time, etc.

We have the weirdest arguments here sometimes :confused:

From: mat_de_b
The amount of time you are arguing over is so minute that its not even worth bothering about…

From: Tim0suprem0
We have the weirdest arguments here sometimes :confused:

Pwnaz0r, others, and myself are discussing what we think may or may not be true to come to a conclusion (or not) on the discussion topic to hopefully learn more about the subject. This is not an argument, this is a mutual discussion and anyone who has anything informational to add will, please do not come here only to post.

Wait, were not arguing? Damn.


Well, why doesn't someone make an awesome proc that uses one of them to do somthing so shizzfrizzling that it will make my over-sized head explode with all the awesome maths it will do.


EDIT: Cheesy pickup: "Wanna come back to my house and do some Maths? You can add the bed, subtract your clothes, divide your legs and we'll multiply."

[BANANA][LEFT]ar·gu·ment (är'gyə-mənt) pronunciation
n.

1. A discussion in which disagreement is expressed; a debate.
2. A quarrel; a dispute.[/LEFT][/BANANA]

No, it can be called an argument, anyways, I never said it was a bad thing.

From: Tim0suprem0
[BANANA][LEFT]ar·gu·ment (är'gyə-mənt) pronunciation
n.

1. A discussion in which disagreement is expressed; a debate.
2. A quarrel; a dispute.[/LEFT][/BANANA]

No, it can be called an argument, anyways, I never said it was a bad thing.

Nor have you added anything sensible to this thread, which brings me back to what I said, don't come here just to post.

Go back to what I posted. The difference is about four seconds, even when GetColor is using =. I think that proves that GetColor is faster…

From: bullzeye95
Go back to what I posted. The difference is about four seconds, even when GetColor is using =. I think that proves that GetColor is faster…

The tests you are using are inaccurate, on top of that, you are not balancing a lot of other things causing time affects.

You will see that if you run these two scripts separately the results will be the same:

var
  B: Boolean;
  T: LongInt;
  P: TPoint;
  I: Byte;
  
begin
  ClearDeBug;
  Wait(1000);
  T := GetSystemTime;
  for I := 0 to 254 do
  begin
    B := FindColor(P.X, P.Y, 16777215, 441, 198, 441, 198);
    Wait(1);
  end;
  WriteLn(IntToStr(GetSystemTime - T));
end.

var
  B: Boolean;
  T: LongInt;
  P: TPoint;
  I: Byte;
  
begin
  ClearDeBug;
  Wait(1000);
  T := GetSystemTime;
  for I := 0 to 254 do
  begin
    B := (GetColor(441, 198) = 16777215);
    Wait(1);
  end;
  WriteLn(IntToStr(GetSystemTime - T));
end.

Like what the hell is going on here?

Like, using GetColor or FindColor get a boolean, its got no real difference in the action, this is just, just somehow weird, how can people argue about thing like that? Its like same do you use standards or not.

If you're doing only one GetColor it shouldn't matter.. Certainly not with RS.

I think FindColor uses GetColor…
And who cares? The difference is 1 ms. Not even if we had to find a color thousand times, would we lose much time!

Just my opinion…

-Knives

program New;
var
  a, t, x, y : Integer;
begin
  t := GetSystemTime;
  for a := 0 to 1000 do
    GetColor(100, 100);
  WriteLn(IntToStr(GetSystemTime - t));
  Wait(1000);
  t := GetSystemTime;
  for a := 0 to 1000 do
    FindColor(x, y, 16777215, 362, 91, 362, 91);
  WriteLn(IntToStr(GetSystemTime - t));
end.

Result:

Successfully compiled
31
94
Successfully executed

don't make such lies :) GetColor is faster..
still it's a matter of what you like, FindColor looks stupid..
Don't tell people what to do and what not to do, that's what Developers are for ;)

Quite simplly, a call GetColor is faster than a call to FindColor. However, If you are looking for colors in an area, a call to FindColor is faster than multiple calls to GetColor.

var
  elapsed, a, i, x, y: Integer;
begin
 
  a:= 0;
  elapsed:= GetSystemTime;
  for i:= 0 to 100000 do
    if FindColor(x,y,$FFFFFF,200,200,200,200) then
      a:= a + 1;
  elapsed:= GetSystemTime - elapsed;
  Writeln('A='+IntToStr(a)+' Time:'+IntToStr(elapsed));
 
  a:= 0;
  elapsed:= GetSystemTime;
  for i:= 0 to 100000 do
    if GetColor(200,200) = $FFFFFF then
      a:= a + 1;
  elapsed:= GetSystemTime - elapsed;
  Writeln('A='+IntToStr(a)+' Time:'+IntToStr(elapsed));
  
end.

Successfully compiled
A=100001 Time:6453
A=100001 Time:1859
Successfully executed

You know what that means? Testing with one call to FindColor takes 0.06453ms, GetColor takes 0.01859ms. Don't even worry with those numbers, you can't even comprehend speeds that fast.
Call my tests inaccurate and I'll shoot you :sasmokin:

Ahh, finally a statement no one can say anything to, except for "cool", "yeah", "nice" :D

Btw Ben, you seem to be "smart" (xD) do you know when is "now" like how long time is it, is it one millisecond or how, like, its so weird… Should I try wikipedia or will BenPedia make more sence?

EDIT: oww, wikipedia didnt tell =/ waiting 4 ya ben..

EDIT EDIT: " Last edited by BenLand100 : Today at 09:27 AM." Am I correct that

Call my tests inaccurate and I'll shoot you

was the edit? :p

so GetColor is actually faster? lol.

Btw Ben, you seem to be "smart" (xD) do you know when is "now" like how long time is it, is it one millisecond or how, like, its so weird… Should I try wikipedia or will BenPedia make more sence?

what do you mean "now"? a millisecond is a 1000/th of a second. so count to a second, and divide it by 1000. and according to bens tests, GetColor is .04594 of a millisecond faster than findcolor. so thats roughly 1 second divided by 100, 000.

IceFire likes to bring up such minor-useful discussions :p

From: IceFire908

So please, stop using GetColor unless you are trying to return the color of a coordinate for auto color or something, otherwise don't use it, use FindColor.

From: Lorax

don't make such lies :) GetColor is faster..
still it's a matter of what you like, FindColor looks stupid..
Don't tell people what to do and what not to do, that's what Developers are for ;)

I have a feeling if I had said that I would've gotten flamed, thank you Lorax.

To be honest, I reallllly don't think this matters all that much.

The claw I know what a millisecond is -.- And that wasnt what I asked, I asked what is the time of this moment right here now? Is it 1 millisecond? Is it smaller?

It is infinitesimally small.

Thanks! Thats what I thought too, Its really confusing to think about it..

From: IceFire908
The tests you are using are inaccurate, on top of that, you are not balancing a lot of other things causing time affects.

You will see that if you run these two scripts separately the results will be the same:

var
  B: Boolean;
  T: LongInt;
  P: TPoint;
  I: Byte;
  
begin
  ClearDeBug;
  Wait(1000);
  T := GetSystemTime;
  for I := 0 to 254 do
  begin
    B := FindColor(P.X, P.Y, 16777215, 441, 198, 441, 198);
    Wait(1);
  end;
  WriteLn(IntToStr(GetSystemTime - T));
end.

var
  B: Boolean;
  T: LongInt;
  P: TPoint;
  I: Byte;
  
begin
  ClearDeBug;
  Wait(1000);
  T := GetSystemTime;
  for I := 0 to 254 do
  begin
    B := (GetColor(441, 198) = 16777215);
    Wait(1);
  end;
  WriteLn(IntToStr(GetSystemTime - T));
end.

You know wait(1) waits 16ms, right?

From: The Claw
so GetColor is actually faster? lol.

GetColor is both faster and requires less coding. ;)

GetColor is (apparently) faster to run.
It is also faster to program, and you don't need a variable :D There, you can save seconds by using GetColor :P

I have no valid arguments against all those mathmaticians above me, so I'll just stop now before I end up saying E = My^3

-Knives

From: Wizzup?
You know wait(1) waits 16ms, right?

Yes -.-

From: BenLand100
Quite simplly, a call GetColor is faster than a call to FindColor. However, If you are looking for colors in an area, a call to FindColor is faster than multiple calls to GetColor.

As with any research, to truly find an accurate unbiased answer you need different people supporting different solutions until an overall 'verdict' is announced. I think that what BenLand100 has stated in the above quote is true, I will add that perhaps we should search in larger parameters than 1x1 to return booleans (as proved with Jagex's trying to break stuff by moving things around by 1 pixel) which FindColor would be more efficient than multiple calls to GetColor, many of you might find that unnecessary though because a single pixel is already pretty stable.

From: King of Knives
GetColor is (apparently) faster to run.
It is also faster to program, and you don't need a variable :D There, you can save seconds by using GetColor :P

I have no valid arguments against all those mathmaticians above me, so I'll just stop now before I end up saying E = My^3

-Knives

[Offtopic] I thought it was E=MC²… [/Offtopic]

From: The Claw
what do you mean "now"? a millisecond is a 1000/th of a second. so count to a second, and divide it by 1000. and according to bens tests, GetColor is .04594 of a millisecond faster than findcolor. so thats roughly 1 second divided by 100, 000.

Now, an interesting concept… You understand that between every two points there is another point right? Well "now" is when you subdivide time so many times that you "can't" get a point between two points. Essentialy the fundamental unit of everything, called an infintessimal. Anything divided by an infintessimal equals infinity. Since an infintessimal is the smallest possible unit, and you can subdivide any two points, no matter how small, there must be an infinant number of infintessimals between any two points… Therefore, for all intensive purposes, an infintesimal change is the limit of a function as x approaches zero (any of you with calculus backgrounds) In otherwords, an infintessimal is the smallest possible number, greater than zero. So, the concept of now essentialy ranges from this instant, to the next infintessimal :sasmokin:If thats not confusing, you should apply to be God. ;)

From: BenLand100
Now, an interesting concept… You understand that between every two points there is another point right? Well "now" is when you subdivide time so many times that you "can't" get a point between two points. Essentialy the fundamental unit of everything, called an infintessimal. Anything divided by an infintessimal equals infinity. Since an infintessimal is the smallest possible unit, and you can subdivide any two points, no matter how small, there must be an infinant number of infintessimals between any two points… Therefore, for all intensive purposes, an infintesimal change is the limit of a function as x approaches zero (any of you with calculus backgrounds) In otherwords, an infintessimal is the smallest possible number, greater than zero. So, the concept of now essentialy ranges from this instant, to the next infintessimal :sasmokin:If thats not confusing, you should apply to be God. ;)

Maybe I will then, because thats not confusing at all, in fact it makes perfect sense ;) We've just done calculus at school.

Thats all fine, Apart from the fact that since infinity isnt a real number, you cant divide anything by it, or an infintessimal :spot: Otherwise, you could say that 1 second would = infinity infintessimal's, 1 minute would = infinity infintessimal's, and so on, since any two points divided by an infintessimal is infinity, as you said. the reason you cant divide something by infinity is because its a destination, not a value, if you know what I mean. it can never be defined, Since you can never reach it..and that would also make an infintessimal a destination, since you're not able to define it either and never will be able to. other than lim x -> 0. i'm sure you knew all this though ;)

so basically it is impossible to put a value on "now", because by the time you do, "now" was "before" :garfield: "soon" is one infintessimal away from "now" (ok we'll just take an infintessimel as a limit lol.)

heres one for you - why is the following proof incorrect? and dont google, try to figure it out yourself ;) -


should be easy enough considering my post lol.

From: BenLand100
Now, an interesting concept… You understand that between every two points there is another point right? Well "now" is when you subdivide time so many times that you "can't" get a point between two points. Essentialy the fundamental unit of everything, called an infintessimal. Anything divided by an infintessimal equals infinity. Since an infintessimal is the smallest possible unit, and you can subdivide any two points, no matter how small, there must be an infinant number of infintessimals between any two points… Therefore, for all intensive purposes, an infintesimal change is the limit of a function as x approaches zero (any of you with calculus backgrounds) In otherwords, an infintessimal is the smallest possible number, greater than zero. So, the concept of now essentialy ranges from this instant, to the next infintessimal :sasmokin:If thats not confusing, you should apply to be God. ;)

Thats simple maths that we need to apply daily at school..

well you just said that you can't divide by infinity since it's a destination…

yeah, you got it. was hoping it would have taken longer than that but its pretty obvious considering my post, i guess

Ben just got carried away since everyone always says he's really good at maths.

From: Lorax
well you just said that you can't divide by infinity since it's a destination…

1 / smallest number ever = inifinity, and that costs him alot of words.. ;)
At school we mainly use that to 'understand', as the teacher calls it, how formula's work.

If thats not confusing, you should apply to be God.

Not at all! I will apply for god if I get wizzy and fawkis private scripts xD Jk/Jk, but it is not confusing at all.. So, by a lol question of mine I caused a page long discussion of math :D

im not sure if this has already been explained correctly but here is the logic (if i can remember correctly) between these two.

GetColor is a call to the API GetPixel which gets a pixel from a DC or hDc (can't actually remember), this is fast when you need one pixel, as the Windows API gets the color directly from the window, FindColor, as to getting an exact pixel is slower because of two reasons: first it must copy the dc to a TBitmap, and second it uses scanlines and these have to be retrieved from the bitmap. So it's incorrect to use FindColor just for one row, because you are adding the overhead of a TBitmap and a scanline. now it would even be slower if you had a one pixel wide and 40 pixel tall area because you would have to get the whole row of pixels 40 times just to look at one pixel.

Holy crap! RsN just posted…

From: The Claw
Thats all fine, Apart from the fact that since infinity isnt a real number, you cant divide anything by it, or an infintessimal :spot: Otherwise, you could say that 1 second would = infinity infintessimal's, 1 minute would = infinity infintessimal's, and so on, since any two points divided by an infintessimal is infinity, as you said. the reason you cant divide something by infinity is because its a destination, not a value, if you know what I mean. it can never be defined, Since you can never reach it..and that would also make an infintessimal a destination, since you're not able to define it either and never will be able to. other than lim x -> 0. i'm sure you knew all this though ;)

i isn't a real number either ;) 1 second does contain infinity infintessimals, along with a minute, or any other value. Hence WHY you can't define it. Its like asking how many points are on a line segment, as compared to a line, each has infinity. Also the reason why PI continues on forever. Same idea with dividing by zero. How many groups of zero (taken as the mathmatical representation for a literal infintessimal) can you make of any number? As many as you want, or infinity ;) Calculus is just a really complex way to avoid dividing by zero, which you should already know since you mentioned limits :garfield:

As for your proof, think of it literaly: Infintiy is the "maximum" value possible, there is no such thing as 4 infinities, thus its mathmaticaly impossible to preform mathmatical operations on it, once you've hit infinity, you can go neither forward or backwards.

Edit: The difference between our two explinations is you see it as finite, I see it as flexible. Everything is possible ;)

Wait… that equation there, its not saying ∞ is equal to 1/4, but its saying that 1/4 is equal to ∞.

All I'm saying is: ∞ ≠ 1/4 , and , 1/4 ≠ ∞, for the simple fact that 1/4 is rational, and as soon as you add a ".00000000000000….000001" somewhere, it is no longer 1/4.


The human mind can't handle infinity, so lets stop arguing?

EDIT: Also, you can't do mathematical operations with ∞, because, for one, ∞ is simple a placeholder meant to say that "this won't end", and not an actual number (like, for intstance, you don't know if you mean an infinite number of decimal places, chairs, tables, zeros).

Okay let's just pretend that you can divide by 0 for a sec.

1 x 0 = 0.
2 x 0 = 0.
Therefore
1 x 0 = 2 x 0
Simplified(1 x 0 / 0 = 2 x 0 / 0)
1 = 2

From: BenLand100
i isn't a real number either ;) 1 second does contain infinity infintessimals, along with a minute, or any other value. Hence WHY you can't define it. Its like asking how many points are on a line segment, as compared to a line, each has infinity. Also the reason why PI continues on forever. Same idea with dividing by zero. How many groups of zero (taken as the mathmatical representation for a literal infintessimal) can you make of any number? As many as you want, or infinity ;) Calculus is just a really complex way to avoid dividing by zero, which you should already know since you mentioned limits :garfield:

As for your proof, think of it literaly: Infintiy is the "maximum" value possible, there is no such thing as 4 infinities, thus its mathmaticaly impossible to preform mathmatical operations on it, once you've hit infinity, you can go neither forward or backwards.

Edit: The difference between our two explinations is you see it as finite, I see it as flexible. Everything is possible ;)

i guess so :p

From: Kevin Wolf
Okay let's just pretend that you can divide by 0 for a sec.

1 x 0 = 0.
2 x 0 = 0.
Therefore
1 x 0 = 2 x 0
Simplified(1 x 0 / 0 = 2 x 0 / 0)
1 = 2

Hey I like annoying my friends with this. I keep saying how I either get infinity percent or 100% in tests that I haven't actually completed. (I know the answer is case 3). :p

1. 0/0 = 0 (0 divided by any number is 0) therefore 0%.
2. 0/0 = 1 (any number divided by the same number is 1) therefore 100% ;).
3. 0/0 = indeterminate (similar to undefined or infinity) therefore infinity %.

So yea… just wanted to join in your little maths game debate here. :p