Perfection!
I was creating functions that combined parsers, but it never occured to me to do this

I'm sorry i've explained it wrong, i was talking about multiplication being commutative and associative, in fact you can test it out => 7 / 3 * 5

(7 / 3) * 5 = 35 / 3

(7 * 5) / 3 = 35 / 3

And in the real world, you are calculating with fractions where the order of multiplication does not matter. I've just said it wrongly. My fault.

PS. even division is commutative, if you accept that division is just (n)^-1 => 1/n

Are you sure about this statement?

I was going off real world, where whether we do * or / first does not matter,

thank you, the precedence was indeed the problem. After changing the precedence to make * and / the same, it worked instantly. Meaning that by changing the precedence, i've indeed changed where precision is lost, and thus was always off by a minute number.

I was going off real world, where whether we do * or / first does not matter, but i forgot, that because of the precision limitation of float numbers, different order makes different precision loss. In my mind i was thinking that i could just give every operator its discrete precedence and it would work out. So, its completely my fault. There is no problem with description, only with my interpretation.

thank you for your patience with me.

Do not use WolframAlpha to verify floating-point arithmetic results. Use Dart itself or any other programming language (Python, JavaScript, etc.). For example, your solution (where I replaced Frac with double everywhere) fails the following test:

Expected: <64.69433890577507>
  Actual: <64.69433890577508>
expression = -95+9/-7--25+45/48/-47+96+40

Let's verify the expected result with Dart itself:

void main() {
  double expr = -95+9/-7- -25+45/48/-47+96+40;
  print("expr = $expr");
}

The result is expr = 64.69433890577507.

Here is a small example for which your solution returns a wrong result:

Expected: <0.7714285714285716>
  Actual: <0.7714285714285715>
expression = 9/7*3/5

It seems like you compute it as (9/7) * (3/5) which is not correct since * and / have the same precedence. So it should be computed as ((9/7) * 3) / 5.

I admit that the kata description is not precise. I plan to update it at some point to make it clear how all expressions should be evaluated. It is also important to specify that all intermediate results should be computed with double precision.

There are no issues with Dart tests. Use double everywhere and make sure that you evaluate all operations from left to right if they have the same precedence. Floating-point arithmetic is not random. You always get the same result if you perform all operations in the correct order.

Dart random test is broken! It's saying i'm wrong, despite difference being 10e-10:

Expected: <1725.6341463414633>

Actual: <1725.6341463414635>

You are trying to verify that a double is exact, but that's not possible because of the loss of precision. The precision is lost at different stages depending on how you implement the function (whether you do it recursively or you collapse all operations). You should switch to using fuzzy equals instead of equals.

In fact, i'm quite sure your solution is imprecise, because when it first happened to me, i've changed to calculating using fractions, so that i won't lose any precision. And yet it's still saying i'm wrong, despite being the most precise value you can get.

The worst case that happened was > Correct: 134.6666666666667, My > 134.6666666666666

Please fix it

i still didn't understand, how i must to decode it.

Is there even some kind of algorithm that created the letter mappings? I've tried to figure it out at first (~15 mins), then i gave up and brute forced my way through it (press attempt to get the letters).

If there is a legitimate algorithm that maps the letters, the kata could easily be 2-4 Kyu. If there isn't, then most of the difficulty comes from getting all the letters, not the actual problem, which makes it 7 Kyu. That's a pretty big difference.

If there is an algorithm, could you post it somewhere (here, github, ...) so i can look at it, i'm just really curious how it works.

Thanks a lot, this issue was not only in dart but in all languages :)

approved

DART > The regex you use to check if shortURL (short.ly/[a-z]{1,4}) is valid is wrong. You forgot to escape the dot, meaning that "shorttly/abcd" is still valid URL.

With this you can circumvent the problem with big numbers, since the number of valid strings is actually 14_257_620, not 475_254. For example in my solution once i got to number 470_000, i resetted the number to 0, and changed the url from "short.ly" to "shorttly". This way i cheated the regex, and my solution was valid. THIS IS WRONG!
Please fix the regex to short.ly/[a-z]{1,4}