NohatCoder

It is hard to understand what this article actually advocates. All the images have the filters aligned with the input pixels, with no grid of output pixels overlaid, as one would need to actually scale or rotate the image. It seems like the article actually suggests that we should use a filter in order to display an unscaled image on screen, even adding a border of filter garbage from outside the confines of the original image.

We are told that the square filter depicted is bad, no actual reason is given.

If we actually add in some scaling and rotation then it is really bad, but then again if we scale it down really far, then so are all the other filters, horrible aliasing all the way round.

Conceptually a filter operation can be thought of as two steps, first we apply an input filter to produce an intermediate infinite resolution version of the input image, then for each output pixel we use an output filter to sample the intermediate version and produce a simple colour value. In practice of course there is no intermediate image, the input and output filters are combined to a single formula that deals with a finite amount of data.

The reason that this model is not often mentioned is that the output filter is commonly just sampling a single point, thus the combined filter and the input filter becomes the same thing. This is often a very poor choice, leading to uneven sampling distribution and the aforementioned aliasing. It is possible to mostly avoid these issues by picking the exact properties of the input filter to match the desired level of scaling, but that is not something I have generally seen applied outside of one specific context.

That context is trilinear filtering used in 3D graphics. This input filter produce an intermediate that is exactly as blurry as it needs to be to avoid the aliasing that results from heavy downscaling. It is still visibly not perfect, and therefore we also use an output filter called an anisotropic filter. Rather that a single point sample it picks multiple point samples in a circle, typically 16. I think there is an argument to be made that an integral over the pixel-shaped square would produce slightly better results. But an exact integral is really expensive to compute, and the circle complements the trilinear filtering better than a 4x4 grid of samples, leading to a more even sampling of the input in cases where a texture is viewed at a sharp angle.

So modern filtering in 3D games don't use any of the fancy filters you see in papers like this. Not because a modern video card couldn't, but because they don't solve the problems video games care about, like aliasing.

For offline filters, like the ones you would apply in an image processing program, I do think squares have some merit. But we have to think of it as two filter steps. One approach would be to simply render each input pixel as a square in the intermediate image, and then for each output pixel sample a square from this image. The input and the output squares are possibly a different size, and oriented differently, but with a bit of maths we can still compute the exact result in finite time. The resulting image is decent, with each input pixel contributing the same amount to the output image, but the blurriness is possibly uneven, which in some cases can look jarring.

An alternative is to use a bilinear input filter, while retaining sampling a square for the output. This is a bit blurrier, but the blur is much more even.

Okay, but what if we use a circular output filter? Or also use bilinear for output, throw in some bicubic, or sinc or some other thing? The real world result is that you are now staring at a bunch of similar images trying to deduce which one looks best, and they are all kind of the same. The only markable difference is that some of them are a bit blurrier, and the others artefact a bit more, and ultimately that tradeoff is the main concern when choosing filters.

Meanwhile us Vanilla.js'ers are still wondering exactly what a front-end framework does for a site that displays some text and some images.

It seems like the framework culture is driven by the search for a silver bullet that makes problems go away. But each solution to a problem always comes with its own set of problems, only these problems are initially unknown. So you trade a set of known problems for a set of unknown ones.

It is possible that these new problems are lesser problems, but this is hard to verify upfront, and the nature of being unknown makes it a lot harder to deal with them preemptively.

So anyway, you have your framework, you have used it for a while, and you have learned about the previously unknown problems that it causes. You could rejoice that you now have this knowledge, and therefore have a reasonable shot at working around the problems. But instead you ditch your imperfect framework and search for a new one, beginning the cycle anew.

I think it is important to understand what makes a style actually different and what is just semantics.

For instance, if you write a function to do some operation on an object, you could have written that as a method instead. But ultimately it is the same code, it is unlikely that the difference matters much for either performance or readability.

However if you need to do some operation on a bunch of objects you could pack each operation on the individual objects in a method, and call those methods from a main function. Or you could just put it all in one function, with as many nested loops and if statements as there needs to be. Now the difference is real, you pay in performance for a lot of function calls, and following the control flow is different.

Personally I tend to prefer the one function, but sometimes part of it makes sense as its own function, in particular when I can avoid duplication that way.

There is no silver bullet, but best of luck, changing one's style can be hard.

Depends on what you compare, but with modern cryptography instructions you can now generate a few bytes per cycle, so billions of numbers is not an issue.

Fair. To be clear the issue remains no matter the choice of these parameters.

At least bilinear and bicubic have a widely agreed upon specific definition. The poor results are the result of that definition. They work reasonably for upscaling, but downscaling more than a trivial amount causes them to weigh a few input pixels highly and outright ignore most of the rest.

The API/ABI structure of every modern OS is a hot mess, that has nothing to do with syscalls not being files, and everything to do with the way the systems have been extended over and over again for decades.

Making a simpler API is a great idea, and from you comment I guess they mostly succeeded, but they did not have to go down the everything-is-a-file path to do that.

What role this played in lack of adoption depends on what alternate course of action you compare it to. A non-file-based rewrite of the API would likely have had approximately the same result, in any case a good compatibility layer might have made a big difference.

Nice guide, but one thing that seems slightly off: All the cubes don't look exactly cube shaped, they need to be slightly taller to look perfectly cube. If for instance a cube is 2x16 px wide, then the height at the side should be approximately 18 px.

No, not everyone sane. Rather everyone sane who has been bitten enough by these issues to use such rules. Everyone starts out at -O2, because understanding all the other flags and their implications is super difficult. As long as the insane setting is default, a large percentage of programmers will be using the insane setting. Arguing that they should have flagged their compilations otherwise is about as useful as pointing out that people shouldn't write UB in the first place.

I'm fairly confident in declaring the answer to your question: None.

Most programs rarely issue all the instructions that a CPU can handle simultaneously, they are stuck waiting on memory or linear dependencies. An extra compile-out-able conditional typically doesn't touch memory and is off the linear dependency path, which makes it virtually free.

So the actual real-world overhead ends up at less than 1%, but in most cases something that is indistinguishable from 0.

If you care that much about 1% you are probably already writing the most performance critical parts in Assembly anyway.

Pretty much all the numbers can be explained as being the closest number to the geometric mean of the previous and following number. Once you have chosen to round the second number in E3 to 22, 47 is the closest to splitting 22 and 100 evenly. The exception is 33 in the E6 series, that should be 32 when splitting 22 and 47, most of the other "errors" in E12 and E24 are there because 33 pushes the other numbers upwards.

The really easy observation to make is that crypto.com is operating at a massive deficit.

Their advertising budget is absurdly large, and then they pay some hefty interests to their customers.

Is there any part of the business that actually make money for them? Because it seems like all they do is loan more money to keep the Ponzi scheme going.

As best I can tell it is all one big boys' club. The network of CEOs who sit on one another's boards, are personal friends etc. is a pretty well connected graph.

When they hire, fire, negotiate wages and so forth a primary concern is exchanging favours. Why would a board member say no to granting a $100M payment package when it is a step on the way to getting a similar deal themselves some day?

Depending on exact specifications that is like $10k of hardware, so 4 days of rent pays the machine in full.

So in this service the actual cost of the hardware is a rounding error. It also needs power, cooling, a roof and some maintenance crew, but that still doesn't come close to the rental price. So what are customers actually paying for?

The weird thing is, the nature of their business does not imply any significant computing needs. As a rough estimate they have served on the order of 1 billion customers, so that suggest they need 1 billion, multiplied by some factor of cruft, database rows. Depending on the cruft factor that should be somewhere between easily fitting on a single disk, up to a few of them. Add in redundancy and backup and we have still not filled a rack cabinet.

Maybe all those computers are doing something that someone thought was important, but it is not serving the core business.

Scientific publishing has largely gone off the rails, thanks in no small part to the frequentist p-value obsession. It is not good enough, people just use it anyway.

I think most people want to avoid the dance of picking a prior, that is why frequentism is still so widespread.

XSLT is just an inferior programming language.

XSD mostly served to make people believe that XML standards could, as the name suggests, be extended. If you just specify your extension XSD it will work, right?

In the real world it turns out that an extended XML standard is just another standard, it may look a bit like the old one, but nothing is going to save you from writing new logic if you want to support the new standard.

While there are surely a few oddballs out there who just want to make standards for the sake it, to most of us, JSON doesn't need any "features", it makes parsing and generating data blobs quick and easy, that is all it needs to do.

The problem is that UML was forced upon a lot of people who basically didn't need it. At some point simply saying "Meh, it is not for me" doesn't cut it, you have to actually fight back to prevent the brain rot that the marketing is causing.

If university students are being taught that UML is a must-use tool, it doesn't really matter whether or not UML has some legitimate use cases, the base teaching is a big fat lie and the students would have been better off spending that time playing Candy Crush.

If MS have found a compromise they should share it. Making the allegation but not disclosing any reason is just slander.

Where do you save transistors? With the Posit you have to be able to deal with larger mantissa, multiplier size scales with mantissa bits squared, so even a small increase makes quite a mark.

Maybe you save a bit by not having denormals, but then parsing the packed float is a bit more complicated in that the bits do not have a fixed division between exponent and mantissa.

It is possible that the Posit circuit was smaller by leaving out some feature, like exact rounding, which is quite expensive, but then it is not an apples-to-apples comparison.

That is fundamentally the same for Posits. If you want constant quantization you should use fixed point, or you could switch your inputs to be +1/-1 for symmetry in this specific case, but I doubt that this is much of a practical issue.

That may be true, but you don't need a fundamentally different number representation in order to throw away most of it. Also, the die size cost is quite small.

The biggest saving you could make is probably foregoing exactly rounded results, and only stipulate that the result has to be within ±1 lsb of the true value. That would save multipliers from computing a bunch of bits that don't end up in the result anyway, except for the rare case where they decide the rounding. That would probably be a good trade-off for most AI chips. For general purpose CPUs I don't think it is worth the breakage.

Addition in logarithmic space is expensive, we don't have any neat ways of doing it. Options include:

* Converting back and forth to linear space, using exp and log functions, this is much slower than a regular multiplication.

* Evaluating a polynomial that approximates the logarithmic space add, this takes several multiplications, so also much slower.

In general we tend to use more additions than multiplications, so trading addition speed for multiplication speed is rarely a good idea, even 1 for 1. If we need a lot of exponentiation keeping some values in logarithmic space may be beneficial, but it has to be those rare cases only.

I think Gustafson may be the kind of liar that doesn't know he is lying. He knows saying that his design improves upon power and die size sounds good, so he says it.

Gustafson is a noob. Both his Unum I and II proposals are completely impractical, making absolutely no consideration for how hardware would implement his ideas. But by writing only about the imagined merits he managed to convince a lot of people that his ideas were great.

Unum III/Posits can work, but mainly it is just a number compression format. Working with say 64 bit Posits pretty much requires implementing arithmetic equivalent to that of 80 bit IEEE floats, and then throwing away a larger or smaller portion of the mantissa depending on the exponent. And the extra accuracy around the sweet spot of 1 still comes at the cost of lost accuracy for large and small numbers, so some workloads will suffer.

What really bothers me is that mathematicians seemingly never distinguish between doing and presenting mathematics.

You can do your own scribbles with single letters, so do I, it works fine.

But when you present maths in a scientific article, maths book, Wikipedia article or similar, your convenience as a writer should be secondary. Your task is to present information to someone who does not already know the subject. Presenting an equation as six different Greek letters mashed together means that the equation itself convey almost no information. You need a wall of text to make sense of it anyway.

Really it is a lot more about how much stuff you load than how you do it. CSR can at times provide savings, for instance by doing fake page changes and not having to load menus and stuff when the content changes. But of course you have to keep the JS light in order to not eat the savings.

You have to be careful with the lazy loading, sometimes it ends up being just more round trips. And then there are those annoying sites that refuse to load anything that is off screen, and you end up having to wait over and over again.

I'd put it like this, sometimes the framework culture does a lot more damage than the framework itself.

Actually no, the point is if you don't put in anything that potentially makes the website slow you can be reasonably certain that it isn't. Obviously you still want to test the website, but it is not like this path is particularly test demanding.