Performance question about simulating AND/OR with conditional branches

[ATT_Turan]

Since JavaScript conditional statements don't only exist in script commands (you'll find plenty of them in the core scripts or in plugins), I considered the additional overhead associated with using script commands to be outside the scope of my statement.

Okay, cool - so I either misunderstood you, the OP, or both

When they first asked

i am trying to figure out if is better to simulate AND/OR with conditional branches or better to just script it

I read that as putting code including AND/OR operators into the conditional branch's Script field, as opposed to actually nesting conditional branches or using their Else branch.

If the conversation actually veered outside of using an event entirely and just putting the code directly into a plugin, I think both myself and Aqua missed it.

 

[Arthran]

Okay, cool - so I either misunderstood you, the OP, or both

When they first asked

I read that as putting code including AND/OR operators into the conditional branch's Script field, as opposed to actually nesting conditional branches or using their Else branch.

If the conversation actually veered outside of using an event entirely and just putting the code directly into a plugin, I think both myself and Aqua missed it.

Yeah, your understanding of the OP's question makes more sense. I think I probably didn't pay good enough attention. I was too focused on my desire to share my array shuffling idea, and just jumped in and started saying stuff. Sorry, folks.

 

[werzaque]

You can also start with

let nums = Array.from({length: 101}, (value, key) => key + 1);

Okay this is very off-topic, but why is it that passing (value, key) instead of just (key) allows you to successfully populate the array? I don't understand why

Array.from([0,1,2,3,4, all the way to 100], (x) => x + 1)

works, but

Array.from(Array(101), (x) => x + 1)

does not...

EDIT: it was the other way round lol

 

[ATT_Turan]

Okay this is very off-topic, but why is it that passing (value, key) instead of just (key) allows you to successfully populate the array?

I'm not sure whether your edit means you figured it out, or that you're still confused but your examples are backwards

Per the documentation of some(), the second argument is a map function called on each element:

JavaScript Array from() Method

W3Schools offers free online tutorials, references and exercises in all the major languages of the web. Covering popular subjects like HTML, CSS, JavaScript, Python, SQL, Java, and many, many more.

www.w3schools.com

Similarly, per the documentation of map(), the first argument is simply the current value of the given element:

JavaScript Array map() Method

W3Schools offers free online tutorials, references and exercises in all the major languages of the web. Covering popular subjects like HTML, CSS, JavaScript, Python, SQL, Java, and many, many more.

www.w3schools.com

If you simply call Array(101), each of those 101 elements are undefined. So only passing one argument into the map function will reference their current value, produce undefined + 1 and all math in JavaScript with undefined produces NaN.



The second argument of map(), however, is the current index of the given element, and that must be a value. So you can perform math on the index (what Trihan labeled key) to produce a value for the elements of the array.



In your example where you actually initialized the values of the array elements manually ( [0, 1, 2, 3, etc.] ) only passing the first argument into map() has a defined value to work with. But in that case the whole thing is kind of pointless because what Trihan provided was a shorthand to initialize the values of a large array without typing it out.

 

[werzaque]

Thanks as always! The realization that the mapping portion was a function was missing from my brain. This is so cool, thanks!

 

[gstv87]

@ATT_Turan like I said, all things being equal, conversion done and all, comparing two variables requires the processor to make one additional loop to load both operands to it's own registry, in contrast to "write [this] to [this address]".
I don't remember my CPU-Fu all that well, but I believe those writings happen in parallel (all bits at the same time) while *looking for a number* is sequential (going up or down the table one position at a time)
still... even if it was [bus size] X [number of operands] X [bit actions], we're talking hundreds or thousands of operations, in a structure that handles millions to hundreds of millions per second.
it's not gonna make a difference.