hackrmn

This may be a dumb question, but can't one implement the "N data stacks" in C and thus basically get the principal feature of Goose while staying with C syntax and paying with verbosity?

Comprehensibility does not equal correctness or fitness. As if that wasn't enough, or perhaps in most related manner, an LLM/AI cannot be held responsible for what it produces, by nature, especially considering the fact that a _human_ claims all of it as their own work, or at least take responsibility. Meaning that when a parable of documentation is discovered to be bogus, you can't pin it on AI, you go to the human and ask them why the documentation is wrong, and it's not a good look.

Pretty cool to click the link and find it has been bookmarked for a decade on my end :-)

I am sorry but what does cache locality and CPU core access pattern(s) have to do with the video you linked? Indeed it shows a lot of instances in animation, but the only technicalities it mentions are bare mention of Vulkan (which I assume implies GPU), and I am using the CPU and without any libraries.

I started writing a [CPU-only] 3-D rendering library in C++ recently, after having written the equivalent in C as a proof-of-concept and an experiment. The reason I decided to write it in C++ after C, is not only because I wanted to tap into meta-programming which is facilitated much better with C++, or that I wanted niceties like procedure overloading, but because some things with C or C++ aren't automagically optimised -- like if you want to leverage struct-of-array (SoA) memory layouts because it allows fewer SIMD (AVX in my case) instructions in the rendering pipeline. You do _not_ get that "for free" just writing a single procedure in C++, much less with C. Both languages are layout-sensitive, I mean this is in part what gives you the speed -- optimising with memory layout for cache locality etc. But you have to do it yourself. Meaning that if you need array-of-struct (AoS) or in fact don't know which path the CPU would prefer, there's no other way than roll up your sleeves and one way or another implement both.

The kicker is, in my case I chose C++ because templates allow me to reuse most of the code in the rendering pipeline _regardless_ of whether I go for AoS or SoA layout. I leverage operator overloading to do vector by matrix multiplication which is implemented in both variants. I do have to specify the desired variant during building, but I've profiled and for Intel x86 AVX in my case SoA is something like twice as efficient because I process ("shade") 8 vertices with 4-5 instructions instead of 1 vertex at a time (still shaded with vectorisation -- just "rotated", i.e in the pipeline axis and not vertex buffer axis).

TL;DR; C++ gives you plenty fast by default, but it's not always enough. The difference between 5 and 15 frames per second, well, makes all the difference -- our eyes are only fooled once the frames-per-second rate goes sufficiently up, anything below an acceptable threshold and it's completely different experience. You then either sacrifice resolution or level of detail etc, or decide to squeeze more from the language by helping the compiler.

Your solution seems tangential to the problem brought evident here, with how ICANN and VeriSign are able between themselves, to turn 22,000 or so tangible name registrations into dust, without any retribution or refund. The funny thing is that DNS -- where these names actually reside -- is distributed, but it's not as federated as to prevent the kind of takeover. Worst case, a rogue state can declare their own root name servers with their own fork of all name records including 3LDs for `.name`, show the middle finger to the U.S. and call it a win -- except that real people in the U.S. or otherwise using DNS servers that don't hold the forked data -- will fail to connect to the services expected at those names as specified by the rogue state, and will instead connect somewhere else. Basically like two realities of links pointing different places in each universe. A multiverse of name resolution. Not great at all, except what if the rogue state is larger and thus more power-dominant than the U.S.? The U.S. can pretend they don't care, but they become ostracised through DNS, and that's not going to win favours with the users. In other words if 4 out of 5 people prefer x.y.z. points to my actually useful website except some scammy ad-ridden page, then whoever doesn't point x.y.z. to my website is going to lose users -- unless those behind the scammy x.y.z. alternative pledge to monetarily compensate for every disgruntled user.

Anyway, name resolution needs to be federated because ICANN is apparently compromised as far as doing the right thing goes. A single root model may not work anymore. Maybe blockchain can finally do some good...

And what lesson have you learned?

This points to a more general problem with some of the Internet infrastructure -- since real people don't actually own domain names, much less e-mail addresses (assuming they use e.g. @gmail.com), they're always at the mercy of a third party, which is normally tolerable except that with prevalence of user accounts at various Internet services, for any given person, tied to an e-mail that receives password reset instructions and what not, ultimately ownership of the service account is in the hands of whomever owns the e-mail. Although Google doesn't read your e-mail to order pizza on your behalf and bill, and even if your crypto-savvy brethren encrypt their communication to you, services you more or less depend on do _not_ send you e-mail that only _you_ can open -- regardless of the mail transfer or storage system (read: the e-mail is plaintext).

In light of this particular situation, I think a secret key shared between you and the service, at least, could guarantee that even in the event the e-mail address is stolen (or otherwise taken) from you, the service account remains in your hands.

I know I am not breaking new ground here, but I don't think the Internet is getting healthier for the human, it's at least going to get worse before it may get better. So maybe we need to adjust our assumptions and mitigate accordingly.

What are you referring to with "they released air tools"? I am not sure I am able to interpret your argument in any meaningful way.

I agree regarding metaphors, I myself aggressively utilise analogies with both myself and others, as a "digestive", but I feel like with LLMs we're treading on thin ice as it's not straightforward to classify a particular use case as one scaffolding learning with a metaphor, or just having the opposite effect where your brain "sails" in a faulty sea of "learning" while in reality there's no real work being done, not of the kind the brain needs to do in order to re-order all the synapses and own networks that ends being "knowledge" eventually.

There's been research done (I know, big words -- don't have any links readily available), where it was pointing to the fact that what goes easily in (into the brain) also goes easily out, and conversely, what the brain requires effort and literal calories and energy to understand, stays there longer (investment must be rewarded / recouped somehow).

So while there's no doubt that facilitating learning is a net-positive, at some point it becomes a net-positive, I suppose -- your brain just chucks it out faster because it knows you can re-obtain the same information again since it worked so easily the first time. It doesn't know the difference between easy and hard, all it knows is how much effort it takes and how much reward (hormones) was generated for it all (to cement the habit/result).

For my part, the make-or-break part of these kind of visualisations -- assisting home renovation, and interior and exterior design and architecture in general -- has been lighting and materials, not [only] or in any meaningful part 3-D through VR augmentation. I mean I would surely appreciate a fine piece of hardware like Vision Pro put to use here, so the author is on point, it's just that at some point you want to actually see the relative colorimetry at work -- how your beige couch is going to look in that spot illuminated by a giant window facing south etc. It's not as critical as making the house right, since moving a couch is easier by far, obviously, but there are things like kitchen islands that are more costly, featuring slabs of stone that is neither cheap nor easy to move.

Anyway, I've been using Radiance to help me deal with the above issues, but it's for all practical purposes non-interactive. At some point there's bound to be a e.g. Monte-Carlo physically-based ray-tracer for these use cases, featuring radiometry with visually negligible error compared to reference (i.e. if you were looking at the real thing with your eyeballs), that is _interactive_-capable (at least in the frames-per-second category and not seconds-per-frame). It's probably already out there, but people have different preferences as to the tools they wish to employ. I like Radiance because it's text mode and gives you a lot of quality for all the text editing and tool composition (which frankly is a bit weird, Greg Ward was sure a maverick!), but mileage varies there.

This is the MVP comment.

When you have a carpenter visiting you don't announce they can go into your kids' rooms (for reasons unrelated to the job is) and what not -- the [default] contract is they're there to do a job and their privileges go only as far as the job requires, they normally also ask you first time where your toilet is, although we all agree they can use it. It's a contract, formally and less so, and things work when the contract is abided by. The carpenter also can't say they had the right to the cookie jar on your kitchen counter just because they were working there.

By not implementing such a contract with code, Microsoft has shown negligence. And they have had _decades_, so it's likely a "business decision".

I don't know, I was very happy when I discovered what Radiance can do with what you give it. I hear people get very good looking rendering with Blender, but my brain doesn't work like that (anymore?). Point being that not everything is about games and looking good, we need reliable tools to render synthetic scenes to assess a lot of non-game related things, like quality of lighting in architecture before erecting a skyscraper or buying a house etc. To that end, every bit of knowledge like the author seems be focused on, helps. I absolutely relate to the problem with "faking" things. Even developers of Unreal engine had acknowledged -- all too late, as it is -- that it's _light_ that most affects our perception of "realism". That and materials, which is why they had some sort of field trip to Iceland taking raw photos of rocks they could add to their materials library.

Another problem with looking good is that it's a) subjective (since it has no real or objective reference point, really) and b) it quickly goes stale once something else looks "better". Just look at Doom. It looked good in 1993, everyone would agree on that. It's not realistic, never was realistic and will certainly never be realistic unless you take a particular cocktail of drugs, I guess.