AutoHotkey Community

I noticed that there are no such built-in functions as Min and Max.
I thought this is so obvious in any programming language, but AHK currently doesn't support them.

I know that this can be easily achieved with ternary conditional operator, but these are so basic functions that I think AHK should support them.

It is very easy to implement and makes life easier.

It makes this evaluation:

more simple and comprehensive:


This will also give a small boost to Monster too

I believe Laszlo already made this wish.
These functions would be even more useful if accepting any number of parameters.

It is? It's certainly not built-in to any language I know of, and there aren't a lot that even have it in their standard libraries (or equivalent). As you demonstrated, it's simple, readable, and easy to implement with machine-level logic operations (if-else, greater). I think it's one of those things that programming languages are made for, not with.

Apart from that, it seems like the most concise syntax for it would be function-style, so... what advantage is there to it being built-in? It's such a short function that it would be more trouble than it's worth, when you can already achieve the same ease of use (which is still not much more than with the ternary). And it's not just the time it would take - there's a number of different factors to consider before adding something to the basic language specification. It needs to be a feature that's actually worth it, not just something that would be slightly more convenient.

Hmm, interesting.

The main adventage would be the speed and readability.
It needs to evaluate 4 variables in ternary operator, while only 2 using built-in function. This is much more faster especially in loops.
I think Min and Max are frequently used enough in AHK scripts to add native support.

Likewise I think it would be a great convenience especially if it can take more than two parameters.

jonny, I think maths is a fundamental part of programming and should be included in the program. Why else do we have trig and string functions? It's because they're faster and easier than conventional methods. Also until we get a real standard library there's no point talking about it.

_________________
GitHub • Scripts • IronAHK • Contact by email not private message.

We had similar discussions before. Trigonometric functions are hard to write, so for most users they are unavailable if not included in the language (or in a standard library). Min and Max are single line functions, every user can include in his code, when needed, so the saving is negligible.
Anything built in is probably faster, but Min or Max is rarely the bottleneck. User defined functions are equally readable, so only the often insignificant speed advantage remains.

Min and Max are often implemented as macros (e.g. in C), because otherwise in typed languages there would be a need for signed, unsigned, integer, float, string, etc. versions. In AHK we don't have types, so one MAX and one MIN function is enough.

Several parameters are advantageous, but I don't remember having seen applications with more than three Max or Min parameters.

I thought about introducing in Monster the operator " /\ " for MAX, and " \/ " for MIN (cominations of \ and /). It is quite common that we need MIN(MAX(exp1,exp2),exp3). It could be more readable if we write
exp1 /\ exp2 \/ exp3
Since no other language uses these, I was afraid to just cause more confusions.

How do you think a built-in function would evaluate it? It wouldn't have access to some magic that would allow less operations. Two simple logic tests would be the evaluation time for both (for two inputs), and as I've already mentioned, they're machine-level tests that take virtually no time to execute even in tight loops.

What I'm saying is speed is not an issue here, especially with how optimized AHK is. If it isn't a problem yet, don't make it into one.



I still don't see how that's an issue. Here's your proposal:


And here's the user-defined function version that's very easy to make and use already:


What advantage do you see in readability?



This is the one good point I've seen thus far. I agree that this would be a slight improvement in readability and convenience, but it can already be done with a pseudo-array or nested functions/operators. Also, does this really make it worth building it into the language? I could see two-input min/max being used fairly often, but more than that would be rare enough to safely delegate to more complicated solutions for the sake of simplicity.



I never argued this. I'm only saying that it can already be constructed easily, so there's no need to introduce unnecessary elements into the base syntax.



Just to reiterate what Laszlo said, we have trig functions because they're difficult to implement at the user level, yet still used frequently. Same for the string functions, and they are used very often. Operations that relate to window manipulation, strings, hotkeys, etc., will have a much higher chance of being integrated into the language rather than left to the user since they are by far the most common.



Once we have a standard library this could be a part of it, which would be far more appropriate than building it in. Thus I agree.

If you wouldn't mind using a > b ? a > c ? a : b > c ? b : c : b > c ? b : c to get max() of just three operands then I don't see why you can't use for e.g. d / (1 - d ** 2) ** .5 for arcsine~4... :/

How do other C languages like javascript evaluate functions with n params? If not a limit of 4 seems reasonable.

Having to include a large function with stacked if/elses or a complex ternary chain like my one above impairs readability.

Min/max are used a lot in inequalities, more so than sqrt() and possibly even trig.

Out of curiosity what are the drawbacks of implementing such functions, apart from an extra paragraph in the docs and a few more bytes in code size?

_________________
GitHub • Scripts • IronAHK • Contact by email not private message.

I'm not sure what you mean. I was referring to the speed argument, and I was only considering the two-operand case. I wouldn't know how languages other than C[++] evaluate functions with an arbitrary number of parameters.



How is readability an issue inside a user-defined function? With enough comments and spacing, most code can be made clear enough for its function to be understood, and that shouldn't be a problem since the user will never have to worry how it's done as long as it works reliably.



By "simplicity," I meant avoiding the effort it would take to implement and support it, but documentation is also a factor. It may seem like a trivial addition, but I think any addition is a significant one and should have suitable justification, which I still consider lacking.

You have a point here, a more common use is to find the min or max value of an array, which can be introduced with true array implementation.

_________________
vPhiLho := RegExReplace("Philippe Lhoste", "^(\w{3})\w*\s+\b(\w{3})\w*$", "$1$2")

I see the point about Min() and Max() slightly improving convenience and readability. However, another small drawback (in addition to the ones mentioned above) is that they are common names that people might use for their own (unrelated) functions. This might lead to bugs where older parts of a script (or an #include file) call Min/Max(), expecting it to be the built-in function, but instead wind up calling the new user function.

I'd be interested to know if any other popular languages have built-in Min/Max functions, especially ones that don't require an include statement to "bring them in".

Thanks for the idea.

For non-empty parameters you can use easy to read 3-line functionsI don't think they are too long to include, but it is true, some speed and a little code space can be gained with built in functions.

True variable number of function arguments (like nArgIn telling the number of arguments, to be referenced as Arg%i%) would be more important than Min and Max. It would allow using empty parameters and arbitrary many arguments in the user functions.

@Titan: I don't understand your argument about arcsin. Do you mean arctan is sufficient? It is true: from arctan you can compute arcsin with a simple expression, but you have to remember the formula or look it up in a book. Still, you can omit ASIN and ACOS, but not ATAN. Also, you don't need both CEIL and FLOOR, SIN and COS; you can leave out ABS (to be replaced by a single line user function), you can drop MOD or one of LOG and LN. However, I don't think most users would know the simple code to compute the left out functions, while min and max was easy.

@jonny: you don't have to stick to functional notations: min(x,y). As I wrote, operators work even better: x /\ y. It was worth considering.

How are the other built-in functions managed? User defined function could act as overrides, if not then perhaps it's something for v2.

Math.Min is a static method in C#/JS if that's what you mean. PHP's min/max have good syntax.

If we have all those it's only fair to include Min/Max. The point I was trying to make earlier was that if you'd rather a complex ternary over a built-in function you probably wouldn't mind manually calc'ing sin/cos ratios, they're both slower and look confusing - remember the difference between x//1 and Floor(y)?

_________________
GitHub • Scripts • IronAHK • Contact by email not private message.

I already demonstrated that speed wasn't an issue, and what do you mean by code space? A user-defined function would be far better for the code size, since it would only affect those scripts that actually use it. A built-in function would affect every script, including the majority of casual-use ones that would have no need of the function. In any case, though, the difference is negligible and can't be counted as a true advantage or disadvantage. We should default to the safe option of a user-defined function (or standard library function) until it can be shown that built-in functions would be an enormous improvement.


@Titan: Noone was making a case for complex ternaries.

Some of these arguments about why suggested built-in functionaility shouldn't be added are getting a bit sad . Maybe we should get rid of built-in multiplication. How often is it really used when creating a simple script that uses a couple hotkeys for automation? A simple function could be used in its place to add using a loop instead that should be fast enough for 90% of average user needs...