I misread lucubratory's comment: indeed I see the same as you do. I only tried asking both question in the same session. I didn't see that point in the paper when I quickly skimmed through it to find the relevant part.
I also agree with him about humans capable of the same "errors".
You are moving away from the topic, which is the question of whether AIs know true and false.
Your first statement was that "they don't know true and false, because they don't know anything in the cognitive sense of using innate emotional and logical reasoning (faulty or not) to come to a self-directed conclusion of their own."
> An example I can remember from the paper is "Who is Tom Cruise's mother? [Tom Cruise's mother's name]" paired with "Who is [Tom Cruise's mother's name]'s son? [incorrect answer or "Can't answer that"]".
The paper is, apparently, still under review.
In the mean time, may I suggest you to verify that example by yourself?
> It's not totally clear to me why simt won out over writing the vector operations.
From the user side, it is probably simpler to write an algorithm once without vectors, and have a compiler translate it to every vector ISA it supports, rather than to deal with each ISA by hand.
Besides, in many situations, having the algorithm executed sequentially or in parallel is irrelevant to the algorithm itself, so why introduce that concern?
> I'm certainly in the minority opinion here.
There are definitely more userland programmers than compiler/numerical library ones.
You make a valid point: I used the word "bug" here without trying first to define it, and that led to confusion in my mind, and thus in my comment.
In that comment, I used the example of programs performing an ascending sort or a descending one. While both programs would be valid, one of them, at least, would not correspond to the intent of the programmer. From an engineering perspective, that would be considered a bug.
I guess an informal yet hopefully apt definition of the word bug could be "an error in the source code of a program leading to an incorrect behaviour of that program at runtime". That incorrect behaviour can take many forms: the most obvious one is the program breaking in the middle of a computation, without providing any result (a semantic bug). A second one is when the compiler will not accept the program as valid (a syntactic bug). A third one is the program producing the wrong result, as in my example (also a semantic bug).
In my mind, I only considered the first 2 kinds of errors as bugs, and qualified the last as something else, perhaps for the reason that only the programmer may really know the intent behind a program's implementation.
One of the goals when designing a programming language is to help reduce the occurrence of bugs. The main strategy is to turn bugs of the first kind (semantic) into bugs of the second kind (syntactic), or at least that is my understanding.
Concretely, with a powerful enough type system, one may express expected properties of a program using the provided syntax, and let the compiler validate these claims using only formal rules.
The way you use the word "correct" is interesting: in PL theory circles, it usually means : "bug free", but it appears that you use it to mean: "produces the results I'm looking for".
Indeed, one may write a program which is bug free, yet does not implement the algorithm that produces the expected result (for instance, a program sorting data in ascending order, when a descending order is needed). In strongly typed languages, type systems are used to ensure that programs are bug free, following the adage : "if it compiles, it works". The issue of having a proper implementation is not a concern of researchers in their papers, it's purely an engineering problem, so there is no interest for them in using the word correct in that sense.
Also, with type inference, one often does not have to mind too much about types, and instead gradually introduce type annotations to lift disagreements between the compiler and its user.
Gradual typing is yet another tool to achieve a similar result.
It's interesting. I remember seeing the air duct on CPU in Dell servers a long time ago, I wonder if they still do that.
Also, it would have been nice for the author to try each duct individually, so as to better understand their role in temperature reduction on every devices. Would the CPU air duct indirectly help the GPU by reducing the box temperature overall?
Finally, I wish he also measured the impact on energy consumption.
> Battery life kinda sucks but I'm not going to fault Framework for that, I am running Linux and have done nothing to improve the situation on my end.
Just in case you haven't yet looked into it:
It really depends on the distro you are using. I assume that some willship with great support (read: automated) out of the box, but others might require a bit of manual setup.
The "powertop"[1] tool from Intel is a CLI app which let you see where energy is going and tune the system to reduce consumption.
From my own experience, the automatic tuning mode does fair job, but the mouse setting was a bit too aggressive for my taste (I think that the tool only saw it as a lambda USB peripheral), so I had to override that setting. I also wrote a simple configuration file for a systemd service to have it executed at boot time, but I lost that lately because of a drive crash, so I cannot help you more than just telling you it's doable, if you're willing to dig through the man pages.
Well, I don't think that network at the time was faster than SCSI, but that's a fair point that X11 isn't quite "internet ready" (though these days with a dedicated VPN you'd probably get very good performance on the core protocol).
> No, I'd say X11 wasn't designed to be run on the network [...]
That's just wrong. X11 was designed from the ground up to be used on the network. It just happens that nowadays requirements are different from when it was originally designed.
Running X11 on the network was quite a thing in Unis all over the world, where you could have dedicated dozens of X11 graphic terminal servers (tektronix used to make good ones) connected (100Mbits) to a single mainframe, and everyone running an Xemacs session without slowdown.
Wayland design is all about framebuffers, which clearly shows how focus has shifted. X11 was not designed for pixmap heavy, shader heavy scenarios.