How does V2 implement this V1 code?

[arcticir]

It may seem simple, but I didn't expect that the latest V2 would be so difficult to implement it.

Code: Select all

f:=[]
loop 1000
{
t:=random(1,100)
if f[t]
f[t]++
else if t>f.maxindex() or  t<f.minindex()
f[t]:=1
}

[Helgef]

Set the length of the array, use has() and save max and min index yourself. If the length required is too large, use a map.

[arcticir]

Set the length of the array, use has() and save max and min index yourself. If the length required is too large, use a map.

Yes, it can be done this way. But its performance and simplicity is a disaster.

[Helgef]

Maybe something like this then,

Code: Select all

f:=c.new()
loop 1000
	f[random(1,100)]++


class c extends map {
	__item[i] => this.has(i) ? base[i] : 0
}

Edit, simplified.

[arcticir]

@Helgef The point is "min-max" ...

[Helgef]

Sorry, I had my mind elsewhere. Regarding the original suggestion, is it really so bad?

Code: Select all

f:=map()

min := 100
max := 1
loop 1000
{
t:=random(1,100)
if f.has(t)
	f[t]++, 
else if (t>max && max:=t) or  (t<min && min:=t)
	f[t]:=1
}

Edit, well, this isn't equivalent of min/maxindex().
edit2,

Code: Select all

f:=map()

min := 100
max := 0
loop 1000
{
t:=random(1,100)
if f.has(t)
	f[t]++, 
else if t>max or  t<min
	f[t]:=1, max:=max(t,max), min:=min(t,min)
}

[arcticir]

@Helgef
The situation may be more complicated. "F" will be passed multiple times as a parameter, it cannot carry the two variables "min"-"max".

So my current method is:

Code: Select all

max(f){
for i in f
max:=i
return max
}
min(f){
for i in f
return i
}

[Helgef]

I see, maybe this then

Code: Select all

f:=c.new(100)
loop 1000
{
t:=random(1,100)
if f.has(t)
f[t]++
else if t>f.max or  t<f.min
f[t]:=1
}

class c extends map {
	__item[i] {
		set => (this.minmax(i), base[i] := value)
	}
	max := 0
	__new(max) => this.min := max
	minmax(i) {
		this.max:=max(i,this.max), this.min:=min(i,this.min)
	}
}

[arcticir]

@Helgef

Yes, but compared to V1, its performance and simplicity are desperate.
So I have been thinking, what did V2 gain in exchange for the lost flexibility and simplicity?

[HotKeyIt]

I have added MinIndex and MaxIndex to Map, not sure why lexikos did not take them over: https://github.com/HotKeyIt/ahkdll/commit/47c45c6cc19e20cf75700b3538e4614dc906883e

[guest3456]

I have added MinIndex and MaxIndex to Map, not sure why lexikos did not take them over

probably because Maps are supposed to be associative array dictionary types, and therefore its weird to query min/max integer keys when you are expecting random key names

the OP still hasn't yet fully described his use case. perhaps his design and data type choices are bad

[lvalkov]

You speak of "increased complexity", "loss of flexibility" and "lackluster performance" when in reality you couldn't be further from the truth.

• The last solution posted by user @Helgef executes about half an order of magnitude faster than the stock v1 sample. (See edit below.)
• Flexibility would have been impacted had there not existed a way of replicating in v2 what you had originally asked for.
• The degree of complexity can be debated. I'd be hard-pressed to call a 10-LoC implementation "complex". Suffice it to say, if one seeks to only get by merely relying on old v1 paradigms instead of making oneself familiar with the new ones, a great majority concepts will seem complicated.

[arcticir]

@Helgef @HotKeyIt Thank you.


@lvalkov

Regarding performance, my test results are the opposite of yours.
loop 1000000
V2 V100 0.550465S
V2 V108 0.903593S

I can't imagine why you think this function will be faster than the built-in functions.
minmax(i) {
this.max:=max(i,this.max), this.min:=min(i,this.min)
}

[Helgef]

@lvalkov, hi, I'd expect my example to be slower due to minmax() method as pointed out, perhaps you forgot setbatchlines -1 when testing in v1.
@arcticir, I understand that it might be inconvenient when built in functionality is removed, but really, min/maxindex() makes no sense for either array or map types, imo. You might have an edge case where you really need it, but to conclude from this that v2 has lost flexibility and simplicity seems a bit hasty. The new object implementation makes it trivial to extend built-in functionality. Consider how you'd add min/maxindex() methods in v1 if they weren't present.

Just as yet another alternative for you,

Code: Select all

f:=map()
min := 100
max := 0

loop 1000
{
t:=random(1,100)
if f.has(t)
	f[t]++, 
else if t>max or  t<min
	f[t]:=1, max:=max(t,max), min:=min(t,min)
}
f.min := min
f.max := max

this is simple and straightforward, and doesn't require you to carry around the min/max variables, but you still have to update the min/max properties if f is modified elsewhere.

Cheers.

[arcticir]

Thank you This brings me to a new understanding of built-in functions, which are not necessarily faster than custom functions.

[lvalkov]

perhaps you forgot setbatchlines -1 when testing in v1.

No. I had simply copied @arcticir's snippet and executed it with the 1.1.32.00 interpreter ("implement this V1 code" implying v1). I failed to account for the fact that the piece of code was, indeed, not v1-compliant (t:=random(1,100)). Unfortunately, the interpreter (through no fault of its own), too, failed to alert me. What had happened is that Random.ahk, part of a library I had been testing these past couple of days, was auto-included from my AutoHotkey Lib folder. The function performs extra checks in addition to having other user-defined functions as dependencies, hence the atrocious performance.

Having now benchmarked the sample again with the proper built-in command (Random t, 1, 100), I can see that it is on average about twice as fast as @Helgef's v2 solution.

Sorry for the misinformation, @arcticir.

[HotKeyIt]

... not sure why lexikos did not take them over

probably because Maps are supposed to be associative array dictionary types, and therefore its weird to query min/max integer keys when you are expecting random key names

Ok, but it would be then also weird to build a class with functions that extends Map or Array, right?
I think it is good to have usefull methods build-in.

[guest3456]

Ok, but it would be then also weird to build a class with functions that extends Map or Array, right?
I think it is good to have usefull methods build-in.

i think the idea is what Helgef said: Min and MaxIndex are not very useful most of the time, but if you need them for very specific edge cases, then you can easily extend the class to provide them yourself, as he showed. normal arrays start at 1 and you keep pushing new items, so maxIndex = .Length, thats the most common use case

[TheArkive]

Hoping this is still on topic...

Is there an equivelant to has() for plain objects? Or would I need to use something like Try/Catch?

[Helgef]

HasOwnProp, close enough?

Cheers.