The camera is positioned so that the side window is visible through the front windshield. I think the "black coating" you are seeing is just the interior of the van, and that the entire front windshield is usable.
I was having some difficulty figuring out how Hy actually is translated to Python (and wasn't even sure if it was compiled or interpreted). Eventually I found on Wikipedia the following:
> Hy is a dialect of the Lisp programming language designed to interact with Python by translating s-expressions into Python's abstract syntax tree (AST).
I kind of wish this was made more clear on the main website. Perhaps, instead of introducing Hy as "a Lisp dialect that's embedded in Python", introduce it as "a Lisp dialect that compiles to Python's AST". The words "embedded in Python" don't make it very clear just how it's embedded into Python. The various ways you can embed a Lisp look very different and have very different tradeoffs.
For example, off the top of my head, I could "embed" a Lisp by writing an interpreter (in C if I care about performance) and letting it be called from Python, perhaps passing in a Python list instead of a string to make it more "native". Or I could "embed" a Lisp by compiling to Python bytecode. Or I could "embed" a Lisp by translating it directly to Python source code. Etc.
> Hy is a Lisp dialect that's embedded in Python. Since Hy transforms its Lisp code into Python abstract syntax tree (AST) objects, you have the whole beautiful world of Python at your fingertips, in Lisp form.
> The various ways you can embed a Lisp look very different and have very different tradeoffs.
Hy itself provides options. Typically the process is that the Hy source code becomes Python AST objects, which Python then complies and executes, but you can also translate the Python AST objects into Python source text. Or you can use Python from Hy or vice versa: https://hylang.org/hy/doc/v1.0.0/interop
The "embed" part stems from the fact that you can mix Python and Hy in a project with bi-directional calling. Works great, because it is all Python byte code in the end.
The original hy annoucement makes it clear that they embed a Lisp by compiling with Python bytecode. You can see it in the following video about the 16:25 mark
The Hilbert curve does contain every point in the unit square. It is a limit of curves, and so can contain points even not in the intermediate constructions. This is similar to how the limit of 1/x as x -> infinity can be 0, even though 1/x never equals 0.
Also, a curve which gets arbitrarily close to every point in the unit square actually touches every point in the unit square. This is because (by definition) a curve is a continuous map from a compact space (the unit interval) to a Hausdorff space (R^2), and so its image is compact, and thus closed. A closed set contains every point that it is arbitrarily close to.
If I travel one half of the distance from where I am to the finishing line an infinite number of times, I reach the finishing line but still never finish the race.
With a Hilbert curve the entire plane becomes a limit.
This doesn't seem to fly with the inductive fact that 1/2 of a power of two is always one over a power of two no matter how many times you perform the iteration.
There are a countably infinite number of rationals between any two rationals, you can even keep splitting up those rational infinitesimal gaps into countably many rationals that are infinitesimal even relative to the earlier infinitesimals.
And you still only end up with a countably infinite set of expressible locations and not the real continuum.
Either x, y, or both are guaranteed to be a number of that form for all values on the curve.
It looks simple and elegant to me, and I've only used Clojure a little before. Perhaps you're just not very experienced as a programmer in anything except mainstream languages.
I don't understand why this was downvoted. In case it's not clear: (S)he's saying to split the key into multiple shares that can be used to reconstruct the key if you have a large enough quorum. Then store each share in a different place. As long as you don't lose too many of the shares, you'll be fine. And one baddie is NOT enough to get the key.
Either shuffling those keys stored in N different deposit boxes is overly complicated for a normal person, or it is not overly complicated for a moderately dedicated baddie either
Unless the "baddie" in this case is the government, why would it be easy for anyone to obtain access to multiple secrets stored in multiple boxes/banks?
Multisig is a pretty common setup for crypto and there is software that makes it easier.
Do you know why introductory textbooks don't define the determinant in terms of the exterior product? This is how some "real" mathematicians I've talked to define it. It also is more intuitive (in my opinion) to define determinants as "signed volumes" than some sum of products multiplied by signs of cycles.
The product of eigenvalues definition is also somewhat intuitive to me ("How much does the matrix scale vectors in each direction? Now multiply those numbers together."), but it's harder to motivate the fact that adding rows together doesn't change the determinant, which is kind of important to actually computing the determinant.
How do you know they didn't have other books about civil rights? Maybe they had an entire library filled with such books, but that wasn't brought up in the article.
reply