Kata

Okay, I think I've fixed this now. I have floor'ed the final answer given by the solution so it should match up with the requested answer. Could you give me your solution so I can test it again and see if it works with yours?

If you test with assertApproxEquals, you should not do any rounding. It defeats the purpose.

Okay, I removed the floor's. Could you tell me how assertApproxEquals works, because it seems to cause some issues with my Example Test Cases now. What is the accuracy that it expects from the answer?

See below. .toString works on assertApproxEquals.

You did not remove the floors.

I think I have fixed this now, could you give it a test and see what happens?

Flooring is out. Now you have reversed expected values of x and y for minutes and seconds, but not hours. Also, there's a - too much in there somewhere.

Could you please check your stuff before you publish it? Just solve the kata yourself like a normal user, and check your answers for plausibility? Add a couple of easy, fixed tests for this, 1200, 0300, 0730, and check the bloody signs of the expected values. I'm getting a bit tired of this incremental stuff.

Thanks for editing the actual Test Cases accordingly but I think you forgot to edit the Sample Test Cases as well ;)

As for whether the actual Test Cases work, they are buggy when the expected value is extremely close to zero (somewhere around 1e-15) but that is not your fault (in fact it is mine, I implemented this particular method for the Codewars JS testing framework but I proposed a fix here a while ago) so you may leave it as is :)

Obviously I have already done what you suggested. I have put in easy solutions and tested them against the results and on my side they seem to be all correct. Sorry to trouble you.

What I see is you're testing the reference solution against itself and you don't have any fixed Submit Tests. You won't find (existing or newly-introduced) bugs in your reference solution that way.

Either add some fixed Submit Tests, or have (very!) different example and reference solutions (or both. and then fixed-test your reference solution as well. you can take that out before publishing).

Oh, you have (actual,expected) switched in the arguments of assertApproxEquals. That makes for wrong messages on failure. Both Example and Submit tests.

But my solution just passed!

It would seem the tests are now correct. Let's hear from some other people as well, but this looks hopeful.

Phew! Yeh it seems to be working now! I think some of my maths was wrong in the original solution. Sorry it was so drawn out, I was about to give up!

For me it seems correct now (haven't tested/submitted before);-)... So well done:-)...

Yep, seems to work.

With Test.approxEquals, this is no longer an issue. You could take out the code handling this.

With Test.approxEquals, this is no longer an issue. You could take out the code handling this.

I'm sure there are some analog clocks that have a ticking mechanism, in which case they should move in an instantaneous manner wouldn't you say? I know what you mean, there are some clocks that do work with a continuous motion, but I think my problem is still a valid task.

Having the hours hand only move to the next full hour on the whole hour is a valid task, but it's not what people expect when they read "analog clock". Would you expect the hours hand to be at twelve at 00:30?

It's worth an explicit mention in the description.

Ah yes I see what you mean. I will try and code it so that the hour hand has to be in the correct position depending on the number of minutes to the nearest minute and the minute hand with just click to the nearest minute. Do you think that would be a good solution?

I initially had all three hands moving once per second, but you can have the hour hand moving once per minute, no problem. Just specify it.

OK, that seems all fixed.

So the values are turned into integers with Math.floor when you calculate the position using the trigonometric function. There was an issue in there with the Y values being the wrong way around (positive when they should be negative and vice versa), but this should be fixed now. Perhaps try again and see if you can get solve it.

Still some rounding differences. Values are never off by more than one. Seems to happen on all hands; if the difference is in x expected value is one more than my actual value, if in y it's one less.

Tried to submit until I got lucky.

Seeing the reference solution, I'm not surprised there are rounding errors.

The best way to do this kind of thing is not rounding any values, and comparing them with a margin for error. Test.assertApproxEquals was invented for this situation. If you specify floor, and have final values very close to integers, it is little surprising it sometimes comes out plus or minus one. With all the calculating you do, you introduce a lot of inaccuracies, small ones, but they accumulate, and then they get amplified by the flooring.

Please explain how the values are turned into integers.

Can't be done.

At least not better than is already in there.

Could you give me an example of how to use Test.assertApproxEquals with object properties, so that I can compare all the seperate values for each hand?

let actual = { hours: { x:1, y: 2 }, minutes: { x: 3, y: 4 }, seconds: { x: 5, y: 6 } };
let expected = { same same }
Test.assertApproxEquals( actual.hours.x, expected.hours.x, "x-coord of hours was wrong" );
Test.assertApproxEquals( actual.hours.y, expected.hours.y, "y-coord of hours was wrong" );
Test.assertApproxEquals( actual.minutes.x, expected.minutes.x, "x-coord of minutes was wrong" );
and same same

You have to compare each and every property, which is a bit of writing repetitive code, but you just can't approxEquals composite data types. You could put it in a nested for loop and assert( actual[hand][coord], expected[same][same], `smart failure message` ), but that's probably as much work as just writing it out.

from the Test.assertApproxEquals source:

if (Math.abs(expected) <= 1) {
  Test.expect(Math.abs(expected - actual) <= 1e-9, msg, options);
} else {
  Test.expect(Math.abs((expected - actual) / expected) <= 1e-9, msg, options);
}