It means the eigenvalues will only give you information about the system relatively to the center of that system.
Before describing any system, it's up to you (your "convention") to assert where is the zero-point of your world and in which directions the axes (x,y,z) are pointing.
For instance, in the real world you can choose your 3D coordinate system such that your mirror, as a physical system, keeps the origin untouched (0,0,0) -> (0,0,0). If you decide the origin is a point on the mirror, the equations will be linear: mirror(X) = AX. However if you setup the origin some point far from the mirror, like the center of your eyes, the equations are no longer linear, but affine: mirror(X) = AX+B. Looking at the values of the "AX" part of the system would reveal you the mirroring plane, but now shifted by an offset of "+B" -- the distance between the mirror and your eyes -- because your choice of coordinates was not leaving the origin intact.
It's entirely a myth that unsafe is needed to get speed boosts in Rust. Usually, the standard library, as well as other crates, offer optimal performance without resorting to unsafe code.
(If we go pedantic, Vec and other primitives do rely on unsafe, but the point is as an application developer you don't have to write unsafe code yourself.)
It's not entirely a myth. There are situations where you can't get the compiler to emit optimal code using only safe Rust. You can go a very long way with only safe Rust (and i do!), but not everywhere.
There are also situations where you cannot get a C++ compiler to emit optimal code without resorting to intrinsics or inline Assembly.
99% of Rust and C++ code performs well without going that deep.
Unsafe rust exists for a reason. There are cases where perfectly safe code cannot be expressed according to Rust's ownership rules, and an escape hash is needed. Of course the "average" developer probably should not resort to unsafe as a rule of thumb.
Also regarding the standard library, as far as I understand it's not entirely true that it never resorts to unsafe rust. For example, I understand that the standard library makes use of specialization, which remains an unstable feature because of a soundness hole in the implementation.
> Also regarding the standard library, as far as I understand it's not entirely true that it never resorts to unsafe rust.
I think you're misunderstanding the parent comment. The stdlib constantly resorts to unsafe code. Tons of methods like `split_at_mut` and `make_ascii_uppercase` are just safe wrappers around an unsafe one-liner.
Rather, the observation is that _with the benefit of the stdlib and common crates_, most programs have no performance reason to reach for unsafe in regular code. That's true in my experience.
I agree that most developers don't need to bother with unsafe code, and will not pay a performance penalty for staying within safe rust. My only point is that it's not necessary to be so dogmatic as to say that no-one should ever write a line of unsafe rust.
For instance, if you read the rust book, they make references to times you might want to use unsafe:
> Borrowing different parts of a slice is fundamentally okay because the two slices aren’t overlapping, but Rust isn’t smart enough to know this. When we know code is okay, but Rust doesn’t, it’s time to reach for unsafe code.
In my experience most of the time I had to use unsafe was to bind unsafe interface (think something like making raw OpenGL bindings for instance, you'll have unsafe code all over the place and you'll have write your own safe wrappers around it). Performance-wise I very rarely find myself having to compromise, although there are times where I have to write "smarter", more complicated code to get good performance without unsafe.
I just looked at the code of a pretty heavily optimized program I've been working on for a few months, I have exactly one instance of unsafe in the code:
I need the unsafe because at the moment the language is not smart enough to understand that 0xf610 is obviously non-zero and that I can build a NonZeroU16 from it without fail (at least I don't know how to express this in static expression at the moment). This has no performance implications whatsoever.
Rosetta was built in a clean room according to COSPAR
rules, but "sterilisation [was] generally not crucial since
comets are usually regarded as objects where you can find
prebiotic molecules, that is, molecules that are precursors
of life, but not living microorganisms", according to
Gerhard Schwehm, Rosetta's project scientist.
See also the Committee on Space Research (COSPAR) Target Categories:
This will be especially true for instruments that are designed to find such compounds. It would be fairly embarrassing to send the probe into space, only to notice that apparently interplanetary space is full of organic compounds no one else has ever seen ...
Nitpicking: surjective functions do not relate to unicity of ouptuts; you'd rather talk about non-injective functions. I agree with your point, though.
(surjective != non-injective, in the same way that non-increasing != decreasing)
Recently I've tried an approach where I send two documents when asked for a CV:
- a "classic" CV which describes education, skills, work experience, and "miscellaneous" projects (late night hacks mostly);
- a second document entitled "friendly CV" but which is actually a short pdf with slides. It is super casual and I explain my previous work with pictures of algorithms and technical stuff. I cut down all the noise and try to speak directly to the inner geek of my potential reader.
From my perspective, I'd say I had quite some success with it.
I think it doesn't matter if you do exactly that. The point is to wake up your reader if you're the 50th CV they're reading this afternoon.
Nice demo! Feature request: I'd like to see the people talking, like display sentence of a random pair of agents, every 10 sec e.g. That way I would feel immersed into users discussions :)
More info: PhD in Machine Learning (time series analysis for gesture recognition). I have the profile of a good data scientist with excellent software engineering skills. I can bridge the gap between research scientists (good POCs but crappy engineering and slow perfs) and software engineers (write good code but struggle to grasp underlying math).
Before describing any system, it's up to you (your "convention") to assert where is the zero-point of your world and in which directions the axes (x,y,z) are pointing.
For instance, in the real world you can choose your 3D coordinate system such that your mirror, as a physical system, keeps the origin untouched (0,0,0) -> (0,0,0). If you decide the origin is a point on the mirror, the equations will be linear: mirror(X) = AX. However if you setup the origin some point far from the mirror, like the center of your eyes, the equations are no longer linear, but affine: mirror(X) = AX+B. Looking at the values of the "AX" part of the system would reveal you the mirroring plane, but now shifted by an offset of "+B" -- the distance between the mirror and your eyes -- because your choice of coordinates was not leaving the origin intact.