Scrapie is particularly known, deadly, and long-lived. The toxin proteins can survive for a decade in soil, and infect a new host years after it emerged.
They're all the same in my understanding, just named differently because they have been observed separately before any understanding about PrP existed. And yes, that means they're also all long-lived. These proteins do not decay like more useful molecules or more complex organic matter.
What gets me is why these prions seem to be primarily brain related. Just coincidence or is it something in the nature of mammalian brain biology that leads to prions?
There are already a bunch of prions generated in the body and hanging around neurons; the body can’t sort the invasive prions from the native ones that cause proteins to fold wrong.
Prions are attracted to or at least congregate in and around nerve cells. That's why as they spread around, they always eventually end up in the brain.
So you are saying that USA is entitled to act with criminal intent and it has no one to answer to? If that is the case, why should it be a trusted entity at all as a nation which claims human rights and democratic rights and abiding by laws?
What you will see with a general read of the criticisms in the wiki are indications of bias and several nations in Africa and South America annulling the ICC influence.
The U.S. had peripheral involvement in these actions.
I am upvoting you, as I don't find your line of questioning abrasive enough to warrant down votes.
Well there is always bias but that is not just about bias but having an entity above nation state that can provide a ruling on wrong doings. For example, the most powerful nation on earth occupying some country to extract its resources without any entity than can do anything about it, is criminal wrong doing. Yes there is going to be bias but not if they are providing the evidence.
I am not talking about the current ethnic conflict between Israel and Palestinians because that is a century worth of conflict has gone far beyond what courts can rule on. I am talking about USA absolving itself from being accountable in presence of evidence.
There are several reasons why Fortran historically has been faster. Many of these are because Fortran is less strict about what the compiler can do so allows optimizations that wouldn't be allowed in C. Such as:
- Procedure arguments are not allowed to alias. Similar to restrict pointers in C99+. This is often critical to allow loops to be vectorized, but the onus is on the programmer to ensure no aliasing or else you get UB.
- Unspecified evaluation order for expressions. E.g. C requires that "a+b+c+d" be evaluated as "((a+b)+c)+d)" and with floating point it can't do it another way due to rounding. Fortran can do e.g. "(a+b) + (c+d)" where each subterm can be computed in parallel, but again at the cost of slightly different results due to rounding behavior for floats.
- Old school Fortran lacked pointers which led programmers to program algorithms using arrays rather than fancier data structures, which cpu's love.
In principle there's nothing preventing a competent C or C++ programmer can reach Fortran level performance. In practice, might be difficult.
Of course, nowadays performance is much about designing for cache hierarchies (see e.g. "Data Oriented Design") where Fortran doesn't have a built-in advantage.
In short, people solving numerical problems want to write like M[i,j] where i is iterated through on the innermost loop and j is iterated through on the outermost loop... and if the language works in sympathy with them and gets good cache-coherence, that's great, but if the language works against them and would make them write M[j,i] to get the same performance, they don't like it, so they keep writing M[i,j] and let the slowness be the other language's problem.
Nah, that is mostly about keeping the ordering in mind when iterating (e.g. do you iterate first over innermost or outermost index?). And there are algorithms such as (naive) matrix multiplication where the correct order for one matrix is the wrong for the other one, so plus ca change.
But speaking of arrays, one definitive advantage of Fortran is that it has built-in multidimensional arrays in the language. Which is very nice when writing code that needs them. In C many people resort to the Fischer-Price My First Multidimensional Array implementation where they allocate each row separately, which is of course horrible. (In C++ you can use libraries like Eigen or Armadillo which use expression templates and operator overloading to have sensible multidimensional array support even if it isn't built-in.)
Uh... C does have multidimensional arrays. Writing "int a[5][10]" allocates the same contiguous storage as "int b[50]", and accessing a[3][7] will access the integer at ((char *)a) + 3*sizeof(int[10]) + 7*sizeof(int), which would be the same offset as b[37].
It has to be row-oriented because the language allows you to take the address of each intermediate dimension, e.g. int *c = &a[3] gets you a pointer to the equivalent offset of b[30], and legally you can access c[0] through to c[9]. Accessing c[10] would be equivalent to a[4][0] and compilers will let you do it, but I think it's officially undefined behaviour?
There is not a lot of floating point in an operating system.
The issue with floating point and aliasing preventing vectorisation was from the late 1980s when early C compilers lacked sophisticated alias analysis and standards were loose. is not a really a thing anymore. C can go as fast, specially compiled with strict aliasing. Maybe more work in compilation.
The last Unisys release, the Dorado from 2015 (ClearPath Dorado 8300 to be exact), used Xeon processors (which are 64-bit x86_64). But, for argument’s sake, let’s suppose there’s a Unisys 2200 out there with 36-bit registers and GCC/clang makes a C2y compiler for it.
If so, then said compiler should still have support for (u)int_8/16/32/64_t. Said compiler already needs to have that support with (unsigned) _BitInt(8/16/32/64)—and, yes, one can also have 36-bit ints on x86_64 in C23 with _BitInt(36) if one must—and allowing stuff like int32_t and uint32_t will allow said (imaginary) 2200 system to cleanly compile a lot of pre-C23 open source code out there. Yes, uint32_t will look a little ugly at the assembly level, just as _BitInt(36) will look a little ugly on, say, a Xeon processor, but the code will compile and run the same.
Of course, these days they can buy tokens so an agent can do any relevant porting, but still.
'In December 2024, 38 scientists, including several synthetic biology researchers and two Nobel laureates, warned that the creation of mirror-image life could cause "unprecedented and irreversible harm" to human health and ecosystems worldwide. The reversed structure of mirror-image bacteria could allow them to evade many mechanisms critical for immunity and predation that have evolved to recognize natural-chirality structures. As a result, mirror-image bacteria could potentially escape immune defenses and invade natural ecosystems, leading to "pervasive lethal infections in a substantial fraction of plant and animal species, including humans."'
You don't need a mirror image organism to cause great harm. An engineered prion could also be devastating.
I don't think preons are technically mirror molecules, but it's close enough from a risk perspective. If rogue AI were to do us in through bioengineering, it might be by creating a novel prion.
Unfortunately, there are several prion diseases already in existence: scrapie in sheep, BSE in cows, Chronic Wasting Disease in deer, and both Kuru and Crutzfeld-Jacob in humans.
Scrapie is incredibly durable in the environment; the prion toxins can remain transmissible in the soil for a decade, causing disease years after it was shed by its previous host.
Everybody is worrying about the AI torment nexus, meanwhile, we're grinding up cows (and sheep) and feeding those bits to cows and then people eat the cows and go crazy.
Actually, scrapie itself is conjectured to trigger BSE.
"Cattle are believed to have been infected by being fed meat-and-bone meal that contained either the remains of cattle who spontaneously developed the disease or scrapie-infected sheep products...
"The British Government enquiry took the view that the cause was not scrapie, as had originally been postulated, but was some event in the 1970s that could not be identified."
Smalltalk didn't start until 1971/2 (Alan Kay started at Xerox in early 1971 as a consultant and then joined as a full time member). It's covered in the HOPL article above
Brian Harvey> I admit that my slogan "Snap! is Scheme disguised as Scratch" would sort of push in the direction of hygienic macros. But historically we built Snap! more with the idea of Logo disguised as Scratch. It was just when we added lambda that we started thinking more in Scheme terms.
Alan Kay> The fact that kids were to be the users, and the simplicity and ease of use of the already existing LOGO, whose own parents were LISP and JOSS (which set a standard for the esthetics for interaction that has not yet been surpassed), provided lots of motivation to have programs and transactions appear as simple as possible-i.e. moving from left to right, procedures gather their own messages, etc. It is no accident that simple SMALLTALK programs look a bit like LOGO!
Don Hopkins> Here is the source code to LLogo in MACLISP, which I stashed from the MIT-AI ITS system. It's a fascinating historical document, 12,480 lines of beautiful practical lisp code, defining where the rubber meets the road, with drivers for hardware like pots, plotters, robotic turtles, TV turtles, graphical displays, XGP laser printers, music devices, and lots of other interesting code and comments.
Lars Brinkhoff suggests that this comp.lang.logo thread with Brian Harvey and Leigh Klotz is required reading:
Brian Harvey> Wally Feurzeig started the whole thing by organizing a group at Bolt, Beranek, and Newman, Inc., to study the educational effects of teaching kids a programming language. The first language they used, like most programming languages, was focused on numeric computation, and it was Wally's idea that kids would find it more natural to work in an area they knew better, namely natural language; therefore, he set up a team to design a language featuring words and sentences. Wally made up the name "Logo."
Brian Harvey> The team Wally put together at BBN included Seymour Papert and Dan Bobrow. The three of them are credited as the designers of the first version of the language; Dan wrote the first implementation.
Leigh Klotz> In the mid 1970's, when the AI Lab Lisp Machine project was just getting underway, Marvin Minsky and Danny Hillis (later to found Terrapin, and still later, Thinking Machines) put together a project to build a Logo machine.
Lars Brinkhoff> Now also BBN PDP-10 Logo, MIT CLOGO, MIT Lisp Logo, and hopefully soon MIT Apple II Logo (direct ancestor of Terrapin Apple II Logo).
They were:
Inspur K-UX (expired on 3 February 2019)
Huawei EulerOS (expired in September 2022)
https://en.wikipedia.org/wiki/Inspur_K-UX
https://en.wikipedia.org/wiki/EulerOS
These were both based on Red Hat.
reply