Surely in production code this isn't best practice?

it seems like if there's a real large string, it's gonna have to fully convert it to upper case and compare. i guess a for loop with an early return false (in case a char is lowercase) would be the best practice in terms of performance

good jop

Interesting, converting the string return value of .ToUpper() to a MyString type instead of converting the MyString s to a built-in string type. I'm curious if there's any particular advantage there, or if it just keeps things a little simpler on one side of the equation?

but not for hugh strings efficiently

I thik its innefficient on very hugh strings. Better check one rune by rune to get Unicode-16 full

1. the reduce function is accumulating the product of the complicated expression with a* (a is the accumulator)
2. the +"" is for converting the number in the array to a string, this is needed so we can use an index to get the first digit
3. [0] is taking the first digit of the string
4. earlier in the code, the first + is the unary plus operator, used for converting that digit (which is now a string) back into a number so we can perform math on it again (otherwise the next + would be a string concatenation operation rather than an addition operation).
5. arr[i-1]%10 is taking the last digit of the previous number element
6. the /arr[0] at the end is needed because the initial value that ends up getting multiplied is going to be the first number of the array. Alternatively, this could have been removed, and an initial value of 1 could have been provided as the 2nd parameter of the .reduce() call, after the reducer callback function. However, they didn't want to do it that way because then they couldn't use [i - 1] as an index, as it would change the starting value of i from 1 to 0.

I hope this helps.

oh. how simple the solution can be... I worked with arrays and runes. hahah

Hi,

Can anyone please explain the code