Literally the definition of the integers is that (x + 1) != x. Wrapping is bad enough, but at least tends to makes failures noticeable. Saturating arithmetic makes it really hard to see that a failure has occurred.
Depending on the performance penalty you're willing to take, there's good alternatives to wrapping, such as: A) 64-bit integers, B) bigints, C) crashing on overflow.
Sure, saturation might be useful in certain circumstances, like manipulating audio samples, but it's generally something you want to make explicit. Using it everywhere? It's madness!
Say you're computing a buffer size with untrusted inputs.
With saturated arithmetic, you could add the (unsigned) sizes together without a possibility of an overflow, so you could eliminate all except the last range check (=branch).
If the end result is larger than what is reasonable, return an error. It's not possible that the value wrapped around and later code will be writing to unallocated memory.
That doesn't actually eliminate range checks. Hardware doesn't have native saturating overflow operations so the saturating overflow methods are implemented by doing a checked overflow and using the min/max value of the type if it overflows/underflows. Which is to say, it removes them from your code, but there's no performance benefit to it.
They do? I admit I'm not an expert on either x86 or ARM assembly, but I've never seen code that used a saturating arithmetic instruction, and the saturating math in Rust is implemented using checked arithmetic as opposed to any kind of llvm intrinsic for saturating math. Looking at the LLVM docs I don't see any kind of intrinsic for saturating math either (checked math uses llvm.sadd.with.overflow.* and friends).
How easy it is to decide for others if they are mad or not, even not asking them about details... No worries, I'm not proposing it as default for all, I was just asking if it's possible to set as flag for some programms.
It also lacks what you might call 'forward secrecy'. If someone gets access to my master password and an old 1password backup, then they get all the passwords in the backup.
But with this, if someone gets access to my master password, they get access to recent passwords, and when I create new passwords they get access to those too. If I'm not aware that my master password has been compromised (why should I be?) then I'd be merrily creating new passwords that are compromised at the moment of their creation.
That just means == is a "lossy" equivalence relation. I rather the precision be truely observable----every number is "infinite precision". Once can always include natural as extra field if one cares about empirical precision.
I'm having a bit of trouble parsing this, but Ion decimal values are not "infinite precision". Every decimal has a very specific, finite precision. It's a standard "coefficient and exponent" model, with no specification-enforced limit on either.
Maybe it is a failure of imagination, but I don't get how nest can be more efficient than manual control. Cold? Switch the heating on. Hot? Switching the heating off. Why'd you need a learning algorithm for that?
The website says stuff like
> The babysitter calls to say she picked up the kids from soccer and they’re heading home. You adjust the temperature from your phone so they’ll be cozy.
..which is a first-world problem if I've ever heard one. Just wear an extra layer for 10 minutes while the heating warms up. Jeez.
The point is to spend very little energy while no one is home, but converge the house back to a comfortable temperature by the time someone gets home. You are not present to actuate manual controls when you're not home. Programmable thermostats have been doing this with schedules for decades, but they tend to have shitty UIs and not every household runs on a regular schedule.
>for 10 minutes
Whenever we'd come back from vacation, it would take my house at least 3-4 hours to move from ~40 to ~70. Our house was actually pretty small for the neighborhood. Being able to kick the heating back on from a few hours away in the car would have been amazing. I think you have a hilariously overpowered furnace, a tiny space relative to Midwestern suburbia, or an exceptionally temperate climate.
This is a highly unusual situation (not to mention dangerous in the winter) to turn off your heat. Certainly not something you would worry about when trying to make a babysitter cozy.
Not all the way off, but there is a wide margin between comfortable and safe where it is generally cost-effective to let the temperature rest when you are not home.
Well, to be honest, a lot of things we can't live without now (like having clean and hot water in the tap) were "first-world" problems only few decades ago. The progress of civilization is measured in the amount of things we don't have to care about anymore.
You're right, but I guess you're being downvoted because nobody wants to hear it. JavaScript will never get anything like numpy, because it doesn't have integers. Doing mathematics without integers is like driving a car without wheels.
Combine typed arrays with BLAS and you have yourself a numpy (well, kind of). In Node you can move performance-critical code to C++, which does have integers. Browser support of typed arrays is a bit disappointing, but it's getting better.
It's interesting that you give the example of Breivik. Don't you think that a far-right nutcase like him would relish the reinstatement of the death penalty?
The average person isn't even aware that VLC is an illegal circumvention tool in the United States under the DMCA. I fail to see how restrictions on encryption software would have a different outcome. Encryption is built into so many products, it's part of daily life and most people don't even know they're using it.
> I fail to see how restrictions on encryption software would have a different outcome.
The enforcement of any law passed would of course be impossible.
The reason we fight it is the implications. While our government and people depend on access to such encrypted communications, our society won't be focused on the right kind of ways to keep each other safe.
So, we should educate each other on the facts and prepare each other for a future where more and more criminals will communicate in hidden ways. On balance, we will be better off with encryption, because there are more good things that come with it than bad. But the bad things are something we can either choose to prepare for, or pretend they do not exist. I choose to prepare.
While they can't actually get rid of encryption, they can definitely make it so that actual secure cryptography is not the default in the devices and sites that the majority of purple use. If Chrome, Amazon, Android and iPhone don't support strong encryption (at rest and/or in transit), then for almost all situations encryption will be weak.
This is particularly problematic when there are network effects (e.g. messaging, email, standards acceptance), because anything that becomes the standard is an immediate target.
The comment system on HN discourages discussion of the article, because threads cannot be collapsed and so there is only space for 2 or 3 top-level comments to get much attention.
The top comment is often a poor quality one, expressing some controversial view that gets replies, starving the lower top-level comments of upvotes, and cementing its place at the top.
It would be better to collapse replies to all top-level comments, and allow people to expand the replies to the comments they find interesting.
I'm a fan of experimenting with voting systems, and as this never happens, i'm always disappointed. I think it would be great if the order of comments was always random and scores were never shown (I don't care what people think of other people's comments; how can an opinion have a score? the very idea is preposterous). It would encourage people reading more comments, and not being either fearful of losing points or posting comments just to get a higher score.
Worth noting, the score is intended to be an objective measure of correctness — well sourced, clear, and reasonable comments aught to add to the score, rudeness, questionable sourcing/factualness should not. Ideally.
The problem is, given the current strict comment ordering system & the fact that many (myself included) read comments top to bottom, a 15 in the top position for two hours may in fact be equal to a 3 that's farther below.
I hadn't thought about it when I started writing this, but I'd be curious what comment ordering results a points/time value function would produce. Although a fuzzy random ordering would still be needed to ensure that lower comments got enough viability. So maybe points/time/position-at-vote-time
PS: That said, collapsing comments to promote more equality between highly rated level 1 comments would be an excellent idea.
Depending on the performance penalty you're willing to take, there's good alternatives to wrapping, such as: A) 64-bit integers, B) bigints, C) crashing on overflow.
Sure, saturation might be useful in certain circumstances, like manipulating audio samples, but it's generally something you want to make explicit. Using it everywhere? It's madness!