If they cared about accuracy....

It's a curious kind of Rakudo advocacy that responds to "Rakudo doesn't live up to its advocacy in this specific technical place" by insinuating that users are untrustworthy and wrong.

I certainly did not say (nor even insinuated) that "users are untrustworthy and wrong," but only that some types of users (namely finance and audit people in that case) very often don't have accuracy as a top item in their agenda. They may very well be right from their own standpoint. Whether I agree or not with their priorities is fairly irrelevant.

The example of monthly time sheets that you have to submit ten days before the end of the month was not just a joke: it's a clear symptom that they care about having data early, but not about having correct data. If that's their priority, so be it! I don't particularly care about their priority. But they should probably not be taken as an example of people particularly rigorous on correctness and accuracy.

some types of users (namely finance and audit people in that case) very often don't have accuracy as a top item in their agenda

That's a silly assertion that you can't back up, and it directly conflicts with my own experiences actively seeking out and correcting these types of inaccuracies because it caused so many headaches and problems and overwork for finance and audit people.

Even so, regardless of all of that, it's still nonsense to claim "Rakudo does numbers right!" when it's clear that there's (as someone else put it) a hole in the bottom of Rakudo's number handling, and then to claim that it doesn't really matter because you don't think people care about this.

It's this type of bizarre Rakudo advocacy that makes me wonder why anyone still bothers.

Yes, the timesheet people are a plague on civilization. But that's a non sequitur. It's completely irrelevant to the rest of your argument.

Yeah, thanks, I have been in the business of data quality for a large financial application running in several different countries for long enough, I know very well how to make things look right, rounding first and then summing.

But that's precisely my point. Making the thing look right this way is likely to make the sum less accurate (especially when they insist at the same time on using rounding methods that will not even out rounding errors in a large sum and will tend on average to make the sum slightly larger than reality -- but that's a different story).

And that's exactly what I was saying about people in finance, accounting and audit departments: they want things to "look right" much more than they want the calculation to be accurate.

I can perfectly understand their concerns and I have no problem with these choices. It even happened at least two or three times that I was the one who suggested them the solution to round first and then sum, as a way to get exactly the look they wanted, but warning them at the same time that it would make the calculations less accurate. In at least one occasion, I even prepared a detailed spreadsheet showing what happened depending on where the rounding was made in a number of scenarios and pointing out that it would look right but be slightly inaccurate in a relatively significant percentage of the invoices (usually just one or two cents above the real amount). They were really unimpressed about lesser accuracy to put it mildly (in fact they didn't give a sh*t about it) and they jumped on the solution that looked right.

So, again, I am not criticizing their choices, but, contrary to what has been said by another monk before, these people should hardly be given as an example of rigor and accuracy.

I'm disappointed to see that you've changed your mind and once again want to discuss this with me. So I'm just going to quote you a passage from the Tao of Programming, chapter 3.3, and if you don't like it you can go back to not talking to me again.

There was once a programmer who was attached to the court of the warlord of Wu. The warlord asked the programmer: "Which is easier to design: an accounting package or an operating system?"

"An operating system," replied the programmer.

The warlord uttered an exclamation of disbelief. "Surely an accounting package is trivial next to the complexity of an operating system," he said.

"Not so," said the programmer, "when designing an accounting package, the programmer operates as a mediator between people having different ideas: how it must operate, how its reports must appear, and how it must conform to the tax laws. By contrast, an operating system is not limited by outside appearances. When designing an operating system, the programmer seeks the simplest harmony between machine and ideas. This is why an operating system is easier to design."

The warlord of Wu nodded and smiled. "That is all good and well, but which is easier to debug?"

The programmer made no reply.