GrantMoyer

Your step 3 is an insertion op, not a bubble op.

An insertion op inserts one element into a sorted list. A bubble op bubbles the maximum (or minimum) element to the end of an unsorted list.

Interaction nets: https://dl.acm.org/doi/pdf/10.1145/96709.96718

> Surely there must be a middle ground between allowing free abortion and having women die of sepsis.

You're absolutely right, and we know so, because that middle ground actually existested before Roe v. Wade was overturned. Abortion was available but regulated.

Actually, the opposite is true. The rationals have measure zero, so a number selected uniformly at random from 0 to 1 (formalized way of placing a dot on a number line), has a 0% chance of being rational.

One important aspect (to me, at least) that the article doesn't mention is that physical media comes with actual ownership rights (first-sale doctrine), and that by whatever lucky coincidence publishers weren't able to introduce widespread DRM to physical audio media.

The linked article doesn't say the submitted driver code was awful. In fact, it says Paragon submitted the driver after Linus suggested they submit it.

What the article quotes Linus complaining about is a process issue. Paragon apparently used GitHub's GUI to merge some of their branches rather than the git CLI. Linus would prefer they use the CLI to merge branches because the GitHub GUI reportedly omits important metadata from merge commits, such as the developer email, and encourages uninformative commit messages.

In addition to being very technically interesting, I think this is among the best executions of a "humorously flippant" tone I've read. I particularly enjoyed:

> They’ll simply describe an interactive protocol with the right structure, then they say something like “of course this can be flattened using Fiat-Shamir, if we assume a random oracle or something” and everyone nods and deposits a billion dollars onto it.

C++ has had a few options since C++11[1].

- Linear congruential generator[2]:

  xₜ = a xₜ₋₁ + c mod m

- Mersenne Twister[3]:

  too complicated for a few lines

- Subtract with carry[3]:

  k < p
  carryₜ = [xₜ₋ₖ - xₜ₋ₚ - carryₜ₋₁ < 0]
  xₜ = xₜ₋ₖ - xₜ₋ₚ - carryₜ₋₁ mod 2ⁿ

All three algorithms are fairly popular.

(Please excuse the unidiomatic index and constant names, I'm at the mercy of unicode)

[1]: https://en.cppreference.com/w/cpp/header/random

[2]: https://en.wikipedia.org/wiki/Linear_congruential_generator

[3]: https://en.wikipedia.org/wiki/Mersenne_Twister

[4]: https://en.wikipedia.org/wiki/Subtract_with_carry

Note that you need to use 3 shifts. All the triplets of shifts listed in the paper should generate sequences with period 2^32-1 or 2^64-1 depending on the state size, because the tables were generated with that constraint. For example the first triplet for a 32 bit state corresponds to the algortihm:

  def advance_state(state):
    state ^= state << 1
    state ^= state >> 3
    state ^= state << 10
    return state

I've hit issues with bad quality PRNGs when using them for Monte Carlo path tracing. With a non-uniform PRNG, the simulation can take a lot longer to converge to a clear image, because some ray paths can be severely under or over represented.

Xorshift is really cool because of how simple it is to comprehend and implement despite how well it works as a PRNG. The initial paper describing it, "Xorshift RNGs"[1], is surprisingly short and approachable, and I encourage anyone with any interest to read through it.

[1]: https://www.jstatsoft.org/article/download/v008i14/916

Seems like a great time to stop eating eggs.

DMCA and Trademarks

Follow up to my earlier comment; The docs say creating a reference to uninitialized memory is undefined behavior, but I couldn't think of any cases where it would go wrong if the data is never actually accessed. It turns out that's because there currently aren't any. See comment [1] and the threads linked there.

Rust calls references to uninitialized memory undefined behavior because it wants to reserve the right to implement some kinds of optimizations using that fact in the future, however currently no optimizations do, and in fact the standard library depends on the compiler being well behaved here.

It's possible at some point in the future some optimization will be added which would cause problems for references to uninitialized memory, but it seems more likely that the requirements on references will eventually be relaxed instead.

[1]: https://github.com/rust-lang/rust/issues/119241#issuecomment...

1. Yep, this is an abstraction HW works hard to preserve.

2.The specific scenario I had in mind was: write value X to address A from core 1, write value Y to A from core 2, read value from address A from core 1 (still X in core 1's cache), core 1 cache gets invalidated, read value from address A from core 1 again (now it fetches Y from memory).

See [1] for reference on how it applies to C specifically, especially "Absent any constraints on a multi-core system, … one thread can observe the values change in an order different from the order another thread wrote them".

[1]: https://en.cppreference.com/w/c/atomic/memory_order

In Rust, creating a reference to uninitialized data is undefined behavior, even if you don't access the data through it[1]. The optimizer assumes all references are intialized.

[1]: https://doc.rust-lang.org/std/ptr/#pointer-to-reference-conv...

The issue isn't writes to uninitialized memory, it's reads from uninitialzed memory. The compiler doesn't know how much of the buffer `read` writes. The docs say it returns a unsigned integer with how many bytes it wrote, so a programmer can know the later read from `buffer[0..num_bytes_written]` is valid, but the compiler doesn't know what the number returned from `read` represents, so from the compiler's point of view, the whole buffer needs to be initialized regardless of what read does for reads from it to be valid. That means it has to be initialized before it's passed to read, otherwise the compiler can't prove the elements which are later read from the buffer are initialized.

> That's correct at a hardware level.

Not even there, due to memory caches.

Okay, I think I see. In the linked article, due to the behavior of `read` uninitialized memory is never read. The same would be true in equivalent C code.

However, in C, the programmer doesn't need to prove to the compiler that uninitialized memory is never read, they are just expected to prevent it from happening. In this case, it's clear to the programer that there's no undefined behavior.

In Rust though, the compiler must be able to statically verify no undefined behavior can occur (except due to unsafe sections). It's not possible to statically verify this in either the Rust or C case, because not enough information is encoded into the type signature of `read`. The article discusses a couple of ways that information might be encoded so that Rust can be more like C, and discusses their trade-offs. C explicitly sidesteps this by placing the responsibility entirely on the programmer.

So to directly answer your question "Why can't Rust act like C when faced with empty buffers?", it's because the Rust compiler cannot yet statically verify there's no undefined behavior in this case, even though there is in fact no undefined behavior, and one of the primary design goals of Rust is to statically prevent undefined behavior.

And to what's perhaps the initial question, this is discussed using the term "safety" simply because Rust defines things which can't be statically verified to not invoke undefined behavior as "unsafe". Perhaps a better term would be "not yet statically provable as safe", but it's a bit of a mouthful.

You have some misconceptions about C and undefined behavior.

> C code that reads uninitialized data is presumed to be buggy, because it wouldn't be doing that unless it thought the memory was initialized. But the read itself is not unsafe.

The read itself is very much unsafe because it's undefined behavior. The compiler is allowed to assume the programmer doesn't allow reads to uninitialized memory to happen, so if the programmer does allow a read from uninitialized memory, any false conclusion can follow from the false assumption.

This is a problem even in trivial cases; see [1] and try commenting out and switching arround the calls to foo and bar. The behavior is very unintuitive, because reads from uninitialized memory is unsafe.

[1]: https://godbolt.org/z/71vbPYT6G

Actually, this is sometimes done exactly as you describe. See "AMD Anti-Lag" or "Nvidia Ultra Low Latency"/"Nvidia Reflex Low Latency".

> Still waiting for the Feynman Lectures on Mario Physics to drop :-).

Wait no longer: https://www.youtube.com/watch?v=mcI1kUvVMYM

To me, the bird mesh actually does look like marching cubes output. Note the abundance of almost square triangle pairs on the front and sides. Also note that marching cubes doesn't nescessarily create stairstep-like artifacts; it can generate a smooth looking mesh given signed distance field input by slightly adjusting the locations of vertices based on the relative magnitude of the field at the surrounding lattice points.

I find it sad that these sharks which naturally live so long, who have no recorded attacks on humans, and whose flesh is toxic to humans, are still killed and eaten by humans.

> Also, I’m not super happy about the extreme views on race, sex and religion that are going through the school system.

Maybe I'm living under a rock; what extreme views are going through the school system?

People usually slow down to run stop signs, but speed up to run red lights.

I can certainly see why many commenters here find this many dicks hard to swallow, but when I take them wholly with the rest of the work, I find they come together satisfyingly and rawly defile copyright and DRM.

I should keep this link handy for when people claim C is a simple language. Even without the GNU extensions, the examples here are pretty wretched.

Temple Grandin designed more efficient killing machines to streamline and reduce the costs of industrial scale slaughter.

> I am not planning to get a lawyer involved as I have faith that UW leadership will make it right in the end.

All evidence so far indicates they will not make it right, but instead they may make it even worse. Your faith is wildly misplaced. Seriously, talk to a lawyer.

Keep in mind, just because you seek advice from a lawyer doesn't mean you need to take legal action against the school. Talking to a lawyer is not an escalation; the school doesn't even need to know you consulted one. A lawyer will advise whether you should take legal action and any more amicable alternatives available before they do anything on your behalf.