|
|
|
|
|
Joined: Aug 2007
Posts: 334
Pan-dimensional mouse
|
OP
Pan-dimensional mouse
Joined: Aug 2007
Posts: 334 |
im almost certain this has been suggested b4 but...
I think mirc should have switch statements, arrays and for loops
mainly because they are more efficient than their counter-parts
Last edited by foshizzle; 26/07/08 04:59 AM.
This is not the signature you are looking for
|
|
|
|
|
Joined: Oct 2003
Posts: 3,918
Hoopy frood
|
|
Hoopy frood
Joined: Oct 2003
Posts: 3,918 |
This *has* indeed been suggested before. Instead of wondering next time, use the Search. I love suggestions that blindly tout "efficiency" as the motivation.. Do you really know the efficiency difference of a case switch versus an if statement, or a while loop versus a for loop? Have you implemented these features yourself in an interpreter and benchmarked the varying results? Can you provide us with said "more efficient" implementation as well as the benchmark results? If not, why would you claim it's more efficient? How did you come upon such a conclusion? The truth is, for loops aren't "more efficient" and neither are switch cases-- those are just syntactic sugar, and mIRC already has enough of that. The only thing that would potentially be more efficient from language construct support would be "arrays". But the thing about arrays is that they sort of already exist in various forms, most efficiently as string tokenization ($gettok on a %var) followed by the use of Hash Tables (hash tables are slightly less efficient than true arrays but probably moreso than dynamic variables-- this is an assumption, it could be the other way around but that doesn't really change the point). However, anyone who implies that arrays don't exist in mIRC doesn't understand what an array is to begin with. The only difference would be syntax in construct vs. function call-- again, not exactly a very good justification. I also can't vouch for the efficiency gain in switching from string tokenization / dynamic vars / hash tables to a builtin first-class array type because I have no way of benchmarking the results. Making such a claim would be impossible to prove one way or another. It might be more efficient, it might not-- it's definitely not guaranteed. Changes for the sake of change is simply a bad idea. This is really just suggesting a different way to skin a cat. There would probably be little actual benefit from any of these changes.
- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
|
|
|
|
|
Joined: Aug 2007
Posts: 334
Pan-dimensional mouse
|
|
OP
Pan-dimensional mouse
Joined: Aug 2007
Posts: 334 |
i know u can achieve arrays in mIRC but its slow.. and i like my eye candy 
This is not the signature you are looking for
|
|
|
|
|
Joined: Oct 2003
Posts: 3,918
Hoopy frood
|
|
Hoopy frood
Joined: Oct 2003
Posts: 3,918 |
It's slow? How do you qualify that statement?
Arrays are not much slower than the rest of the engine, and implementing them natively in mIRC is not guaranteed to make anything faster. In fact, the slowness of mIRC's interpreter comes mostly from the fact that it's being interpreted, not from the efficiency of language features, so you're not likely to see much of a speed increase with native array types even if there is one.
- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
|
|
|
|
|
Joined: Aug 2007
Posts: 334
Pan-dimensional mouse
|
|
OP
Pan-dimensional mouse
Joined: Aug 2007
Posts: 334 |
i know that..(about mirc's interpretness)
but its gotta be a little faster than writing your own script
built in commands are almost if not always faster
Last edited by foshizzle; 26/07/08 05:36 PM.
This is not the signature you are looking for
|
|
|
|
|
Joined: Aug 2007
Posts: 334
Pan-dimensional mouse
|
|
OP
Pan-dimensional mouse
Joined: Aug 2007
Posts: 334 |
I also think $atan2 should be implemented.. its a very handy feature when trying to find angles
This is not the signature you are looking for
|
|
|
|
|
Joined: Oct 2003
Posts: 3,918
Hoopy frood
|
|
Hoopy frood
Joined: Oct 2003
Posts: 3,918 |
atan2 {
var %y = $1, %x = $2, %z = $1 / $2
if (%x == 0) {
if (%y > 0) return $calc($pi / 2)
if (%y == 0) return 0
else return $calc($pi / -2)
}
if ($abs(%z) < 1) {
var %atan = $calc(%z / (1 + 0.28 * (%z ^ 2)))
if (%x < 0) return $calc(%atan $iif(%y < 0, -, +) $pi)
}
else {
var %atan = $calc(($pi / 2) - %z / (%z ^ 2 + 0.28))
if (%y < 0) return $calc(%atan - $pi)
}
return %atan
}
edit: the last %atan = was changed-- replaced "$pi" with "($pi / 2)"
Last edited by argv0; 26/07/08 09:18 PM.
- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
|
|
|
|
|
Joined: Aug 2004
Posts: 7,252
Hoopy frood
|
|
Hoopy frood
Joined: Aug 2004
Posts: 7,252 |
shouldn't the initial setting of %z be $calc($1 / $2) ?
|
|
|
|
|
Joined: Aug 2007
Posts: 334
Pan-dimensional mouse
|
|
OP
Pan-dimensional mouse
Joined: Aug 2007
Posts: 334 |
This is not the signature you are looking for
|
|
|
|
|
Joined: Jan 2004
Posts: 162
Vogon poet
|
|
Vogon poet
Joined: Jan 2004
Posts: 162 |
A case-alike method is:
var %food = $2
goto %food
:bread | return 2
:apple | return 0.3
:choco | return 1
:milk | return 1.2
:%food | return unknown
or token method
var %food = $2, %country = $3, %fc = $+(%food,.,%country)
goto %fc
:bread.uk | return 2
:bread.us | return 1.3
:apple.uk | return 0.3
:apple.us | return 0.25
:choco.uk | return 1
:choco.us | return 0.85
:choco.nl | return 1.05
:milk.uk | return 1.2
:%fc | return unknown
These :labels (and their tokens) eliminate whole (nested) if elseif chains. There are much less curly braces. Most of the code is lined up to the left. When enough cases and/or subcases, I use this method. It's short, easy, overviewable, and, regarding efficiëncy and speed, certainly not worthy different.
|
|
|
|
|
Joined: Apr 2004
Posts: 759
Hoopy frood
|
|
Hoopy frood
Joined: Apr 2004
Posts: 759 |
you can even ident it:
alias tid {
var %x $1
goto %x {
:playbar {
var %x = $calc(2 % 3)
return %x
}
:playoptions | return 1
:noid {
var %x = "NOID"
goto break
}
:%x | var %x = %x + 1
}
:break
return %x
}
*quick and dirty alias before someone moans Fact is though you explitly need a break label to prevent cascading and very sugaring it's not. Argv0 makes valid points in that the only benefit is syntactic sugar. In most (if not all) languages for and switch are actually slow and compile more machine code as there counter parts would have. Still, i am a sucker for syntactic sugar so i'd still love for/switch/foreach statements.
$maybe
|
|
|
|
|
|
|
|
|
