Could you please clarify how division should be handled? It seems everywhere that we are supposed to work on integers but this test case - diff("(/ x 2)"), "0.5" - introduces floating point numbers and I'm not sure what's the logic behind it.

I enjoyed this kata, except for the part at the end where I had to reshuffle all my commutativity stuff to make it match the test cases.

Not sure how much of the issue I ran into is only part of the rust version.

From reading the thread below, it seems like the expected way to resolve the commutativity ordering issues is to rely on the example tests? This isn't explicitly stated in the instructions (though I suggest that it should be), and is a bit annoying that the tests conflict with the given reference materials on what the ordering should be (the reference link gives the chain rule as f(g(x))' = f(g(x)) * g'(x), but the tests implement it as f(g(x))' = g'(x) * f(g(x)))

However, the main actual issue I ran into is that it's possible to pass the given example tests and yet fail on the tests where you can't see what the expected result is due to the opaque error message assertion failed: result == expected1 || result == expected2, which obscures the information about the expected ordering of the solution (in my case, the associativity was being grouped differently, my solution encoded cos(x) * 3 * (sin(x))^2 as (* (* (cos x) 3) (^ (sin x) 2)), grouping multiplication from left to right, which isn't rejected by the example tests or addressed in the instructions)

If this message could be fixed in the Rust implementation so that the kata can be completed without potentially requiring guessing, that would be great.

For what language version? The original Java, Javascript and C# versions do accept both versions.
The contributors that made the other language translations will have to update their respective versions.

In the instructions it says you should evaluate values in the resulting expression.

Could you please clarify how division should be handled? It seems everywhere that we are supposed to work on integers but this test case -

`diff("(/ x 2)"), "0.5"`

- introduces floating point numbers and I'm not sure what's the logic behind it.Where did you need to cast ? When are interfaces ever a problem?

Why use interfaces at all if we need to cast certain properties?

Why use mutable properties when you require unique identifiers?

This comment is hidden because it contains spoiler information about the solution

This comment is hidden because it contains spoiler information about the solution

`(tan (* 2 x)) --> (/ 2 (^ (cos (* 2 x)) 2))`

`expected: "(* 2 (/ 1 (^ (tan (* 2 x)) 2)))"`

Although without redundancy, no simplification is involved during the first differentiation, yet it is not taken into account by the answer.

I added better messages to the mentioned test cases.

I enjoyed this kata, except for the part at the end where I had to reshuffle all my commutativity stuff to make it match the test cases.

Not sure how much of the issue I ran into is only part of the rust version.

From reading the thread below, it seems like the expected way to resolve the commutativity ordering issues is to rely on the example tests? This isn't explicitly stated in the instructions (though I suggest that it should be), and is a bit annoying that the tests conflict with the given reference materials on what the ordering should be (the reference link gives the chain rule as f(g(x))' = f(g(x)) * g'(x), but the tests implement it as f(g(x))' = g'(x) * f(g(x)))

However, the main actual issue I ran into is that it's possible to pass the given example tests and yet fail on the tests where you can't see what the expected result is due to the opaque error message

`assertion failed: result == expected1 || result == expected2`

, which obscures the information about the expected ordering of the solution (in my case, the associativity was being grouped differently, my solution encoded cos(x) * 3 * (sin(x))^2 as`(* (* (cos x) 3) (^ (sin x) 2))`

, grouping multiplication from left to right, which isn't rejected by the example tests or addressed in the instructions)If this message could be fixed in the Rust implementation so that the kata can be completed without potentially requiring guessing, that would be great.

This has been suggested and replied to before.

I believe the test case for (^ x 2) is broken, because it does not respect commutativity of multiplication:

x^2 should return 2

x: '(x 2)' should equal '(* 2 x)'Currently, it requires the answer only in one of two possible forms.

Thanks, the

`tan`

case works for me now.Try it now

Rust 1.44

Contains the following assertions in the tests:

Who do I contact to fix the translation?

For what language version? The original Java, Javascript and C# versions do accept both versions.

The contributors that made the other language translations will have to update their respective versions.

## Loading more items...