Mozilla lightning wtf:)




  • in case you didn't notice - there are 2 24'th of march:)



  • Oah, that's pretty bad.



  • Ouch. Well when you're living on the cutting edge of functionality (what, you mean someone already made several hundred calendar controls? Nah....) these things are bound to happen.

    I have to wonder what kind of code bodge up created that. Surely that can't have been a general monthly calendar problem - the "many eyes" of OSS would surely have spotted it. Is there a special case for 24th March '07??

     

    It's a shame that I never took a photo of it but a few years ago one of our stationery suppliers sent us their calendar (why do they all do that?) There were four errors - 2 duplicate days like that, one month starting two days after the previous one ended, and a month with Saturday and Sunday transposed.



  • @RayS said:

    Ouch. Well when you're living on the cutting edge of functionality (what, you mean someone already made several hundred calendar controls? Nah....) these things are bound to happen.

    I have to wonder what kind of code bodge up created that. Surely that can't have been a general monthly calendar problem - the "many eyes" of OSS would surely have spotted it. Is there a special case for 24th March '07??

    Maybe screwy code that uses fucked floating-point rounding causes it. Modulo is an underappreciated operator in the low-to-medium reaches of the programming populace.



  • When I want to calculate dates, the very first thing I think is "I'd better use floats"!

    Then again,  anything i sipossible I suppose.



  • @RayS said:

    When I want to calculate dates, the very first thing I think is "I'd better use floats"!

    Then again,  anything i sipossible I suppose.

    Now that we're on the subject, I've been wondering whether (34.68 % 1) is a nice way of getting the decimal portion 0.68, or if there's a better way.
     



  • @dhromed said:

    @RayS said:

    When I want to calculate dates, the very first thing I think is "I'd better use floats"!

    Then again,  anything i sipossible I suppose.

    Now that we're on the subject, I've been wondering whether (34.68 % 1) is a nice way of getting the decimal portion 0.68, or if there's a better way.
     

     

    how does that return a decimal?  What language are you using that in?  

     

    PS (num - floor(num)) 



  • @dhromed said:

    @RayS said:

    When I want to calculate dates, the very first thing I think is "I'd better use floats"!

    Then again,  anything i sipossible I suppose.

    Now that we're on the subject, I've been wondering whether (34.68 % 1) is a nice way of getting the decimal portion 0.68, or if there's a better way.
     

    As modulo is an integer function, that's asking for problems.

    On python and ruby, this works fine.

    A C compiler refuses it.

    Javascript yields WTFed floats : 3.1%1 = 0.10000000000000009 , 5.4 = 0.40000000000000036

    Perl truncates to integer anyway, so anything %1 is 0

     For sure, a reliable 2-characters decimal part operator would have been fun. But given those results and knowing the mathematical definition in the first place, that's asking for a front page article :)



  • btw ruby has a "rational" data type, perhaps less optimal than float but far more reliable.



  • I think this belongs on the front page.

    Write up something witty and submit it.



  • @aikii said:

    As modulo is an integer function, that's asking for problems.

    On python and ruby, this works fine.

    Javascript yields WTFed floats : 3.1%1 = 0.10000000000000009 , 5.4 = 0.40000000000000036

    Funny that JavaScript's result is a "WTF", yet Python, which returns exactly the same thing, is "fine".  But this is a general problem with floating point.  The worst you could say about the particular languages is that they show an excessive amount of precision by default.

    (For the record, Ruby seems to be more accurate - I'm not sure exactly what it's doing differently, but it uses floats too so it would have the same problem in more extreme cases.) 



  • @iwpg said:

    Funny that JavaScript's result is a "WTF", yet Python, which returns exactly the same thing, is "fine".  But this is a general problem with floating point.  The worst you could say about the particular languages is that they show an excessive amount of precision by default.

    Quite the opposite - they are imprecise. The problem is that people consider them to be precise.

    "Ooooh look, 16 digits after the decimal point, these things must be real precise!"

    They're approximations. 5.4 - 5 = 0.4, not 0.40000000000000036. that's not to say that there's anything wrong with floats, just that a lot of the time they are the wrong tool for the job. The proverbial person using a hammer for a screwdriver's job.

    Most modern languages provide more useful tools for dealing with decimal numbers. Some frameworks even call them "decimal". I wish that more people would use them when appropriate.

     



  • @RayS said:

    Quite the opposite - they are imprecise. The problem is that people consider them to be precise.

    "Ooooh look, 16 digits after the decimal point, these things must be real precise!"

    No, they're inaccurate.  That's not the same thing as imprecise.



  • @iwpg said:

    @RayS said:

    Quite the opposite - they are imprecise. The problem is that people consider them to be precise.

    "Ooooh look, 16 digits after the decimal point, these things must be real precise!"

    No, they're inaccurate.  That's not the same thing as imprecise.

     

    Hmm.... they both have around 16 digits of accuracy.... I'd call that precise. :D



  • @iwpg said:

    Funny that JavaScript's result is a "WTF", yet Python, which returns exactly the same thing, is "fine".  But this is a general problem with floating point.  The worst you could say about the particular languages is that they show an excessive amount of precision by default.

    (For the record, Ruby seems to be more accurate - I'm not sure exactly what it's doing differently, but it uses floats too so it would have the same problem in more extreme cases.) 

     Duh, chalk one up for unscientific testing. I randomly typed "1.5%1" in python and as the result was round, I'd think it would be Ok :-/

    Ruby floats are really architecture doubles. But apparently, so are python floats.

    On ruby, 3.1%1 is 0.1 , while Python yields 3.1000000000000001

    Still, 4.1%1 yields 0.0999999999999996 in ruby, which I didn't test in the first place. Nevertheless, I wouldn't have used it, decimal modulo being an undocumented feature. 

    I know this is just a precision thing, as the point of float/double format is to be binary-effective and having a predictable precision.

    But on some domains, you just don't care about 1/1000000th being stored in a fairly precise format. You just want your 1/100th to be round, and never care about the rest.  Eh, put that "WTF?!?" panel down :) Sometimes we just wish default literal format were not binary-effective, but convenient for our use, so we never have to care about rounding while displaying values. Hence DateTime class in ruby using rational for day fractions, so you never need to worry about seconds not being round while displaying.

    Thus, "%1" as a shortcut is a bad idead, as its compactness purpose is defeated when you have to care about rounding.



  • Hang on, isn't March 24 a Daylight Savings Time switch?

     

    for( time = "March 1, 00:00" ; .... ; time += 24 hours ) {

    ... Ouch!

    "March 24, 00:00" + 24 hours = "March 24; 23:00"
     



  • @JvdL said:

    Hang on, isn't March 24 a Daylight Savings Time switch?

     

    for( time = "March 1, 00:00" ; .... ; time += 24 hours ) {

    ... Ouch!

    "March 24, 00:00" + 24 hours = "March 24; 23:00"
     

    I looked it up: actually DST switch in the European Union is on Sunday, March 25 on 01:00 UT

    (UT = universal time = greenwich mean time without DST)

    So the math doesn't quite work out like in my pseudo code, but I'm pretty sure it's a DST issue.



  • DST works the other way around though, we'll skip one hour in March..

    So adding 24 hours might skip March 25th instead of doubling 24th? 



  • @Whiskey Tango Foxtrot? Over. said:

    @iwpg said:
    @RayS said:

    Quite the opposite - they are imprecise. The problem is that people consider them to be precise.

    "Ooooh look, 16 digits after the decimal point, these things must be real precise!"

    No, they're inaccurate.  That's not the same thing as imprecise.

     

    Hmm.... they both have around 16 digits of accuracy.... I'd call that precise. :D

     

    no they have 16 digits of precision...  which could be called fairly accurate! :P 



  • @tster said:

    no they have 16 digits of precision...  which could be called fairly accurate! :P 

    I stand by what I wrote. Reparse and you'll eventually get it.



  • i thought this could very well go in the error'd category but i really don't know how the subjects go to the front page?



  • it's the way it works really, not a wtf: http://jibbering.com/faq/#FAQ4_7


Log in to reply