• (nodebb)

    locales that insist on using weird ass units are

    Or in this case, essentially only a single country insists on using these "weird ass units", the other 10 who use it exclusively are so small that they only do it because of that one significant, but "weird ass", country.

  • (nodebb)

    Which, I want to stress, this code comes from an open source project for home automation, so it's not the code that's wrong, here.

    I'm going to ignore the grammatical hash at the beginning of the sentence, and concentrate on the implied assertion that "open source project" directly implies "the code is not wrong"...

    This is completely bogus as reasoning, as if the mere act of opening the source somehow makes the code correct. Even "It's F/OSS and it has been out for at least ten years, therefore the code is not wrong" is still bogus, if it's about a boring bit that apparently just works. (Noteworthy point - the tables in these functions might be mostly incapable of breaking anything because it almost never gets to be sufficiently exact to match any of the numbers in the table...)

  • Pag (unregistered)

    Fahrenheit was originally defined using average human body temperature as 96 degrees F. You could measure this using an ass thermometer. Then the units would be better described as average-ass then weird-ass.

  • geoffk (unregistered)

    I suspect the microcontroller doesn’t even have a divide instruction, and probably code size was a concern. If so it might not use a table, but rather a small chunk of code, on the order of 10 bytes or so, to do the conversion. It could use a bit shift to do the divide by 2.

  • (author) in reply to Steve_The_Cynic

    It's more, "I don't want to pick on a small project made by enthusiasts".

  • (author) in reply to Pag

    Pedantically, it was supposed to be 100 as human body temperature, so the calibration ass was in fact, a weird ass. Or at least had a fever.

  • Officer Johnny Holzkopf (unregistered) in reply to Remy Porter

    Even more pedanticallillery, the correct unit symbols are °C for "degree Celsius" and °F for "degree Fahrenheit", as opposed to K for "Kelvin" (absolute temperature; temperature difference), which formerly also had °K.

  • (nodebb) in reply to geoffk

    I suspect the microcontroller doesn’t even have a divide instruction, and probably code size was a concern. If so it might not use a table, but rather a small chunk of code, on the order of 10 bytes or so, to do the conversion. It could use a bit shift to do the divide by 2.

    OK, that's nice, but consider that it's a floating divide, and therefore the bit shift won't work well. Consider that the "code size because of libs we pull in" would speak aggressively against having the real calculation as a backup option.

  • (nodebb) in reply to Remy Porter

    Then you should say so.

  • (nodebb) in reply to Steve_The_Cynic

    It's also necessary to consider also the other piece of wrongness in the code, which I only just noticed. Because the table variable is not static, it populates (and destroys) the table every time anyone calls the function, rather than just the first time.

  • Shawn P (unregistered)

    I'm a big fan of the metric system in almost all contexts, but I think Fahrenheit is actually the better scale for temperatures humans experience (weather, room temps). 100 is fairly hot, 0 is fairly cold, and a one-degree change is right about at the level of perceivable difference. C (or K) all the way for science, baking, industry, etc. but I'll keep my freedom units for temps I feel, thank you. :)

  • (author) in reply to Shawn P

    My unhinged metric take is that it should be a base-60 system, simply because it's got way more divisors than a base 10 system. Which would amplify the problem you're complaining about, admittedly, but we can just go to the next power.

  • (nodebb)

    I just think it's impressive that someone reverse-engineered all of the temperature options the remote could support. It honestly should never hit the "failed to find the key" part because what's the remote going to do with something it doesn't support?? It should pick the closest key or reject it.

  • 516052 (unregistered) in reply to davethepirate

    Or crash. It could crash.

  • Fryfan (unregistered) in reply to davethepirate

    @davethepirate: Looks like it's using the remote mappings unless the input is out of range, and then it just calculates it properly. Perhaps the function is used elsewhere too (which is a little wtf in itself).

  • (nodebb) in reply to Fryfan

    Looks like it's using the remote mappings unless the input is out of range

    Or in the middle of the range but not on one of the precise points.

  • (nodebb) in reply to davethepirate

    I just think it's impressive that someone reverse-engineered all of the temperature options the remote could support. It honestly should never hit the "failed to find the key" part because what's the remote going to do with something it doesn't support?? It should pick the closest key or reject it.

    Does this mean the remote does not support 19.5 or 20.5? If it did, there is no reason for the table. The function should just return the calculated number for values between 16°C and 30.5°C (61°F and 88°F) with some reasonable "default" like 22°C/71°F (or NULL) if the value is out of bounds. (This requires the unit to handle NULL and not change the temperature, which we cannot guarantee from this code.)

  • (nodebb) in reply to geoffk

    I'm surprised it even has floating-point math in the first place. I would have expected some fixed-point stuff. Or a mapping of strings to actual temperature values.

  • (nodebb) in reply to Jonathan Lydall

    I object to the characterization of my country as "weird-ass". Weird-ass is WWAAYYYYY too mild for the current state of things.

  • Hmmmm 🤨 (unregistered) in reply to geoffk

    Odd that they skip 19.5 and 20.5...

    Also, weird-ass units are great when you don't have anything but your own body parts, a polished stone and maybe 7,000 wheat or barley seeds to measure things with.

  • Fikitus of Borg (unregistered) in reply to Shawn P

    Fahrenheit is a better scale for temperatures THE MINORITY of humans experience. Besides 0°F being way too cold and 100°F being way too hot (ok, the latter being more common lately), all the humans I know in 3 continents are more used to think "15°C is too cold for confort, 30°C is too hot for confort". Me? I could get used to set the A/C at a confortable 295K despite having used °C all my life, if that means do without the whole weird units for everything and use Kelvins, meters and grams. Get rid of DST while we are at it, and maybe standarize 30-days months +5 yearly "non-dates". Yes, I am a radical.

  • Acronym (unregistered) in reply to Shawn P

    That's US-centric thinking. Me on the other side of the world stop having words for how cold it is at about 40º F. I never experienced an ambient temperature lower than 35º F. At the other end, temperatures over 100º F, while hot, are still bearable and it's a common occurrence for temperatures around here to reach 104º F. It's a garbage scale for most of the world (by population).

  • matt (unregistered) in reply to Remy Porter

    Someone better get a glass of water for my butt. Someone better call a special doctor for my butt.

    (One other thing I've heard about Fahrenheit is that 98.6 is not actually an especially accurate average body temperature, but an overspecific conversion of the integer Celsius value of 37.)

    ((New captcha, eh? No more traffic lights and bridges?))

  • (nodebb)

    Moving up a meta level.

    One heck of a lot of everything sold in the USA is now designed and made elsewhere. By and large all those engineers think in SI and their materials come in stock SI-based sizes. Same for the software. It's written by people who think in SI for customers who think in SI. US customary units are bolted on afterthought at best.

    Poking our nose into the code of almost any device with a microcontroller and USA-compatible units is going to expose something similar to this article.

    e.g. I have a "smart" bathroom scale. It has an (undocumented) hysteresis feature where your displayed weight won't change if you gain or lose a small amount. Only if you gain or lose a large enough amount will it display your new weight as opposed to re-showing you the last displayed value. Turns out the hysteresis cutoff is 1 Kg. Which is kinda wacky when expressed in archaic US customary pounds. But makes lots of sense for their internal implementation on a very simple processor.

    Units conversion for display purposes only is the name of that game. And Americans, as the "victims" of those half-assed conversions can expect lots of these kinds of anomalies.

  • (nodebb) in reply to Pag

    Didn't have have a slight fever at the time, throwing the reading out slightly? So they definitely would be weird-ass units.

  • (nodebb)

    Given the ridiculous resolution of the unit, particularly since it's measuring the inlet temperature which often only bears a passing resemblance to the actual room temperature, that wouldn't be a Daikin would it? So you can reliably set the wrong temperature with 0.5-degrees resolution.

  • A Human (unregistered) in reply to Fikitus of Borg

    I can get around kelvins for temperature (although celsius is nice because the numbers are small). I can definitely get around reforming the calendar so we have 30 days in every month.

    But noone can take away my daylight savings. There is no way that a reasonably sane time zone can allow the sun to produce light at 6am, or get dark at 5pm. That is just absurd, and is why dst exists.

  • 516052 (unregistered) in reply to A Human

    That's the worst. Back when I was still working I remember always dreading winter DST because it would move the clock backward and thus cause it to be night already when my job was done. And there is no feeling in the world more demoralizing than getting out of the office and looking up at the sky to see that the day has already passed.

    I used to literally call those the "dark days". Which in my local language is an idiom for terrible times like famines, plagues etc.

  • Drak (unregistered) in reply to A Human

    You mean like in the winter, where that is normal around here, to have it get dark around 5pm (17:00)? Sunset is at 16:30 on 21 dec where I live. And it should be at 15:30 because we are in the wrong timezone due to something that happened halfway through the previous century. A bit west of here, in a country where they also used to use weird units, and they drive on the wrong side of the road, the sun sets before 16:00 on 21 dec.

  • uhn (unregistered) in reply to Remy Porter

    @Pag

    If it was meant for average human body temperature then they probably shouldn't have measures an ass's temperature in the first place.

  • MangusPI (unregistered) in reply to WTFGuy

    One heck of a lot of everything sold in the USA is now designed and made elsewhere.

    There is also a lot of things designed in the USA and manufactured elsewhere. Also domestic production has been increasing there as well.

    And Americans, as the "victims" of those half-assed conversions can expect lots of these kinds of anomalies.

    And yet I have seen plenty of products like smart scales that do conversions far more sensibly, even cheap ones from China, so it really isn't an excuse for piss-poor conversion algorithms; stop using hideously bad products from places like Wish and Temu or similar vendors on other sites Ali, eBay, etc.

  • MangusPI (unregistered) in reply to 516052

    That's the worst. Back when I was still working I remember always dreading winter DST because it would move the clock backward and thus cause it to be night already when my job was done. And there is no feeling in the world more demoralizing than getting out of the office and looking up at the sky to see that the day has already passed.

    This is why businesses shouldn't start and stop based on a set time but based on the sun instead. Some do exactly that and it appears to work a lot better. You can also go into business for yourself and control when you start and end you work time.

  • (nodebb) in reply to geoffk

    I suspect the microcontroller doesn’t even have a divide instruction

    Some do, some don't, but it (and float support) are extras that add slightly to the cost, and doing them in software isn't too bad providing you've got spare code space. Fixed-point divide doesn't take that many instructions; a floating point library takes a fair bit more (especially if you need double precision too).

  • (nodebb) in reply to A Human

    There is no way that a reasonably sane time zone can allow the sun to produce light at 6am, or get dark at 5pm. That is just absurd, and is why dst exists.

    You are showing your latitude privilege. In London, if you want it to be "still dark" at 6am on the Summer solstice, it would be still light at 11pm - and later if you want it to be properly dark at 6am. Conversely, in the middle of winter, if you want it to be light at 5pm, it would still be dark at 9am.

    In Glasgow, which is in the same time zone as London, it is worse. If you want it to be dark at 6am on the Summer Solstice, it would still be light at midnight. If you want it to be light at 5pm on the Winter solstice, it will still be dark at 10am.

  • (nodebb)

    TRWTF is that the table is not just an array and the remote doesn't just have (Up and Down) buttons to move the index in that array.

  • (nodebb) in reply to n9ds

    I was always under the impression that the remote only did have up/down buttons. The control unit then goes up or down through the table (hopefully not going off the edges) but can display in both F/C. You can't enter "Make my temperature 71.2 degrees".

Leave a comment on “Heating Up”

Log In or post as a guest

Replying to comment #704033:

« Return to Article