I want to express my small frustration with this kata, because it's not clear whether the expression must be evaluated on each call, or if it has to be calculated at the ending method call. And as it turned out, the first variant is the correct one.

JS sample test is broken: it does not trim the lines of the expected value but does for the actual value, so they will never be equal.

Ruby also does not comply this rule:

the result is compared with smart algorithm, so you don't have to worry about additional space characters that's not visible.

Why is console.log disabled??

Until this changes, for other people's information, console.info still works.

Ruby 3.0 should be enabled.

In Java this:

x    \n     x   \n    o x  \n     o x \nx o x o x\n x o     \n  x o    \n   x     \n    x    \n

And this:

 x\n     x\n    o x\n     o x\nx o x o x\n x o\n  x o\n   x\n    x

Are not treated same!!

Two issues found:

• You state to "round down", but what you actually mean is "round towards zero": -1.6 is to be rounded towards -1 (direction of zero), not -2 (direction of "down")
• If the calculation throws both a DigitOverflow AND an DivisionByZero exception, you require them to be prioritized in a certain order. That implicitly limits the implementation. I was going to first check the whole sequence for regex "/0\b", which was made impossible for no reason. I realize that the "real world" example is hitting buttons one after each other, and hence the appropriate error can be seen immediately, but the way this kata is created, it should be ok to first build a string of the sequence and then process is with regex once the final method is involved. At least that implicit limitation should be made explicit. :)

Actual and expected order is not consistent, sometimes they're ok and sometimes they're flipped. The right order is expected first, then actual. At least in sample tests.

I don't understand why no one responding to my queries / issues.

FluentCalculator::init()->dividedBy->dividedBy->times->dividedBy->zero->one->one->seven->plus->dividedBy->eight->nine()
Failed asserting that 1 is identical to 0.

Is obviously wrong. This is from the last random tests which each tests I've manually calculated myself based from the instructions, they are all wrong.

Unless I'm missing something, HINT if ever please?

Hi,

Java:

• in the solution setup: import java.lang.String;...!? XD
• the main issue, tho, is that it's a plain duplicate of the original kata: Just compare my solution to both, I had almost nothing to do to solve yours. So you should unpublish it, sorry.

Hi! Are there any sources that i can refer to, because i am having some troubles solving this problem.

Thank You.

As mentioned below by @anmae, there are undocumented behaviours:

• The calculator's value is expected to be initialized at 0+, but it's nowhere mentioned
• Expected division behaviour is not round down to the nearest integer i.e round towards negative infinity, but round towards zero. This causes a difference when the divisor is negative