Random() quirk

[willichan]

I came across a little quirk when using the Random() function.

If Min and Max are the same value, then Random() returns 0 rather than the Min/Max value. The Flag does not make any difference.

For example, the following returns 0 for all four "tests"

MsgBox(0, "test 1", Random(1, 1, 1))
MsgBox(0, "test 2", Random(2, 2, 1))
MsgBox(0, "test 3", Random(3, 3, 1))
MsgBox(0, "test 4", Random(4, 4, 0))

I am using the following workaround for the time being.

Func FixRandom($min, $max, $flag=0)
    If $min = $max Then Return $min
    Return Random($min, $max, $flag)
EndFunc

[water]

If Min and Max are the same value, then Random() returns 0 rather than the Min/Max value.

Did you check @error?

From the help file:

Return Value

Success:

Returns a pseudo-random number between Min and Max.

Failure:

Returns 0 and sets @error flag to 1 if bad parameters.

[PsaltyDS]

It has been discussed several times before, and the Devs do not consider it a bug. The documentation should be updated to reflect it, but the behavior is as designed.

[kaotkbliss]

I would think that if the min and max values are the same, then the number really is not random at all then... Maybe why it's not considered a bug?

[BrewManNH]

It may be by design, but it's still not working as you would expect. I used the Random() function in a script that randomly selects a picture from a folder to display on a GUI, if there was only one picture in the folder it didn't display because Random(1,1,1) returns 0. It took a LONG time to track that error down. If the documentation for Random() explained that you can't use it like that then it probably would have been a lot easier to debug.

[willichan]

I am not going so far as to call it a bug, since as kaotkbliss points out, if Max and Min are the same, then it isn't really a random number ... technically.

It was a simmilar situation to that BrewManNH describes that pointed me to the quirk. I was populating an array, based on existing subfolders in various folders, then selecting one of them at random.

$TheArray[1] = "default"
;...
; routines to further populate the array
;...
$Selected = $TheArray[Random(1, ubound($TheArray)-1, 1)]

It would make more sense for Random() to return whatever Min/Max is provided, than to return an error condition.

As I said, I wouldn't go so far as to call it a bug, but I would support the idea that if the behavior stays as it is, the help/docs should be updated to reflect it.

Edit:

My purpose in posting this was not to report a bug in AutoIt, but to help others not spend the time chasing their tails after a bug in their scripts, as I did, based on a misunderstanding (logical though it may be) of how the Random function should behave.

Edited August 31, 2010 by willichan

[Spiff59]

I had a BugTrack shot down a year or two ago on this exact issue, and I don't think it was the first time the problem was reported.

It is illogical behavior, requiring extra coding to work around, but as stated above, it's been ruled "no bug".

Edit: Pardon me, it was someone elses BugTrack, regarding this issue, that I "piped-in" on, rather than having started one of my own. I think quite a few threads have argued this point as well. It makes no sense, and behaves like no other language I'm aware of.

Edited August 31, 2010 by Spiff59

[willichan]

It is illogical behavior, requiring extra coding to work around, but as stated above, it's been ruled "no bug".

I would agree, to an extent. It does not make sense that the extra coding is put in to handle only providing one parameter, and assuming it as Max; then to turn around and argue that the coding to handle Min and Max being the same is too much, and calling it laziness on the scripter's side. (The docs do also fail to specify what Min is assumed to be. 0? 1?)

On the other hand

AutoIt's main purpose has been stated as being an administrative automation tool. I have yet to encounter when I would need the Random function for administration or automation purposes, so I can see where it would not get up very high on the priority list. I see it as one of those extra functions that allows me to use AutoIt outside of its stated purpose, and I am not one to look a gift horse in the mouth.

Not to mention that the workaround is only two short lines of code (four if you make it a function like I did above).

There are several places in the help/docs where a little extra information would go a long way. That should not be considered a knock against the developers though. It is not uncommon for docs to lag behind development. I also find it very common that developers do not make the best help/doc writers to begin with (again, no knock against anyone on the development team). I know people that make very good money going into development centers, and interpreting developer's docs into something end users can use. The best coarse to take, in my opinion, would be to write the change to the docs that you think would be appropriate, and suggest it to the AutoIt team. "You need to change it" will probably not be well received, but "Here's my suggestion for how to word it" would probably be taken more seriously. (They may even be relieved to see one more item removed from an already very long lists of things to do)

I am already working on some suggested changes to the docs. Once I am satisfied that they state what I intend them to, and have them reviewed by a couple of colleagues, I will be submitting them myself.

Edited August 31, 2010 by willichan

[czardas]

I find it odd that it returns a value of zero. The way I see it is that as min approaches max, random values also approach max. When min equals max, random values disappear. I would be inclined to return the max value. It would be nice if min and max values could be any value, or even swap their values. Min and max would then have to be renamed value1 and value2. Having said that it's not a bug and it doesn't take much additional coding to make it behave the way you wish. Perhaps there's a deeper reason behind the Dev's choice.

Edited August 31, 2010 by czardas