> The Library of Congress has said trying to count them is nearly impossible.
4,769 karma · joined July 28, 2009
https://bitcoin.clarkmoody.com/
[ my public key: https://keybase.io/clarkmoody; my proof: https://keybase.io/clarkmoody/sigs/VKSVLAktYAYCG6qBgCRbOXbBIBzCSuj5yCUx-hybU10 ]
> The Library of Congress has said trying to count them is nearly impossible.
First reply was exactly the same as most of the top-level comments here today: "That doesn’t prove anything. Make your fake video, point your phone camera at it, record."
Of course, I'm sure someone else had thought of something along these lines in the 90s, I just didn't have a citation to hand.
Perhaps this has something to do with the economic dislocations and world wars between the 1870s and today?
[1]: https://clarkmoody.com/Moody_AgentBasedElevatorControl.pdf
Cry me a river.
Branches of humanity torn between decadent stagnation and radical evolution. The artificial intelligence civilization with its own agenda. The All Thing (Internet) as the third branch of government.
So much good stuff, published in 1989 no less.
Rest in Peace to a true legend.
self.prev.iter()
.chain(iter::once(self.active))
.chain(self.next)
I'm not sure what you mean by including active in another position, but see my sibling comment that makes the active element of a different type, for another wrinkle on this thing. struct List<T, A> {
prev: Vec<T>,
active: A,
next: Vec<T>,
}
This could be used for some active type that has ephemeral cache information or state associated with it (view state in a GUI app, for instance). The inactive type may be hydrated and converted to active, and the active type can be archived into an inactive type.A concrete example is for managing the active item in a list. Instead of storing the active item as an index into the vector like this:
struct List<T> {
items: Vec<T>,
active: usize,
}
...which two the glaring impossible states. The vector can be empty, or the index can be outside the vector. Each time the active item is desired, we must check the index against the current state of the list.Instead, we can use the zipper concept so we always have a concrete active item:
struct List<T> {
prev: Vec<T>,
active: T,
next: Vec<T>,
}
Switching to a different active item requires some logic internal to the data structure, but accessing the active item always results in a concrete instance with no additional checks required.[0]: https://sporto.github.io/elm-patterns/basic/impossible-state...