Still frustrating (if the taxpayers want it, might as well let them have it), but not purely a semantic technicality.
6,395 karma · joined April 19, 2017
Still frustrating (if the taxpayers want it, might as well let them have it), but not purely a semantic technicality.
I think even this view is missing the point.
My opinion is that most people are overcomplicating this whole issue. When people react negatively to the term "AI", it's simply because the vast majority of features branded "AI" in the vast majority of products, are pure garbage. Searching for some deeper cultural or psychological reason is a waste of time - let's just stop pushing garbage AI products, then maybe someday people's perception of the term will change.
Until then, just leave that word out of the marketing material. Nobody really cares how the product is implemented, just focus on what it does.
QEMU is an emulator that can run entire operating systems, because it emulates hardware devices like hard drives and displays. Unicorn doesn't emulate any of those things, it only emulates the CPU. It's probably mostly useful for compiler development and security research / reverse engineering.
It vaguely sounds as though there is some sort of nuclear deal in the works ... but the US already had a nuclear deal with Iran, that Trump tore up. So I guess you could squint and say that the US won something back that was previously foolishly discarded.
It sounds to me like there is some point in this project's history when both of the following were true:
1) It was a C++ raytracer
2) It was entirely human-written
So technically there is no lie here.
Apple was already a multibillion dollar company almost 30 years before the iPhone was invented...
(though I'm sure you will have no trouble inventing some other reason that that wealth, too, was created through exploitation)
The context of this thread is that someone stated that the C++ standard library sucks, and someone replied to them saying that it's just some implementations that suck, but that's separate from the language. The point I'm trying to make, in response, is that it is about the language. It's not just "some" implementations - there is no implementation of the C++ standard library that doesn't have these inefficiencies, because the language's own standard requires them.
(This is tangential but - this is why I often say that C++ is not actually the most complex language in the world, it's just over-specified. If you took almost any popular programming language and wrote a document dictating the behavior of every single feature and library to the same level of detail, you would end up with a document similar in length or even longer than the C++ standard.)
For example, the standard says that adding elements to an <unordered_map> is not allowed to invalidate references to keys or elements within the map. That makes it impossible for any standards-compliant C++ implementation to use a high-performance implementation in which keys and elements are stored contiguously in a flat array.
Very serious, though in practice it doesn't sound like this bug achieves arbitrary RCE on its own (especially in the presence of ASLR). You would need there to be some writable and executable page of memory lying around.
Automated verifiability goes down once a software project incorporates things like:
- Concurrency
- Networking / distributed systems
- Visuals / animations
- Domain knowledge (e.g. banking, finance)
There is something about intelligence that seems to carry a degree of... moral responsibility, somehow? Though in reality it's just an animal eating another animal, as ever.
> Now, we all know that it can take a while to find a long sequence of digits in π, so for practical reasons, we should break the files up into smaller chunks that can be more readily found.
> In this implementation, to maximise performance, we consider each individual byte of the file separately, and look it up in π.
So, they're naturally able to influence the West way more than the West can influence them.
Whereas my point is moreso when, the variables really are correlated but it's purely due to random chance. Not bullshit, per se, just bad luck (or possibly, p-hacking).
(Though the solution to both is the same - you shouldn't trust a study until it's been independently replicated on new data.)
That often results from p-hacking. In a world of infinite variables, if you look hard enough you are guaranteed to eventually find two completely unrelated variables that correlate with each other over a statistically significant period of time.
As a love letter it's very sweet - you clearly have found something special.
As life advice - I mean, not everyone's ideal relationship is gonna look like this, and that's okay too.
> Slots are stable for the life of the process; the heap grows with distinct content only.
So how is a program supposed to handle lots of unique content? Like a web server handling user requests?
A macro like (logged-fn) that defines a function which logs the arguments passed, is wonderful.
But if you see a macro like (validate-report), something very wrong happened.
I echo the parent commenter - the STL has a massive negative impact on compile times. And for what? The STL is not even fast. The way the standards are written, std::unordered_map has to be implemented as a tree rather than a flat open-addressing hashtable, which would've been far superior due to cache locality.
For my own project I rolled my own string, string_view, map, set, optional, variant, and vector. Only took maybe a day. And that day has paid dividends, as my clean debug builds literally take 3 seconds now.