Gravitational field. There’s no way you could achieve this with the magnetic field.

fn enable(&self, enabled: bool) {
    self.enabled = enabled;
}

“State” can mean too many things. Just have one function “enable”. And if your language allows default parameter values, set to true by default

So your use case for LLMs is the first aspect of them that will be enshittified.

LLMs advocating for products that pay them is step 1 of incoming enshittification.

Also, anyone that has ever talked to customer service of any kind knows that the “automated” stuff is the absolute worst and you want a human most of the time.

SO was in decline before AI. AI just accelerated the process. The shit moderation is what took it down.

If you read the conclusion, it is very clear that you should not ever break convention. You should not apply this if it would affect any other program.

That is, if your input is in u8, your output should be in u8 too. Otherwise you are “exposing” your different quantization.

I don’t think this post is telling you that you should use the 256 method. I think it is pretty clear that it is just explaining it, not advocating for it. At various points of the article it is written something like “I struggle to see a situation where it would be beneficial”.

The offset is needed because this quantization dividing by 256 uses truncation whereas by 255 uses rounding.

So a value of 245 (for example) could be anything between 245.00000 and 245.99999. Therefore, when dequantizing, we set the value to 245.5, which is in the middle. Between 245.00000 and 245.99999.

Did you read the article or just the title?

I’m honestly surprised this comment is the one that shows at the top.

The random number generation is not the source of the complaint. That is just made to easily prove the point in the article.

The argument is not to use another method when randomly sampling from [0,1). The argument is that f32 color channels are already in the [0,1) range, and following the alternate method results in a “fair-er” representation of the range.

The plot that was generated with the random sampling is just to show that the standard method is not “fair”.

The correct way to scale a number from one range to another is …

Citation needed.

It is just as valid to quantize the following way:

q = (x+0.5)/256

The inverse would be:

x = min(truncate((q*256)), 255)

In fact, you could argue that this method is technically more correct. The only issue being the exact value of 1.0, which we have to handle explicitly with min(..., 255).

This method is idempotent. Try it with x=90 for example. It does destroy data, but that is true for all quantization methods.

We have to remember that quantization is the process of representing a bigger set of numbers (usually infinite) with a smaller one. We sort a range of values from the bigger set into a single bin in the smaller set.

The argument of the article is not about “resolution”. The argument is about using the 8bits available as efficiently as possible.

As the article points out, if you follow the naive approach of:

q = x/255

x = round(q * 255)

You are losing a tiny bit of the 8bit range. Since the ranges represented by 0 and 255 are half as big as the other ones. The naive approach is really quantizing in the range of [0-0.5/255, 1+0.5/255) instead of [0,1). This is because round() maps approaching values to x from both sides, so some negative values map to 0, but there are no negative values in our set.

The conclusion at the end of the article is mostly the correct one though. If there is an industry standard, it is best to follow that standard. Since mixing a quantization function from one method with the dequantization function from another is just wrong. You can only choose your own method if both your input and your output is the small range.

EDIT:

The “naive” approach described in the article does x = truncate(q * 255 + 0.5) which is equivalent to the x = round(q*255)

Checks out with my experience in university. I had like 3-4 classmates in software engineering that could program a simple program that ran. And this was before LLMs. You don’t even need to cheat to pass while being absolutely incompetent. Of course, some people also cheated.

California, home to the most evil and powerful companies in the world. Lmao.

TL;DR:

Domain Driven Design has a flaw: not all types can be categorized into “valid” and “invalid”, since it often depends on context.

Solution: you just haven’t modeled your domain correctly. You have a type for “MyData” but you don’t have a type for “MyDataThatIsBeingEditedByTheUser”.

So the “final” type should be valid, but often you should have intermediate type(s) that model incomplete input.

Basically, when doing DDD don’t forget your builder types.

I don’t see how LLVM helps with bootstrapping.

Yes, it helps with supporting newer platforms, since LLVM is a big project and will probably have support for the new platforms relatively fast.

But as long as any part of the whole process is in rust, it means that you need a rust compiler to build the rust compiler, thus needing to solve the bootstrapping problem.

Of course, every compiler has this issue (even if not self-hosted, you still have to bootstrap the compiler of the language your language is written in).

The only solution for this is to have a compiler-chain where the first level is a simple compiler that can be relatively easily written in the assembly language of the new platform.

EDIT: or of course I could’ve read any other comment. Of course you can use one of the intermediate representations that are portable to build the first compiler. In which case you don’t need a rust compiler, just need LLVM. Makes sense then.

There are many C++ features that make the language worse. Exceptions is one of them. It’s not strange to have them banned.

Critical systems often only allow you to use a subset of the language. Dynamic (heap) allocations, recursive functions, exceptions are features that are often banned. In medical devices, safety is critical, so it makes sense. Otherwise you could get a Therac-like scenario due to an unhandled exception.

Chromium based ones are at the mercy of Google. Firefox, however, is independent in that sense.

When google decides to drop support for manifest V2 (which is the one unlock origin uses), every chromium browser drops support for it. Unless they make a fork of chromium and add manifest V2 back in. Which means extra effort every time they want to update with upstream, since there probably will be merge conflicts.

Firefox can just not drop support for it, literally 0 effort.

Thank God AI is so powerful that we would live in a post-scarcity world! AI is so productive that labor is basically free. Thus making products basically free.

Go to crates.io, search for whatever you need. Most probably it will be multiplatform.

There are plenty of cross-platform libraries in rust. In fact, most of them are. Since Rust is cross-platform at its core.

“plugins” is not a feature. What plugin specifically do you need? Most probably you can accomplish whatever you need with a library and iced. Plugin is just a fancy word for library.

Yeah. That’s a huge issue rust has. However, it can’t be solved with Rc.

You either do it in safe rust, by “cheating” the borrow checker and storing a size offset of the buffer instead of a reference. Or just use unsafe rust and store a raw pointer alongside the buffer.