Done

This kata was retired. It is important to make sure that tests are good before publishing a kata. You may create a new kata with the updated tests but I do not recommend it because there exists a general version of this task: https://www.codewars.com/kata/57b1f617b69bfc08cf00042a/python

Do not submit solutions which modify the testing framework.

No random tests. In order to create proper random tests, the input and output should be BigInt.

My solution uses 3 memory cells and passes all tests.

It is necessary to write a very specific solution to pass all tests in this kata consistently. Tests should be updated to make sure that correct solutions pass all tests (right now, some correct solutions fail 1-5 random tests almost every time).

It is especially important to include sample tests with even sizes. And it should be better explained in the description. For example, if the width is 4 then the correct position is 1 (not 2). The center is 2 but the digit position is 2 - 0.5 = 1.5 which is rounded down to 1.

Tests are not ideal but they are correct. It is hard to create randomized tests which catch all possible bugs. Your solution does not work for some simple test cases like this one:

( -9.21+ -8.97* -0.00+6.51+(5.50+6.81))

The expected result is 7.263867809057526 but your solution returns -915.278670000000034.

A simplified version of this test case:

( -9+ 8*0+6+(5+6))

Expected: 8, your solution: 799.087999999999965.

Yes, it is always true for Java and for any sane programming language. You still need to be careful with more complicated expressions and if you use a low-level programming language like C with specific compiler flags (e.g., --ffast-math): It is possible that you get different results on different machines even if they are IEEE-754 compliant.

Historically, the original version of Java was not strict with floating-point arithmetic and it was possible to get different results on different machines (but always the same results on the same machine). That's why Java had the modifier strictfp to make sure that floating-point results are reproducible (it was removed in Java 17).

Please do not open new issues unless you can confirm that your solution is correct and tests are wrong. Floating-point arithmetic is not random. You always get the same result if you follow all computation steps in the specified order. Did you see my reply to your previous issue?

Both Python and JavaScript return -20.490663944447256 for this expression. So there are no issues with tests.

Make sure that you evaluate all operations with the same precedence from left to right and use library functions to convert decimal numbers to floating-point numbers.

Your current solution fails the following simple test case: 1-(6-3) == -2 but you solution returns 1.

I see the problem now: RISC-V assumes that the second argument is a single character (not a string). It should be fixed.

For real-world problem rounding is required. You cannot distribute real money without rounding. For example, all intermediate steps for calculating US taxes should be rounded to whole dollars. But there is also a small error margin for the final tax value (something around $2).

So my suggestion is to keep rounding but accept results with the margin +-1.

Here is an example which shows that rounding may yield different results:

qf([[1] * 7, [1] * 7], 29)
total weight = 14
round(7 * 29 / 14) = 14
round(7 * (29 / 14)) = 15

What is wrong with RISC-V? It follows all best practices for languages with manual memory management.

If the problem is in a different description for RISC-V, then it could be easily fixed. I personally do not like language-specific descriptions and would prefer to have a comment in the initial solution which specifies how the user solution should return results.

There is an issue with your C# solution: It does not work for large input values (>= 2**62). The amount variable overflows for these input values.