peter_d_sherman

https://www.reddit.com/r/learnmath/comments/av8w5v/help_me_u...

>"Basically we can see every function in R^n as the level surface of some higher dimensional function in R^n+1"

[...]

>"A level surface is just some constant value of any function."

Also related:

https://en.wikipedia.org/wiki/Jacobian_matrix_and_determinan...

o PCIe 6 attached card for PC's (Or, optional CXL 3.2 x8 device/connection)

o Part CXL Memory Expansion Device (up to 2TB DDR5 onboard)

o 3072 onboard RISC-V cores

o Cache Hierarchy onboard (L1, L2, L3, etc.)

o >"MX1’s programming model has parallels to OpenCL or CUDA" (= ability to write custom mathematical Kernels, etc., etc.)

o >"XCENA takes advantage of RISC-V’s extensibility to implement a custom Vector Processing Engine (VPE) at the subsystem level. Each RISC-V core gets a VPE command queue, and can ask the VPE to accelerate a variety of vector operations. Likely, XCENA uses special instructions to enqueue messages into VPE command queues, and expects code to treat it as a giant shared coprocessor. The VPE supports FP32 and FP16, and provides ~3 TFLOPS of dot product throughput across the chip."

(Repeated Vector Operations is what's necessary to implement Matrix Multiply (matmul), which is what's needed for AI training and inferencing to work.)

>"For perspective, an Nvidia GeForce GTX 1080 with similar onboard memory bandwidth has 8.8 TFLOPS of FP32 compute, compared to the 3 TFLOPS available from the MX1"

(Today's TFLOPS on an MX1 may be slow, but the orchestration, the integration of all of these components on a single device is what's important, because it creates a broader template pattern for future such devices originating not just from Samsung and/or XCENA -- but from the computer industry as a whole. Much like the original IBM PC architecture did for the PC industry, that was to follow...)

o >"MX1 can host SSDs, which are presented to the host as CXL memory. [...] However, SSDs have high latency compared to DRAM. MX1 can mitigate that latency by using its attached DDR5 to cache SSD contents. Caching works with 64 KB pages, with an on-chip 1024 entry map cache. The map cache acts like a TLB, and tracks DRAM pages mapped to SSD-backed addresses. If an access misses in the map cache, it causes a page fault that’s handled by firmware running on the MX1’s RISC-V cores. Firmware handles the cache miss by fetching data from the SSD and updating the mapping."

Observation: This is basically a hardware implementation of virtual memory / paging / swapping, that most OS's currently do, but if this trend continues, then OS's may not need to do this in the future... it'll be interesting to see where this goes...

Oh, last thing... would love to see RISC-V cores replaced, in whole or in part, with an FPGA or multiple FPGA's... Don't get me wrong, I love RISC-V over all other non-open, closed hardware ISA's, but I love FPGA's (since the user can define their own functionality) even more... ideally FPGA's with open toolchains...

Or maybe Samsung/XCENA could make several models of this... one with the RISC-V cores, another with an FPGA or FPGA's...

So to recap, from a "future technology" perspective, I like this architecture a lot!

(Also, technology-wise, this reminds me of Transputer from the 1980's, a device which despite its lack of commercial success was so ahead of its time that it's the stuff of legends among the tech-savvy: https://en.wikipedia.org/wiki/Transputer)

F=Φ∘ρ∘π

representative-level enumeration is mathematically unnecessary: the objective is constant on quotient classes and may be evaluated entirely from the reduced carrier."

So basically, you're creating a Rainbow Hash for Mathematical Objects!

Brilliant idea!

AKA a "Lookup Table", aka a "Database" -- for the properties of Mathematical Objects!

Now, I think this could be worth future research... if we have say, a database of mathematical equations, then my question is, "How many distinct Mathematical properties could be their own attribute, aka their own database table "field" -- for each record?"

The above references such mathematical properties as "class-indexed fold invariants, polynomial layers, Cantor complexity coordinates, determinantal degeneracy data, algebraic certificates, Thom encodings", etc.

But, in the world of pure Math (as opposed to merely cryptography), how many additional properties could be added as Database Fields (or Key/Values, if you prefer KV stores) to each Record?

Which would be dependent on others?

Could such a Database, were it to be created, or attempted to be created, be normalized?

And other questions!

Point is, there's a lot of weird-but-interesting (in a good way!) pure Math ideas here, above and beyond the cryptography aspects!

When I said:

"(more specifically the linear equations of curves with N control points aka "binding points" / "points of stability" / "fixed points" / "immovable points", etc.)" -- there's a terminology mix-up here -- the control points (A, B, C, D) are (obviously) variable / flexible in nature, but the values from Pascal's Triangle are (obviously!) bound/stable/fixed to their respective row!

So that's what I meant to say...

So my apologies for having messed-up the terminology there!

(You know what I meant! :-) )

Anyway, some very interesting responses and connections! Thanks to everyone who responded!

The Magic-Eye Tuning Indicator, W G Morley, The Radio Constructor, March & April, 1969:

https://www.r-type.org/articles/art-137.htm

Read my profile: https://news.ycombinator.com/user?id=peter_d_sherman

On there, you will find the following quote:

"The true knowledge consists of knowing that one knows nothing..."

- Socrates

See, I'm agreeing with you(!), at least on that part of your message, at least on that comment!

You see, I truly don't know...

And, I don't truly know what the future as-of-yet holds...

I suggest and submit to you that this is the foundation of intellectual humility, which is the starting point of all forms of inquiry which have the potential to lead to genuine knowledge, at least in the specific areas of inquiry, and at least for specific amounts of time ("the only constant is change", aka, many forms of specific knowledge, if acquired, are time bounded, bounded in time -- but I digress!)

>"The problem with your rambling and speculation..."

My inquiry into the nature of this phenomena, but sure, your (perceived!) "rambling and speculation" on my part (I'm chuckling to myself, because that's rather funny from my perspective(!) -- yours is the first message on HN that has truly made me laugh!)

>is that you're not making any attempt to think about what conditions would be necessary for a technology to succeed in the market and gain widespread adoption across many market segments. I stand by my assertion that it is impossible for compute-in-memory chips to entirely replace commodity DRAM, especially in any market segment where the compute portion of those memory chips is not critically valuable. Any remotely plausible, useful compute-in-memory design will have significantly lower capacity and higher cost than pure commodity DRAM; this is not a low-overhead added feature. Any market segment where the compute capabilities of compute-in-memory were so marginally valuable that a non-trivial number of the customers wanted to disable the compute is a market segment where everybody would still be buying mostly ordinary DRAM.

I see...

So the premise of your argument is The Market (specifically the future consumer commodity DRAM market)... correct?

That is, Modern CPU's (as opposed to truly ancient ones, around 50 or more years ago) implement caches -- regions of gates/circuits/transistors or mostly transistors -- which implement the equivalent of RAM.

When a silicon wafer specifically destined to become a stick of consumer RAM is etched, most of its space is etched in a gate/circuit/transistor (or mostly transistor!) pattern that implements RAM.

There may be other timing/coordination/refresh etc. circuits etched on the region of the silicon wafer which is to become the RAM, but those are usually a small portion of the space.

But, fundamentally CPU's and RAM -- are created from the same substrate, transistors and other very small electronic components etched into a silicon wafer, although these days due to manufacturing constraints and cost issues, RAM usually uses a larger process node, a larger (less expensive, older) size, i.e., the latest CPU might use 2nm process, and consumer RAM might use 10nm or 12nm process.

But, fundamentally, at the lowest level, both RAM and CPU are mostly transistors and other minature electronic components.

So, if they're both the same at that level (ignoring process node size), then my engineering question to you is as follows:

Why exactly can a CPU contain RAM electronic circuitry, but RAM can't contain CPU electronic circuitry, if both, at the lowest level, the level of the minaturized transistor, the minaturized electronic circuit, are created from the same substrate, the same basic building blocks?

>You seem to think that "compute in memory" would mean the disappearance of commodity DRAM parts and their replacement with parts that had compute capabilities.

You seem to imply that I think that, but I am merely speculating on possible futures, possible outcomes...

>This is impossible.

That might be speculation on your part...

>Nobody is going to be putting compute in memory chips onto standard consumer DIMMs.

That also might be speculation on your part...

Seymour Cray was heralded as a genius back in time in computer history, because he put memory physically closer to the CPU. Since his time, compute and memory have been getting closer and closer together, in various forms, including, but not limited to CPU caches, or say, 64GB HBM on Intel Xeon Max 9480... Cerebras, for example, mixes as much memory and compute as they can, on the same wafer...

But historically, memory and compute have been getting closer and closer together... that's because higher performance (which is the goal, the continual holy grail of the computing industry) typically requires less space, less latency, less delay, between the two...

Is putting a CPU or other processing unit/computing device/computing circuitry into a stick of DRAM a good idea?

Well, that I don't know, but the industry, always in search of better performance, might head that way, in whole or in part, in the future... we don't as-of-yet-know...

γ(t)=A⋅(1−t)^3+B⋅3(1−t)^2⋅t+C⋅3(1−t)t^2+D⋅t^3

The rule is simple: descending powers of (1−t), ascending powers of t, with coefficients taken from the n'th row of Pascal's triangle.

I've never seen the connection between the equation for Bezier Curves (more specifically the linear equations of curves with N control points aka "binding points" / "points of stability" / "fixed points" / "immovable points", etc.) and Pascal's Triangle before!

Brilliant!

Great article, too!

[...]

>"WAFT is similar to RAFT but replaces cost volume with high-resolution warping, achieving better accuracy with lower memory cost."

[...]

>"Compared with existing methods, WAFT ranks 1st on Spring, Sintel, and KITTI benchmarks, achieves the best zero-shot generalization on KITTI, while being

1.3 − 4.1× faster than existing methods

that have competitive accuracy (e.g., 1.3× than Flowformer++, 4.1× than CCMR+)."

Generate lightweight previews in 360p resolution up to 60% faster

and at a third of the cost compared to Omni 1.1’s standard 720p resolution. This is helpful for rapid prototyping, storyboard iteration, and quick rendering in developer platforms."

This is a great idea, to have a low-resolution mode for additional speed to create previews, do test runs, create rapid prototypes, etc.

My curiousity is, what's the absolute useable minimum that this could be?

That is, would/could 240p resolution work? If so, what about 144p? How about lower? Then, could those images be upscaled quickly (and is the result still usable?) with a faster image upscaling-only neural network?

The reason why knowing such lower numbers / lower bounds -- is because they could be important for additional cost/time savings and/or running derived LLM's on local resource-constrained hardware...

Anyway, great post, great idea, and we welcome Gemnini Omni 1.1 Flash to the ever-expanding list of LLM/AI's!

-The Who, "Won't Get Fooled Again"

:-)

(https://en.wikipedia.org/wiki/Won%27t_Get_Fooled_Again)

Related:

"SIMDRAM: A Framework for Bit-Serial SIMD Processing Using DRAM Extended Abstract" (2020):

https://arxiv.org/html/2012.11890v1

>"We leverage the SIMDRAM framework to accelerate seven application kernels from machine learning, databases, and image processing (VGG-13 [63], VGG-16 [63], LeNET [38], kNN [42], TPC-H [66], BitWeaving [45], Brightness [28]). SIMDRAM provides up to 2.5× speedup for the kernels compared to Ambit [58]. Compared to a CPU and a high-end GPU, SIMDRAM is 257× and 31× more energy efficient, while providing 93 × and 6× higher throughput, respectively."

I was particularly impressed by the following:

>"A built-in lightweight HTML view widget renders documentation-style markup with cascading styles."

Basically you built a miniature, integrated, embedded, open-source web browser which can parse CSS and render to SDL... very impressive!:

https://github.com/ovenpasta/adi2/blob/master/src/adi-widget...

https://github.com/ovenpasta/adi2/blob/master/src/adi-widget...

Also, it should be possible to easily, easily port this source code to Delphi and/or FreePascal and/or Graeme Geldenhuys' "Blaise" language (A modern, self-hosting Object Pascal compiler, https://github.com/graemeg/blaise) should anyone in those respective communities decide to do that...

Also, if Ada had an {$IFDEF} equivalent, then with proper use of {$IFDEF's} (since the source code is so similar across these language families), the source code could potentially support all of the above languages from a single source code base...

But, of course, maybe that wouldn't be desired... maybe individual ports would serve those other communities better... and then again, maybe it wouldn't!

(Just thinking aloud... :-) )

Anyway, great work, and once again, very impressed by the lightweight HTML view widget!

First understanding: LLMs/AI's require Matrix math (aka "matmul"), lots of it, billions, trillions (and perhaps more in the future!) times per second.

Second understanding: It would be nice if we could create our own Open Source hardware for this, via FPGA's. Oh sure using an FPGA probably won't be as fast as using a dedicated silicon ASIC -- but they're great for learning and prototyping such ASIC's.

Third understanding (from the following web page: https://www.alphamatch.ai/blog/cpu-gpu-tpu-npu-lpu-dpu-ai-ch...):

>"Google's TPU takes specialization one step further. At its core is a systolic array — a grid of multiply-accumulate (MAC) units where data flows through in a wave pattern. Weights enter from one side, activations from the other, and partial results propagate without returning to memory each time — eliminating the memory bottlenecks that plague GPUs.

The entire execution is compiler-controlled, not hardware-scheduled, making it extremely predictable and efficient. TPUs scale massively — a single TPU pod can contain up to 9,216 TPUs working in lockstep."

Or phrased another way (Einstein's dictum, "As simple as possible but not simpler"!), by getting rid of any unnecessary digital logic components not directly related to the core task of Matrix math, the design can be radically simplified.

Fourth understanding: SpinalHDL apparently offers a lot (over Verilog, VHDL, etc.) to simplify the design of repeated-digital-logic-component hierarchies, such as the systolic arrays / grid of multiply-accumulate (MAC) units used for creating a Matrix-math only processor, aka an "AI accelerator"...

Now, with all of those understandings firmly in place, you are now prepared to read the Paper, above... and/or the one below! :-)

Related Papers:

FPGA validated RISC V system on chip with a custom systolic array accelerator for edge AI inference (2026):

https://link.springer.com/content/pdf/10.1007/s44163-026-020...

>"Someone asked what I'd do if I were 17. I'd learn how to build LLMs from scratch..."

That's funny, Paul Graham, because if I were 17 again,

I'd learn how to program in LISP.

https://www.paulgraham.com/rootsoflisp.html

https://www.paulgraham.com/iflisp.html

https://www.paulgraham.com/hundred.html

(And/or other LISP derived languages... Clojure, Scheme, Racket, TinyScheme, etc.)

I guess "the grass is always greener..." as that old expression, that old "chestnut", goes... :-)

One of the best deep-dives on AI chip architectures that I've ever read.

Other posters are welcome to their opinions, but I (again, personally) thought it was great!

>"The Forth interpret loop is very simple:

1. Read a word [string] from input.

2. Is it a number?

3. Yes? [Convert it and] Push that number to [the] Parameter Stack and go to 1.

4. No? Then is that word [string] in the dictionary?

5. Yes? Execute it [look up the associated address in memory and jump to it] and go to 1.

6. No? “Word not found” error. Go to 1."

...basically, that's all a Forth Interpreter is(!), in pseudocode (or in higher-level English as a code abstraction, if you prefer...)

(Key observation: There are no additional parameters to parse, no additional parameter lists to pass, because every FORTH function works on whatever data is in the stack, directly. (Every FORTH function could be said to be 'generic' from that perspective.) Which means that all we really need to do is look up the address for a function name and jump to it. That, and have a way to put parameters onto the stack. And that's all we basically need!)

Language compilers and language interpreters (programs that implement an underlying programming language) -- do not get much simpler!

Compare (cf.) the above to the complexity of the simplest compiler, or even the complexity of the simplest LISP (or LISP-like language) interpreter... it's simpler and less complex than either of those...

But, while very impressive (and it is!), that's not (IMHO!) what's so great about this repository... what's so great about it is the following list that starts out as follows:

>"This improvement in training speed has been brought about by the following techniques:

o Modernized architecture: Rotary embeddings, QK-Norm, and ReLU²

o The Muon optimizer [writeup] [repo]

o Use FP8 for head, and asymmetric rescale and softcap logits

[...] (etc., etc.)

See, that's like a who's who (or a what's what, as the case may be!) of

all the latest LLM training optimization techniques

In other words, it is a very information-dense list about optimization techniques for LLM training.

Think Mike Abrash, but 2026 and for LLM training...

In other words, a very high signal-to-noise ratio here!

Worth studying and re-visiting in the future for anyone into speeding up LLM training and/or people who just like algorithms in general... what a great list, and what a great tool!

intent."

>"but if i (or an agent working on behalf of me) use an API in an obviously

unintended

way to revoke other people's reservations..."

?

An AI cancelling other people's gym classes is a felony?

?

Don't computer systems fail all the time at holding reservations for people?

Heck, don't people fail all the time at holding reservations for other people?

You know, like in Seinfeld's "Alternate Side" Episode (S3 E11):

Jerry (to car rental attendant): "You know how to take the reservation, you just don't know how to hold the reservation... and that's really the most important part of the reservation -- the holding!"

:-)

Not holding a reservation should not be a felony... it should be a minor infraction at best, a Class C Misdemeanor (the least serious kind) at worst...

Also, there should be no jail time...

And no fine...

The criminal penalty for not holding other people's reservations should be that you actually have to start holding other people's reservations!

That's the Court sentence!

You actually have to start holding other people's reservations!

:-)

(You know, "let the punishment fit the crime!" :-) )

I don't use MacOS because it is not Open Source.

I don't use Windows.

I used Windows extensively in the past, but I don't use it in 2026, because it is not Open Source.

Anytime you're dealing with a closed source OS, you're dealing with the following things:

1) Extra time/effort/complexity to make your programs work correctly.

2) Extra time/effort/complexity to make your already working working programs keep working through OS version updates, upgrades, patches, etc., etc.

This article (AI written, not AI written, I don't care) describes something that is overly complex (proof that you don't have and/or cannot access the source code of the underlying operating system) and something which could potentially fail when Apple releases its next OS or OS upgrade...

If you switch to an Open Source operating system (and I'm not trying to shill for Linux here -- OpenBSD, etc., any open source Operating System could work too), then most of these problems will disappear -- or at least be reduced rather significantly.

But what I'm most concerned about is the complexity...

Now, you're welcome to engineer whatever additional complexity above Apple's stack -- many companies do this and are more than willing to pay the price in additional time, resources, programmers, tech people handling whatever issues arise, as they arise.

I'm not against Apple -- I think their products have beautiful aesthetics, and every company, every producer of physical products on the planet could take a lesson from their design teams. Their products are absolutely stunningly visually appealing!

But Apple in turn, could take a lesson from Linux and every other open source OS on the planet.

I personally will not develop for any Apple product unless and until Apple open sources their OS'es.

If code that I write coincidentally runs on an Apple product, hey that's a happy coincidence! Yay!

But I never expect it to, and I never expect to keep working across OS versions and upgrades.

If anyone thinks I'm being unfair to Apple, then I'll state for the record that I have the exact same expectations (or negative expectations, as the case may be!) about Microsoft Windows!

Closed source OS'es lead to complexity, work-arounds ("oh no, API call <abc> isn't working the way we thought it would under these conditions -- well, use this work-around and call API <xyz> with this unnecessary and overly complex data structure after making 3 other unnecessary API calls and then you need to do the following additional steps..."), and software breaking over time over OS version upgrades, updates, patches, and the like.

On the one hand, I'm very glad that this article is bringing micro VM's to Apple.

That's a good idea!

(But on the other hand, I have to ask if the complexity is worth it... but I'm not the guy who pays these guys' salaries or the future support guys' salaries, so I can't determine if it is or isn't, if the trade-off is worth it!)

On the positive side though, bringing Micro VM's to Apple is a good idea, at least in its purest idea form ("we want to add functionality X to platform Y" -- there's nothing wrong with the intention to add value to something -- in fact, quite the opposite! The whole of Western Civilization is based on that idea!)

Also, what I find, well, let's just say "entertaining" here in the HN comments is that some posters (who don't do very well at identifying themselves!) complain about the as-of-yet-somewhat-"imperfect" (let's just say) at this point in time KYC and identity verification of customers aspects of this thing... (you have to love the double standard there!)

Forgive me for saying this, but aren't all Bitcoin and all other cryptocurrency transactions (at least in all cryptocurrencies that don't track identity) subject to the KYC and identity verification complaint?

In other words, you've got the tiniest of fishes in this pond, Ben, and he's trying to do the right thing, and he at least is a little bit accountable to "the spirit and letter" of doing the right thing -- whereas all of the other black-box cryptocurrencies DO NOT do anything KYC or identity verification wise.

Yet you other posters, you other critics -- are willing to see the "mote in Ben's eye" whereas you are not willing to see the "beam" in your own -- all of the other black-box cryptocurrency, foreign currency, and other systems for trade/transactions that you do not control.

Ye hypocrites!

I have nothing to say to you... half of you are people with agendas paid off by dark money funds, and half of you are bots, also paid off by dark money funds.

Ben, you are on the right track, you are doing the right thing!

Ignore what all of these crackpots, cranks, and agenda-driven paid-for-by-dark-money naysayers have to say!

You always see them, en masse, on any HN article that is halfway political or halfway financial.

They are always hypocritical, always willing to railroad discussions to their political and/or financial ends.

They never observe the bigger issues, and if you debate them they will railroad the debate into corner cases and use those corner cases to make you look bad!

So, getting back to the software, I like it, I think it's absolutely brilliant!

And I'm a human being with a real name, real flesh and blood, and I can own every single damn thing I say on HN, every single damn comment I make, without ever hiding behind an alias!

(Maybe HN should implement a "KYP" policy. That is, a Know Your Poster. policy... That is, know the person making the comments...)

Anyway, way to go, Ben!

See, VPTERNLOGD is a ternary bitwise instruction.

In theory, that means that it could (in theory, temporarily ignoring other factors like streaming, parallelism, memory access speed, etc.) replace the Matrix Multiply (aka "MatMul") component of LLM's, if, if and only if the weights in an LLM are changed to ternary (-1,0,1)...

Matrix Multiply is at the core of all GPU's and AI accelerators -- so alternatives to it, such as VPTERNLOGD (especially on older/cheaper hardware, as x86 AVX-512F apparently dates back to 2016), as well as Ternary LLM's -- may be worth a little investigation...

Yes, ternary LLM's do come with their own set of problems(!) -- but as a strictly-for-intellectual-curiosity x86 instruction, I think that VPTERNLOGD is pretty interesting...

Related:

"NativeTernary: A Self-Delimiting Binary Encoding with Unary Run-Length Hierarchy Markers for Ternary Neural Network Weights, Structured Data, and General Computing Infrastructure":

https://arxiv.org/pdf/2604.03336

VPTERNLOGD/VPTERNLOGQ — Bitwise Ternary Logic

https://www.felixcloutier.com/x86/vpternlogd:vpternlogq

Microsoft BitNet - Official inference framework for 1-bit LLMs

https://github.com/microsoft/bitnet

Ternary Mirror-symmetrical Arithmetic And Its Application To Digital Signal Processing by Alexey Stakhov (related: Nikolay Brousentsov, the "ternary principle" aka "Brousentsov's principles"):

https://computeroptics.ru/eng/KO/PDF/KO21/KO21334.pdf

DeepSilicon (YC S24):

https://news.ycombinator.com/item?id=41490196

Observation: This, or any tool like this (any proxy which can negotiate an SSL and/or TLS connection) could be used to give simple browsers, browsers that don't implement SSL or TLS natively, SSL and/or TLS capabilities...

(In other words, if I were going to write the simplest of all possible Web Browsers, a Web Browser solely for teaching purposes, then I'd intentionally separate its source code from SSL/TLS/encryption code. Why? Well, it would greatly reduce the lines of code in the browser, which would aid greatly in making that source code easier to read/understand. SSL/TLS/Encryption could be implemented in a separate local proxy server, much like the one above, and the simple browser would gain the ability to make SSL/TLS/Encrypted connections through it, while keeping all of that additional code separate... also, on that note, JavaScript processing (all browser code necessary to run JavaScript) could also be separated into it own local server...)

So yes, again, very interesting!

I can just see a whole lot of other town squares having a public battery (and corresponding public charging facilities) like this one, in the future!

It's sort of like "town-from-100-years-ago" meets "technology-from-100-years-from-now" at this center point...

(Also, it would be a great item (if you're a salesman or enjoy sales!) to sell to small towns and municipalities... how could they say no? Wouldn't every small town want a public charging facility that doubles as a piece of art?)

Anyway, super interesting, and I'm looking forward to seeing more of these appear in public places in the future!

And that approximate doubling, in RAM requirements, year by year (compare to Moore's Law for hardware!) for Microsoft's OS'es, has got us, fellow students of computer history, to where we are today -- with Microsoft OS'es being the size that they are and requiring the RAM that they do!

And it all started with upgrading (or "upgrading", take your pick of term!) an 8KB OS to a 20KB OS! :-)

https://www.falstad.com/embox/

>"This java applet demonstrates standing electromagnetic waves in a 3-d rectangular box, or cavity resonator."

Maybe it's the idea that waves can carry slower frequency secondary waves, the idea that fields can carry slower frequency secondary fields, the idea that EM space itself can be stressed in a number of dimensions, and that these stresses, (depending on waveforms and modes of oscillations) could give rise to even smaller regions of stronger, localized (yet time/period/frequency dependent!) stress... much like waves in the ocean... to use a simple analogy... but this app really shows us what's possible...

Anyway, this page of apps is a must-have resource for any Physics or Engineering student... A+++++ !