Chabsff

FOSS is not the same thing as "everything digital should be free". They are not the same people/movements, though I will admit that there is some overlap.

It's absolutely true that a vast majority of crypto projects revolve around the idea of artificial scarcity, leading to a disgusting commodification of absolutely everything. However, and ironically enough, code is the one thing that crypto cannot commodify, which is what FOSS cares about.

You can only cool something by making something else warmer by a larger amount. The heat has to go somewhere, and moving that heat in any non-passive way will invariably produce yet more heat in the process.

Kinda? Taking the experiment outside of earth`s (and the sun`s, I guess) gravity well would have the effect you have in mind. But the impact would not be particularly pronounced considering the magnitude of the curvatures we are experiencing.

They sure do have one: https://peering.google.com/#/infrastructure

That's not necessarily true. SSL/TLS does not prevent all MITM, it prevents unwanted MITM.

To be fair, I don't think you can install certificates on a Chromecast for example, so it might not be practically feasible for all devices, but a blanket "SSL makes that impossible" is not correct.

My apologies. I thought you were providing an explanation as to why slerp() is preferred in general. The circle example is a really good way to frame the distinction.

Still mostly relevant to their use as encoding for transformations, but the fact that a unit quaternion's conjugate is also its inverse is extremely useful from a computational performance point of view.

10-12 years ago, the consensus used to be that this singularity simply does not show up in the wild in the vast majority of scenarios, and the performance hit of using `slerp()` is just not worth it unless truly needed.

It was essentially the same reasoning as for using `-ffast-math`. Yeah it's not "correct", but users can't tell the difference and it has a measurable performance benefit.

To be clear, I'm not questioning using slerp() at all, it definitely has a role to play. I'm just wondering about using it by default as implied by the post.

The two aspects that slerp() addresses over lerp() + normalize() are 1) it can deal with pole-to-pole interpolation 2) It always takes the shortest path.

In practice, the former is often provably never going to happen, and the later doesn't actually matter from a qualitative standpoint: Quaternion interpolation will always look a bit weird over large angles, especially if there's a roll component to one of the orientations.

As far as having a constant interpolation speed: again, this is rarely perceptible, and truly linear transitions from one orientation to another looks janky so some amount of filtering happens anyways (an ease-in-ease-out for example).

But yeah, for very large interpolations, it can create a slight authoring/runtime skew. My rule of thumb used to be: use slerp() when the orientations can be at least 120 degrees apart, or when lerp() yields weird results. However, it's really rare to be interpolating over such a large orientation change, you almost always have a few keyframes or dead-reckoning syncs in between.

Again: This might be an outdated perspective though.

I've been out of the games sphere for a long time, but is slerp() really the default idiomatic interpolation approach in modern games nowadays?

There are a vanishingly small number of scenarios where lerp() + normalize() doesn't work perfectly well enough and it is drastically faster and SIMD-friendly. That used to be the case at least.

According to the article, it's not the products that are being shutdown, just the centralized organization structure around them. It's safe the expect that at least some of the projects will be terminated as well, but for the most part, it seems like this is just a removal of a (presumably redundant) layer of management.

TURN/STUN servers are not always used, and more often than not only as a fallback if a direct link is not established.

It's hard to tell for sure. Double-buffering game updates like that can involve a lot of memory copying. Considering that it would not surprise me in the least if Factorio was close to being bottlenecked by memory bandwidth, this could easily be counterproductive.

Obviously, there will eventually be a security policy. The libraries are just too early in development for that yet.

Hello HN,

I've been toying away at writing a user-friendly markdown-ish format that lets users to define their own marks and format rules. It's pretty stable at this point, and I'd love to get feedback and ideas before I push it any further.

Thanks!

Ideally, the lexer should be a system in of itself, exposing a public interface that is consumed by its client, the parser.

Public doesn't necessarily mean "not you".

Well, ideally yes, but let's be honest here. If we can't trust websites to not abuse data, how can we possibly trust them to respect a polite request not to gather the data in the first place? I would personally rather have an incognito mode feature that I have confidence performs the task it claims to do without alerting the website, than one that loudly announces its presence, on the hope that it might be respected.

I don't trust Google, but I certainly don't want Google to trust random websites on my behalf.

You are asking that browsers announce to websites that the user has incognito mode enabled, which immediately opens the door to websites refusing to serve users running incognito mode at all.

I think the debatable point here is that the lawsuit implies that the problem is that Google is not integrating analytics and Chrome enough. Analytics works in a certain way, and chrome works in another. The expectation that because both products belong to Google, they should treat each other in a special manner (i.e. Site-side Analytics should be behaving differently when encountering a chrome browser) is pretty iffy.

Right, I meant "prolog-style formal inference engine". My point is that this "human imperfection" also present in probabilistic engines have artifacts that are fundamentally at odds with many business requirements where we are attempting to shoehorn then.

It's almost more of a cultural issue than a technical one. The level of explainability currently desired from automated systems is possibly not achievable, simply because we want to uphold them to a different standard.

I think it's actually the complete opposite. The current biomimetism direction being privileged by the modern A.I. trends is most likely the correct way to achieve "True" A.I.

However, Inference-based A.I. is actually needed to properly tackle many of the business problems that are being thrown at ML systems today. Explainability and bias reduction can probably only be be taken so far with the current approaches, and I suspect that this "so far" is not far enough for many tasks. It's definitely the case from a practical standpoint today.

So inference-based A.I. is due for a comeback indeed, but I'd say AGI is looking like one of the main areas where the current techniques might work.

The rule needs to be deterministic accross compilers, since a library can be compiled using a compiler and linked in an executable using the same header.