They didn't really do a very good job of selecting marketing examples. The only good one, that shows off creative possibilities, is the knit elephant. Everything else looks like the results of a (granted fairly advanced) search through a catalog of stock footage.
Even search, in and of itself, is incredibly amazing but fairly commoditized at this point. They should've highlighted more unique footage.
An interesting problem for those who're good at e.g., geometric packing problems and space-filling curves.
I wonder about having an optional fill mode with more of a sphere-packing approach. I.e., instead of layering long threads of filament, what if you put down a bunch of dollop-drops in a checkerboard pattern and then staggered successive layers of dollops to fill the gaps?
Prior to computer-generated 3D animation, I can imagine it was very difficult to float and spin vector-arrows in mid-air with enough accuracy to show what goes on without having to resort to reams of explanatory paragraphs.
Eugene Khutoryansky is something of a lesser-known 3b1b that's more focused on physics than math. I found his animations very helpful for building intuition around Maxwell's equations:
I wish most explanations wouldn't skip over the fact that field lines arent real, and just a tool to graphically depict what is going on. Statements like the following gets the causality entirely backwards.
>the strength of an electric field depends on the number of electric field lines.
I think the question of whether field lines are real is more of a philosophical (of physics) question so it usually falls outside the scope of introductory material on E&M. However, some texts like Purcell and Morin do kinda take a stance on whether fields are real: "since it works, it doesn’t make any difference."
Very much this. The (standard model's) "answer" is that the four vector potential probably is the "most real" and we're all just excitons along for the ride.
At some point the definitions become almost circular and opinions about what it fundamental have shifted a bit over the centuries. The cgs system of units -- which differs profoundly from SI in the treatment of electromagnetism -- was associated with those who viewed D and H rather than E and B the most fundamental. I'm quite happy with the level of theory used being appropriate to solve the problem at hand. There's always a bit of wiggle room around exactly what that problem is, however ;-)
So, a bit like how the conventional depiction of electric flow is in the opposite direction of the actual electron travel?
It doesn't matter in terms of the math (in the vast majority of situations), so while the conventional idea of electric flow is incorrect, we keep it anyway.
I think it is closer to the conventional view of current as the travel of electrons down a wire.
Current moves far faster than electrons. it is more similar to a wave in the ocean with the electrons being the water molecule.
As a result, and counterintuitively for most, the speed of electrons will give you a completely wrong answer for when a light will turn on after you flip a switch.
Current is the movement of charges. It cannot “move” faster than said charges. (Or, perhaps, you meant the electomotive force that makes the electrons move along the wire, then sure, that thing spreads pretty quickly.)
yes, the EM force, Field, or whatever it is called. I still struggle, mostly because I was taught a fundamentally flawed model for how electrical power is transmitted.
Current is about the throughput of electrical charge at a specific point of an electrical circuit, while what you're describing seems to be about the latency or the speed of electricity.
isn't that a special case of Plato's argument that "triangles aren't real. show me a perfect triangle...you can't, you can only show representations of a perfect triangle"
Your comment could be reduced to "lines arent real. show me a perfect line"
I suspect something similar happens with manifolds for GR. Riemanian manifolds aren't a big deal when you contrast them to what happens inside of a DNN, but physical analogs for these structures start to break down.
e.g.
Imagine a 4-dimensional hyperbolic surface defined by the lightcone of a particular point in space-time, now imagine that this surface is stretched/compressed by the distortions of gravity. Now let's talk about equations which are only loosely tied to this surface.
vs.
Consider the metric tensor defined by this 4x4 matrix g_xz. Distance is computed as a^x b^z g_xz, now consider all possible walks from point a to c to b. Now let's show the relation between these walks and a quantity we'll call the stress-energy tensor which represents the energy/momentum density at any particular point in space, and it's flux towards any other direction in space.
The latter is a very algebraic description, which does not rely on the audience having to visualize the constructs involved. Practically, even if you get a feel for what a Riemanian manifold looks like in 4-dimensions - you'll struggle to visualize the Riemann tensor, or Christophel symbols.
Rust allows for higher stakes in terms of risk/reward while guaranteeing many aspects of safety. I'm not sure for this case if the scheduler would benefit from more complex/risky structures but if it did, that'd be a valid example of Rust making things "easier".
Rust definitely makes some easy things more difficult but on the flip side it arguably makes very difficult things easier (to get right with fewer guinea pigs).
When I use the word 'Simple' in e.g., a class name, I usually mean: ~"This is meant to cover the 80% of common cases--I haven't done extensive testing or development on it. If you need to cover something in the remaining 20% of edge and corner cases, you're going to need to write your own more complex code to handle those."
I.e., my code is simple--and that might make your usage complex.
Of course, things can evolve from the original implementation--especially if the code is maintained by a team. What was once 'simple' (from any perspective) can become terribly appendaged yet never renamed.
I think one part of the trick is that you find high-functioning people but in less-overlapping domains.
In one of the more successful teams I was on back in the day, I was a JavaScript developer and was paired with some Flash developers on a project where we had a lot of back and forth calls crossing the boundary. I'd ask them to implement a way for me to call their logic and then they'd ask me for a way to call my logic. We were both super-responsive to the other because neither side had much interest in imposing our preferences in the other's very distinct domain.
On the flip side, we were both quite capable in our own right and thus able to agree on the overall architecture pretty quickly. With some people, you'd probe, "it seems like you should have a way to do X, right?" and they'd respond immediately, "that's definitely not possible, you'll have to work around that". So you'd push, "do you want to check?" but they'd decline so you'd take it upon yourself to dig in and point them to relevant documentation. With these guys, their response to the first question was, "Of course we can do that and you can do Y for us, right?".
It's group of people A, who are conducting a [series of] transaction(s) with group of people B. It so happens that the wares being exchanged are currency vs. software but that's really besides the point.
Yep. The primary fault lies with the too-many people who abused the non-hostile system. "This is why we can't have nice things"--because trust is too costly in the societies where hostile architecture is prevalent.
I get that and agree. But why is the 'easy path' to leave the garbage even in conditions where there is a garbage can right there? Shame and motivation probably seem like the wrong tools here. It seems like something is lending it to us just not doing it the right way. It is like something in the architecture lends itself to people just ignoring the obvious way. My wife was telling me about a 'gum wall' at an amusement park. I immediately saw that as a way for the park to basically hack people to not throw their gum on the sidewalk. Basically a weird reward for keeping your gum and putting it on that wall. The architecture and mythos encouraged people to not do it.
My favorite is being asked to estimate a bug fix before I've had any chance to analyze the issue.
It's like calling a mechanic over the phone and asking how much it will take to fix your car. The mechanic doesn't know if the engine just fell out of your Model T or if you're just trying to put the key in backwards. How about you bring it in first, then we'll look it over and go from there?
Sometimes you can ask some questions and get to, "Well it's probably X which would take Y but we'll need to see". Then they get Y stuck in their head and it turns out to be the one time out of twenty when the cause isn't actually X but something much more involved.
If you're being asked to estimate a task without insufficient information on what the task is, punt it back with 'More information needed, we'll look at it 3 weeks from now in the next sprint planning'.
Even search, in and of itself, is incredibly amazing but fairly commoditized at this point. They should've highlighted more unique footage.