• (nodebb)

Splitting the dollars and cents into separate variables might successfully increase the floating-point precision in some cases, as you're effectively getting twice as many floating-point bits for your calculations; rather than trying to use 24 bits for the whole number, you've got 24 bits for the integer part and another 24 bits for the fractional part. Once you've completed your calculations you still need to take care that you don't need more than 24 bits for the final result, of course.

• smf (unregistered)

I think the best way to illustrate the "Dunning-Kruger" effect is to look at the "X got talent" shows, or other tv shows where the people are there to sing. (Or just your local Karaoke bar)

Most of the people who sing really bad, have know idea about how bad they sound, and how far off they are from even having a chance of sounding decent because they are tone deaf.

That is the TV producer effect.

The contestants don't just walk in off the street and get put on TV, they have been to maybe four auditions and told that they were great and given a callback. The producers have a quota of bad singers to fill and they have to lie to do so. Sure they are tone deaf but when someone is telling you that you're great, then it's hard to resist.

• nasch (unregistered) in reply to Dave

"Ffs, the DK effect is a joke."

If you have credible evidence of that, could you please update the wikipedia entry?

https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect

• (nodebb) in reply to Robert

What's so hard about dates?

Months, for a start. Only today I had to fix an issue where an application calculated the number of months between Feb. 5 and Mar. 5 as 0.986something instead of 1, because each February day counted as 1/28 of a month and each March day counted as 1/31 of a month. (The alternative system, a la Oracle, works better for many cases but also has surprising artifacts, such as today + one month - one month not always equalling today.)

And a few days ago I had to fix a leap year problem related to the birthday emails we send out. You might be expecting "oh, they don't pick up Feb. 29 birthdays unless it's a leap year", but that wasn't the problem; I wrote the code for that and in a non-leap year Feb. 29 birthdays are included in the Feb. 28 send. The problem was that someone else wrote a validator to make sure we didn't have stale data and didn't think about leap years, so on Feb. 28 the leap year birthdays caused it to incorrectly fail validation. I had to change the validation condition from "source MMDD = today MMDD" to "source MMDD = today MMDD or (source MMDD = 0229 and today MMDD = 0228 and (today plus one day) MMDD != 0229)".

These aren't the most annoying date issues I've had to deal with, they're just the date issues I've happened to have this week.

Frigging dates, man.