drostie

I would love to work on old cars if I were not living paycheck-to-paycheck. However if I had the free money, well before I started tinkering with old cars, I would probably start scheduling vacations in eastern Africa. I'm not sure what exactly I'd be doing there, but I figure someone's got to have wiring issues or plumbing problems or a broken tractor or something -- anything that I could put my Applied Physics degree towards.

Right now I've got a tutoring side-job; that's basically similar. My work boils down to the fact that I like people and I try to help them with whatever skills I've got.

I guess "regulation" was the wrong word because that gets into the legal aspect of it; I meant purely the programming side, "we won't give you this certificate unless our web app's counter for you hits 52." "Oh, well, I'll make something that clicks your app's counter for my employees!"

Obviously, yes, this fell foul of the actual regulations, which were not "the web app's counter hits 52" but rather "you need to spend 52 hours looking at this stuff."

So, the difference between a "hacker" and an "engineer" has always been this idea that the engineer is designing something which is principled at all levels, whereas the hacker is putting together something which works in the most obvious cases but doesn't necessarily cover all of their bases. In practice, I think we all know that a little of both is best; ideally you can throw something together with copy-paste programming to sign a new client, say, and then you can rethink it from the ground up once you've got that proof that someone needs it. Hacking is much cheaper than principled design.

What I'm taking away from this article is that this is also true at the CEO level. Conrad sounds like a hacker's philosophy, writ managerial. If there's a regulation that your browser spend 52 hours on a web page, here's a script to make your browser browse that web page for 52 hours, clicking aimlessly among the pages. You're welcome; you've got other crap to do. Or, if you don't have a license to sell this thing -- well, you still seem to be able to sell, so let's just do it the way that works for now, as a proof-of-concept, and we can always do-it-right later.

And that's not a bad thing! It works great for software! But it looks from the article that therefore the hiccup that the company faced was somewhat predictable given the personality of the CEO. It's hopefully an instructive lesson for any venture capitalists who don't already realize that you need that both-hacker-and-engineer versatility up-top. Because it's the exact sort of hiccup you get when your software team is hacker-only and always put under pressure to get more done, but never under pressure to do it right. Eventually the code spaghettifies to deal with all of the real-world problems, and the sooner you can catch it before it becomes a hairball, the better.

My job right now is, I maintain a big data processor. I can freely testify that there are still a ton of quick hacks that are stuck in various places. But every week or so, I get a little downtime -- and when I don't spend that peeking into Hacker News, I spend it trying to modularize the hackery and then swap in carefully-reasoned modules for quick-hack modules.

I implore other software engineers to do the same; and I will definitely start thinking of more management-level decisions this way, in terms of "quick clever hacks" versus "careful design."

Furthermore, this idea that nobody's studying the number-of-blades problem is bogus too. When I worked abroad as a research assistant in the Wind Energy Project Group at the TU Delft (biggest tech university in the Netherlands), one of the researchers showed me a very interesting wind turbine that had a massive, elegantly curved blade on the one side and a big blob on the other. He explained, "We've been doing some simulations on these one-blade designs, even though they look goofy. This blob is just a counterweight, it is very cheap to produce because you don't need any advanced materials to use it. So the question is, if you had three times the budget to spend on just one blade, could you make it so good that it would outclass the three-blade model completely?"

In fact I asked why he wasn't going with 5 or 7 or 9 blades (he explained that even numbers tend to be Bad News) and he explained that the big problem was, as you increase the number of blades, the proportion of the rotor disk that consists of blade gets higher, which means the force on the tower component gets larger -- it goes something like the third power of wind-speed. Every few years or so, hurricane-force winds batter parts of Europe, and therefore there is a massively important design requirement that the wind turbine not completely be obliterated during these violent storms. An airplane with a funky propeller can of course be stored indoors when this happens; a turbine would require maintenance technicians to disassemble each one the day that the high-wind forecast was received.

Googling some of these related issues brings me to the page:

http://mstudioblackboard.tudelft.nl/duwind/Wind%20energy%20o...

However I cannot say with great certainty whether this is the same person that I heard these things from, or just a peer in the same field with the same general conclusions.

The etymology here is actually really interesting. The term "tank" was an Americanism for a swimming pool once upon a time, and the etymology of that is pretty well-known: it was imported from a Portuguese word meaning "pond" which ultimately came from India [1]. The same source quotes a 1960s usage of the term for "failure" in the sport of Tennis.

The term actually seems to come from a 1920s boxing euphemism [2]: when a boxer is not actually knocked out but voluntarily lays down on the ground, it was called "a dive" for obvious reasons; euphemistically some people called this "going into the tank," since you'd dive into a pool.

How did this start referring to the vehicle? Again, back to [1], there was once a memo "recommending the proposed "caterpillar machine-gun destroyer" machines be entrusted to an organization "which, for secrecy, shall be called the 'Tank Supply Committee,' ..." and the rest is history.

[1] http://www.etymonline.com/index.php?term=tank

[2] http://www.slate.com/articles/news_and_politics/explainer/20...

One of the things that has really changed my thinking about an entire cluster of related questions, and informs this one, is a Bloomberg article from a law professor about a year and a half ago.[1]

If you followed the link, skimmed through the article, and are now back at this comment going "what the hell are you talking about," go back to it and reread the first two paragraphs. It's really short, and it packs a punch, even if you're not a libertarian (I'm certainly not).

If you don't want to click through: Don't support a law unless you accept that it will kill some of the perpetrators. A law needs to survive its collateral damage. It is always a strong, non-theoretical possibility that due to some law, and whatever dynamics are available at the time, that someone will die as a result of it. It just requires a pimp or prostitute (in this case) who is being apprehended to accidentally move in just the wrong way, show just the wrong disrespect, that some police officer thinks they're in imminent danger of being attacked or shot. And, are you going to be comfortable with it?

The linked article points out that this is true in the case of Eric Garner's crime of selling loose cigarettes: nobody really thinks that this is something anyone should potentially die over. Similarly, I would say, for the act of selling one's body -- perhaps it might come with fines, to discourage it, but jail time seems insane. And one of the reasons is that it puts a threat on the lives of the women who are presumably already being trafficked.

(The article contains a bunch of other gems from a book it recommends: for example if you're having the "I don't need privacy; I've done nothing wrong" thing, you can be like, "statistically according to this book there's a 70% chance you have -- you probably just don't know it yet. Have you read the 3,000+ federal laws and do you know the 300,000+ federal regulations to be sure of that?")

[1] http://www.bloomberg.com/view/articles/2014-12-04/law-puts-u...

Caches:

https://web.archive.org/web/20160505153552/http://www.russet...

http://webcache.googleusercontent.com/search?q=cache:9BEl9sv...

Maybe, but you get five tries before you get locked out, so even if your lawyer pleaded successfully with that, the judge could reasonably order that you try with, say, all the fingers of your right hand, or maybe both thumbs and index fingers, without forcing you to disclose that knowledge.

(a) It means he's got a few hundred million dollars stashed away in BitCoin.

(b) He can then claim priority as benevolent dictator for life, with a reasonably good chance that the community will follow him. For example, he could probably fork BitCoin to have more frequent transactions and larger block sizes, and his fork would hit a critical mass of users to the point where the BitCoin Core group would have to accept those changes or else risk a blockchain split which could kill the currency altogether.

Um. Yes it does. If you prove that you are not (not Satoshi), then you prove that you're Satoshi. There is this widespread myth that "you can't prove a negative" when, in fact, you can.

You might have been meaning to point out that the characters of evidence needed in either case are somewhat different: the problem with proving some negatives via an argument from silence is that an absence of evidence is expected. You see, it's an absence of expected evidence that's evidence of absence! If, given something were true, we wouldn't expect to have evidence of it, then such "arguments from silence" (we lack evidence, therefore it's not true) do not work.

So when I want to prove that someone is not a giraffe, I can reasonably expect that if they were, they would have a long neck, walk on four long legs, probably stand taller than a given human -- if I see no evidence that they have any of these, we have an absence of expected evidence. This functions as evidence of the absence of their giraffe-ness.

But when I want to prove that someone is not immortal, say, there is no expected evidence of immortality for me to hang my hopes on. I mean, I might hope that they'd been born long enough in the past that they'd have documentation of their existence lasting out hundreds of years, but I'd have to introduce more assumptions to expect this. Or I might hope that they'd been subjected to lethal force sometime during their lifespan and lived through it, but in the posh, cushy developed world there's not necessarily any reason to expect that the typical 30-year-old has suffered a grievous injury, so I'd have to introduce added assumptions about their rough past before I could expect this. Still, proof would still be possible in such a circumstance -- just ask them to kindly survive stepping in front of a train or so -- and the negative could be proved. It's just that it can't be proved by an argument from silence.

The usual way to make this semi-rigorous is to use the definition of conditional probability, where the event "A given B" is written "A | B" and its probability is defined as Pr(A | B) = Pr(both A and B) / Pr(B). Then we have some claim C with some new evidence N and some old evidence O; we can prove that three numbers that need to be known:

    P = Pr(C | O)
        the prior probability of C before adding evidence N;
    Q = Pr(N | O and C)
        the likelihood that C would generate this evidence N, given the old evidence,
    R = Pr(N | O and not-C)
        the likelihood that not-C would generate this evidence, given the same.

The expression for the probability that we want to know is then:

                              Q * P
    Pr(C | N and O) =  --------------------
                        Q * P + R * (1 - P)

An argument from silence is just an argument where the new evidence N to be incorporated is the lack of some observation, for example the lack of observed dying after being shot by a gun, or the lack of observing a long neck on a person claimed to be a giraffe.

We can then see that arguments from silence are still supportive (Pr(...) > P) whenever Q > R, but may not raise P to the level where we'd really bet on it. In particular if P is very unlikely (e.g. immortality would have a P of one in 10 billion or worse, given what we've seen about the world), then with Q=1 (e.g. not dying when shot, given immortal), you're still looking for R to be commensurately tiny (e.g. the shot must have survival odds 10 billion to 1 against) to raise the argument from silence to a decisive position. Any weaker sort of silence does not confirm it enough to raise it to the level of plausibility, although of course you can rinse and repeat with N now incorporated into O (so we can talk about someone who has been shot, poisoned, and hanged many times on many different occasions and each of them might have a 1/100 survival rate; still if we have her surviving 5 such things which are individually bad evidence, we may get a non-negligible probability that all together they are good evidence and either she's conspiring with her killers or else maybe she is, in fact, immortal.)

Most of the "important details" aren't, as far as I can see. The only big thing that the pool adds is plausible deniability: everything else can be simulated by sufficiently complex tumblers; it's just that the vast majority of mining payouts are untainted that gives this a mixing effect. (You can delay payments and pay back in installments to multiple addresses that are not the source address but are owned by that person, via either mechanism.)

Running some numbers, it looks like about 98% of Bitcoin's hashrate seems to be held in the top 10 mining pools; assuming this isn't a common service provided by those top pools then a mining pool which launders too will have, say, 1% of the network hashrate at most. That's actually a nice place to be in; it means you get a payout roughly every 1000 minutes of 25 BTC (~$400) plus what looks like typically 1500 transactions or so paying you about a nickel apiece -- so let's optimistically say you get a payout of $600 total every 16 hours, or $900/day. Maybe you can keep plausible deniability going even when 25% of your revenues come from laundering transactions, so that means they can launder about $300/day. That's not too bad, about $100k/year, but it's not a massive chunk of the money laundering happening worldwide either, which usually is quoted in at least terms of billions of dollars -- so 4-5 orders of magnitude larger. Even considering how much the network as a whole could maybe launder if they were crazy about it (100x more participation in laundering, 10x more revenues from laundering transactions) you're still only 1-10% of total global money laundering by this mechanism before you have no presumption of "most of this money is clean so the laundered money is properly hidden."

So e.g. if you wanted to launder $1m within a year using our example pool then you'd have to pay in $2700/day and the legitimate transactions of the pool would only be 900/3600 = 25%; I'm not claiming that this is insecure -- but rather that a normal tumbling system could do this too, purchasing 25% of the money-to-be-laundered from a BitCoin exchange, gradually paying out over a year, and reselling the surplus 25% back on the exchange, for no real difference in security (but potential gains in speed and volume). If you charge a 10% laundering fee then this is an investment of $250k to gain $350k over the course of 550 installments in the year, so if I'm doing the math right that's a return rate of 0.13094%/installment or a nominal rate of 72%/year -- plenty enough to cover whatever risks there are in the currency, inflation, opportunity cost, etc. So it wouldn't be prohibitively much to ask the laundering network to invest, if I'm doing these numbers right.

Can someone else confirm to me that I'm not crazy and the central distinction of this article is totally bogus?

Reasoning: BitCoin isn't, to my knowledge, a scheme where some private identifier is stored inside each "coin" whose ownership is revealed with a zero-knowledge proof; it's simply one where you have public and private keys and use those private keys to sign transactions saying "Take X1 out of my public key K1 and put X2 in public key K2, with X1 - X2 going to the miner." That is, BitCoins themselves, as I understand them, are just points in a big distributed videogame: they do not represent actual packets of data which are individually 'minted' in mining and stored on your computer until you spend them.

If that's correct, then there's no distinction if you tumble-via-miners versus tumble-via-tumblers -- either way the coins are 'freshly minted'; there's simply no other sort of coin.

The only real thing that you seem to be able to do here is to tumble via both the tumblers and the miners, which might create some binary tree of complexity if someone tries to "follow the money" -- but that doesn't seem to be what the author is saying.

Is there legitimately something in each coin which makes it easier to follow a given bitcoin via tumbling than through miner-money-laundering, or are they really just the same thing performed through different channels, with a much slower rate of success for the MML tumbling?

They will be automatically incorporated.

To see why, think about this at a much coarser granularity: just people who operate miners. Suppose a new version of the BitCoin software comes out which makes you lose all of your money. Will you switch over to that software? No, you'll just keep the old version that lets you keep your money. What about the peer pressure to switch over? Well, if all of the peers stand to lose by switching over, your peers are likely going to band with you, precisely to not switch over.

Therefore any change needs to be backwards-compatible. Software changes come in the form of updates, "Before block #123456, block sizes will be X; for that block and after, block sizes will be Y," issued some months before block #123456 is likely to show up.

It's actually a parallel to something where I saw an agnostic philosopher debating some Christian fundamentalists who were totally out-of-their-league. They were supporting a divine-command-theory of morality. He was saying something like, "That's stupid: your morality could change tomorrow; God could tell you something different, like that you have to kill babies, and then that would become the Right Thing to Do -- but that's in the face of every moral intuition we have."

They were saying something like, "of course, God can't change his mind because he's eternal, so that's a non-issue. The laws of morality are therefore eternal and your example is impossible."

He replied, "No, I'm saying that God's eternal rule could be, 'Before 6AM on May 15th, 2016, GMT, killing babies shall be bad, and afterwards, it shall be everyone's duty.' It's a perfectly eternal rule that does not require God to ever change His mind. And you're saying that you're totally comfortable if that turns out to be the way that God's moral laws work, right?"

To a temporal agent, an agreement about the structure of eternity can always be renegotiated among those agreements which amongst themselves agree on the past and nearby future.

This needs to be the top comment in this thread; it precisely gets to the heart of what's being said here.

I mean, the other criticism is good too--I was trained as a physicist; I too balk when I see quantum mechanics used this way. (I'm a big fan of Searle's third law[1].)

But I mean, the only point that we're actually seeing used here is that QM is creating a huge amount of tension for people who used to comfortably believe in an objective observer-independent reality. That's not actually a hugely divisive issue here. One issue that isn't particularly quantum but is brought up here is that there seems to be a strange embeddability problem in the most basic theories of consciousness, also highlighted by Searle as part of his "Chinese room" thought-experiment: somehow the two halves of your brain merge into one consciousness, but somehow we don't think that two people dancing really do; we don't think that the two halves of your brain keep separate accounts of reality quite the same way that we do think that two dancers do: what is the boundary? Is it just, say, a matter of the volume and frequency of communication as related to the reaction speeds of the surrounding media? Or what?

Similarly the issue that Donald Hoffman's raising up-front is precisely the one that you're analogizing: hey, there's no reason to think that this language that our brain uses maps directly onto the fundamentals of the reality; rather where there is a translation between these two it's complicated at best, and you're only seeing the world after layers and layers of programming have acted on it. Maybe at the most fundamental things are crazily different -- and we can't understand them easily, if at all -- and what we've got are really effective models. When this happens, and what the universe is doing "down in the plumbing" starts to get really difficult to understand, it's going to be more useful for us to regard our impressions of reality as a sort of farce -- except that pragmatically, we can't do that, so we have to regard the underlying we-can't-actually-experience-it-but-here's-what-we-think-it-is reality itself as a sort of farce.

That feels like an uncomfortable "turtles all the way down" place to head, but I read Donald Hoffman as saying precisely, "Hey, it's not as scary as it sounds, just try it for a few: I'm not promising any dramatic answers, in fact I'm just promising less bluster about 'here's all the stuff we know for sure' and more honesty about how little we really know."

[1] Searle's third law is a fun one, and this whole talk is fun: https://www.youtube.com/watch?v=vCyKNtocdZE . About at 25:30 in this discussion of philosophical problems of free will, there's a great aside: "Well, think about it, is there any part of the universe that we have solid evidence to believe is not fully determined? And the answer is, of course, we know from quantum mechanics, that at the most basic level, it's not deterministic. Now -- I dread saying this, 'cause Searle's third law is: whenever philosophers talk about quantum mechanics, what comes out is hot air, at best. And I won't use an even more obscene expression. Oh, by the way, that applies to a lot of things physicists say about quantum mechanics, too: Feynman said, look, don't try to think what quantum mechanics means, just do the equations, for God's sake, don't think you understand it -- well, unfortunately, I get paid to try and understand things! So. There is a part of the world that's not deterministic." And then continues back on the thread that he was on.

Right, the point would be for the hash to strip out file info, line numbers, whitespace, comments, any stylistic choices which turn out to be equivalent "under-the-hood" in some straightforward way, and probably even the bound variable names (with de Bruijn indexes).

What I want to see in a language would be a bunch of syntactic sugar which corresponds to a MIR like Rust's by a well-specified reduction that is likely to be consistent from build to build.

The reason that this could be really cool is that you could hypothetically hash these MIRs and store these hashes in a public database of open-source code. (You would have to include hashes of whatever functions they call/depend on, and you would have to solve foreign-function imports.)

Then you would have this cool language where modules are simply saying "here's a mapping of names to hashes in the public database," with automatic recognition of "hey, these two functions you're importing from these two modules are actually the same function, I don't need to disambiguate them." If your dependency graph isn't a tree and one of the branches can't cope with a dependency-upgrade, that's fine too -- you upgrade the dependency on the one branch only. The point is, all of your dependency-semantics are now reduced to a really straightforward reasoning about unique names.

I think the archaeologist almost surely meant this and the reporter completely screwed up the story.

It would be functionally insane to think that authoritarianism came fundamentally out of a New World archaeological site that is 3000 years ago. For example, in order to sustain this belief you would have to believe that someone from this culture traveled to Africa and then invented time travel, so that they could go back to the mid-2000s BC and give the idea to the Old-Kingdom Egyptians.

Just to give some numbers by rectal extraction: I am about 98% sure that a seasoned academic from Stanford would not be so clumsy with his speech as to say outright that he thought this had happened; I am only maybe 75% sure that a given reporter understands a given scientist's research, so given that we have this report I'd estimate .98 * .25 / (.98 * .25 + .02 * .75) = 94% chance that the reporter misunderstood the scientist, and only a 6% chance that the scientist really believes what the reporter was saying. It's possible but I definitely think it's highly unlikely.

Somehow my brain turned off for the logo & the authors and I just started reading the main text. So somewhere in section 5, I started thinking, "Wow, this is great, it's like several talks I've heard from Alan Kay. ... ... Wait a minute..." Yep, he's the coauthor.

I would guess that from his perspective (which may not be what the court decides is the right perspective, of course) he might be thinking something like, "hey, we started this together, I had these 10 ideas, we parted ways because we have the wrong personalities to work together, now I see 8 of my 10 ideas in the finished product (even if it's out of, say, 100 total ideas or whatever) -- and I feel like you never actually compensated me for about a month of genius that I provided. By helping you start this thing it was secretly our baby all along, and I was okay with you doing whatever you pleased with it while it was a bunch of crazy ideas that hadn't proven their mettle; but now that they have, this is my last chance to speak up for my fair share."

Again, that's not necessarily the truth, but if you want to understand the psychology of how someone can claim this stuff and feel reasonable about it, that's how. We've very much only heard one side of this discussion and while Altman's side is very reasonable, it'd be interesting to see the other side.

To be fair, this is actually a problem with the environment that goes way beyond the individual pieces of content, and is one of the reasons that Alan Kay thought that the Internet was professional but the Web was amateurish.

Alan Kay's idea was (paraphrasing) "It's great that we have message passing between client and server processes, but we really needed to take this idea and run with it, with each piece of content on the Web being some sort of network-hosted process which you communicated with. Then you by-default preserve provenance (who the author is and how it got here) and then you can integrate micropayments into browsers so that you can earn money for watching ads (and target the ads that you want to watch!) and then use that money to browse the content that you want to watch, etc., with by-default the content-creator reaping the micropayments of their content."

But because nobody solved this rather difficult problem, we have freebooting and you have to reload web pages whenever you change their source and re-navigate down to the menu that you care about, and Brendan Eich is now getting flak from people for trying to reinvent advertising on the internet etc...

I've often thought that you could give people a huge leg up on calculus if you could first explain to them the discrete calculus, possibly with a programming language like Haskell. It would look like this:

We're going to start thinking of infinite sequences. A sequence starts with a value, and then there is another value, and so on, and so on. We might number these sequences and then write down rules for them; for example we might write $x_n = (n + 1) ^2$ to denote the sequence of square numbers starting with 1, `map (^2) [1..]`; if you're not familiar with these then we'll write out the first five as:

    squares = 1 : 4 : 9 : 16 : 25 : map (^2) [6..]

I'm going to teach you one list-operator, it's a function which subtracts each number in a sequence from the one that comes before it in that sequence. For the first element, it just subtracts 0, so it doesn't do anything. This is written in Haskell as:

    delta seq = zipWith (-) seq (0:seq)

When we use the above we get:

    Prelude> take 30 (delta squares)
    [1,3,5,7,9,11,13,15,17,19,21,23,25,27,29,31,33,35,37,39,41,43,45,47,49,51,53,55,57,59]

(Here the `take 30` just stops the computer from trying to give us all infinity of the results!)

Interestingly, the difference between square numbers is the set of odd numbers. This is not too hard to understand after you know it -- $(n + 1)^2 = n^2 + 2n + 1$, so of course after you subtract $n^2$ you get $2n + 1$.

Similarly when we start looking at the various counting sequences like [1..] (which again if you don't know Haskell is the same as 1:2:3:4:5:[6..], the infinite sequence of successive integers starting with 1) and [2..] we find:

    Prelude> take 30 (delta [1..])
    [1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1]
    Prelude> take 30 (delta [2..])
    [2,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1]
    Prelude> take 30 (delta [3..])
    [3,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1]

We notice that they're all the same except for that very first element, which basically just tells us the first value. But actually, `delta` has a special property which is that it is invertible: just like you can invert `\x -> x - 3` with `\x -> x + 3`, you can invert this `zipWith (-)` beast with `scanl1 (+)`

    Prelude> let sigma seq = scanl1 (+) seq
    Prelude> take 30 (sigma (delta [3..]))
    [3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32]
    Prelude> take 20 (sigma (delta squares))
    [1,4,9,16,25,36,49,64,81,100,121,144,169,196,225,256,289,324,361,400]

What is this magical beast `sigma`? What is `scanl1`? This is a function which processes a sequence by passing on an "accumulating value", but unlike `foldr` and `foldl` where you get that accumulating value at the end of the sequence, `scanl` gives it to you at each step of the journey, including the first. So like with foldl1, we start with the more general case of foldl or scanl:

    scanl fn val list = val : case list of
        [] -> []
        x : xs -> scanl fn (fn val x) xs

So we always emit a sequence whose next element is `val` and whose follow-up sequence is either empty (if the source sequence is empty) or consists of scanl'ing the rest of the sequence with the same function but with val updated to `fn val x`. Each new element gets combined into the existing value with `fn` and the results are getting steadily emitted as it goes.

Then the "1" in `scanl1` means, just like the "1" in `foldl1`, "read the first value from the first element of the list":

    scanl1 fn list = case list of
        [] -> []
        x : xs -> scanl fn x xs

So when we defined `sigma` as `scanl1 (+)` we just specified this `fn` to be one which adds the two values together. The above recomputation of the squares from the odd numbers actually just works like this:

    1                                =  1
    1 + 3                  =  1 +  5 =  4
    1 + 3 + 5              =  4 +  5 =  9
    1 + 3 + 5 + 7          =  9 +  7 = 16
    1 + 3 + 5 + 7 + 9      = 16 +  9 = 25
    1 + 3 + 5 + 7 + 9 + 11 = 25 + 11 = 36

Notice as the second column here indicates, we don't need to recompute all of these pluses each time: we can just hold onto the last number we've computed, the previous item from the last column, and add that to the new item to get the new value.

I'm asking you to notice the last point because if you study it carefully enough, that we generate each new value by adding the sequence to the last value, you'll start to ask, "wait, is `delta . sigma` also an identity transformation, just like we saw `sigma . delta` is?" And the answer is a resounding yes. This is actually a very common property for inverses, usually after you've proven that `f . g = id` then there's also an argument that `g . f = id`.

So, we've learned that just like `(+)` undoes `(-)` and vice versa, summing up a bunch of terms from some start point to a current place undoes taking differences between nearest-neighbors, and vice versa.

I haven't actually proven either side of this, but it's not too difficult: to see that delta undoes sigma, notice that for n > 0 we have $$

    \sum_{k=0}^{n} x_k  -  \sum_{k=0}^{n-1} x_k  = x_n 

$$ (and the x_0 case is just x_0 - 0 = x_0, so that works too). To see that sigma undoes delta is a little more complicated, but just write out the n'th term to see:$$

    (x_0 - 0) + (x_1 - x_0) + (x_2 - x_1) + \dots + (x_{n-1} - x_{n-2}) + (x_n - x_{n-1}).

$$ Notice that except for the first and the last term, each term contains two parts: a +x_k which will cancel with the next term and a -x_{k-1} which will cancel with the previous term. This is called a "telescoping" series because it's really long but it collapses like a telescope due to perfect cancellations between adjacent terms. The only thing that's left at the end is $(-0) + x_n,$ which of course is just $x_n.$ So `sigma` has indeed undone `delta`.

To follow up, first I would probably define:

    instance Num n => Num [n] where
        (+) = zipWith (+); (*) = zipWith (*); (-) = zipWith (-)
        abs = map abs; negate = map negate; signum = map signum
        fromInteger = repeat . fromInteger

    k !* seq = map (k *) seq

so that we have sequence algebra and we can multiply them by constants; then I would introduce people to basic discrete-calculus results like `delta (f + g) = delta f + delta g` and `delta (k !* f) = k !* delta f` and `delta (f * g) = f * delta g + g * delta f + delta f * delta g`.

Finally comes the big reveal: derivatives, to difference a continuous function, treat that function as if it were a straight line when you zoom in close enough, and to do this we have to divide `delta f` by some $d x$ to make it work; similarly integrals, to be the proper inverses to derivatives, contain a `(dx * )` operation. So if you start to define a grid of size dx over the x's that you care about, u < x < ∞, then each function corresponds to a sequence $f_k = f(x_k) = f(u + k * dx).$ Then `map (/ dx) . delta` generates a version of `delta` whose results converge, but not (in general) on the trivial answer 0; rather it converges on the "instantaneous slope" at x. Meanwhile `map (dx *) . sigma` perfectly undoes this, and calculates the area under a curve from u to x. From this, observe that the product rule gets easier due to these limits and introduce the formal definitions (limits, largest element of a partition going to zero for integrals; simple "h" parameter going to zero for derivatives).

Furthermore, is Namecheap authorized to copy their clients' data by their terms of service? If not, automatic backups may bypass totally-reasonable expectations that other users have. Backups can potentially be a threat vector, for example. There might be many reasons why one of Namecheap's clients might say "you copied this data?! and now I have no control of the environment the backup lives in?!"...

An example would be if some service stored credit card information temporarily while waiting for transactions etc. to process but then purged each record after two weeks later. A compromise of the backups containing, say, weekly snapshots could then contain 90% of a client's ever-stored financial information whereas a compromise of the main site might only reveal a couple percent of them.

Partly. Tsuyoshi Ito's answer on that page is IMO better than the original: `head` mattered at a time when pattern matching didn't exist; but today the only reason to use `head` is to form some sort of pointfree expression operating on lists that you've already filtered to be not-null. That is, you're doing `map (transform . head) . takeWhile (not . null)` or something, or maybe `takeWhile` is replaced with `filter` or so. If you cannot assert that the list is non-null then you have to handle two branches, and this code will generally look clearer if you pull it into a `where` clause and write it with pattern matching rather than with an adjusted `head` followed immediately by an appropriate `maybe` function.

So the terms are coming from the Buddhist tradition, where there is a category of Buddhist denominations usually (a) valuing the Lotus Sutra (as sort of a central uniting point and/or shibboleth); (b) believing in celestial buddhas and bodhisattvas who you venerate and whose assistance you request in life; (c) valuing the idea of us all being "on the path to nirvana" (the "bodhisattva" ideal) even if we are not monks; and (d) representing the diversity of Buddhist denominations as largely being "lesser vehicles" (hinayana) to nirvana, and their own category as being a "greater vehicle" (mahayana) to get there. "Maha-" is a prefix meaning "big," but often also connoting "great, impressive, respectable, noble".

In practical terms a "big-vehicle Prelude" is saying "I want to do something much smarter than the original Prelude and I am willing to replace most of the underlying abstractions in the Prelude to do it," which can sometimes mess with code that has to deal with old-prelude and new-prelude subsystems of code. A "small-vehicle Prelude" is much more "I have a couple extra modules here and there that I want to import, and maybe I want to fix a couple of these operators to a slightly more general definition with a typeclass, but largely I want everything to be the same, hence intercompatible with minimum fuss."

It is; I think it may have been intended as alt-text rather than a caption. It's precisely the sort of description that you'd give to a blind person to describe "here's what this image is, in case you can't see it."

I actually wrote a JS-based encryption container which passes these requirements (and does not even have PasswordSafeV3's key-reuse problem!) for these very reasons about 2 years ago, and one of its example applications in the repository, 'tagaloop', can function as a password storage container:

https://github.com/drostie/nermal

Tagaloop does not time-out or re-authenticate for you, and since I'm not selling the service I can't offer 2FA, but of course if you wanted to build a company out of this stuff it's open-source. In addition nermal makes the deliberate decision to not support "seek" operations, so it does not e.g. store a header field which could then be scanned in advance to index a bunch of concatenated binary strings -- this is not bad for password storage where the metadata outnumbers the data by a factor of 2 or 3 so there's no point, but other applications like storing an encrypted archive of files might suffer.

So if you've never taken an economics class, here's the basic craziness that crucially underpins our modern economy:

There is a central bank sitting in the middle of most modern economies, and it is a bank-for-banks: they either borrow from it or deposit into it. It sets an all-important interest rate: this rate is the rate-of-return that those other banks will compare possible loans to, when saying 'is it worth it to loan to this person, or should I just put my money in the central bank?' -- if you lower this rate, then presumably banks make more loans, stimulating the economy; if you raise this rate, then presumably banks make fewer, stifling the economy. The hope is not that different from storing up food in years of plenty in order to weather years of famine; during a recession you lower the interest rate, but afterwards in the upswing you raise it again.

When you deposit money in a bank, it is not required to hold onto all of it and keep it safe. Instead it usually takes a chunk of that money and promises it as a loan to someone else, who will hopefully in the end pay them more in interest than they're paying you, enough more that the difference is better than just shoving the money in the central bank.

When it makes this loan, that comes in the form of saying "I still owe you $x, and now I also owe this other person $y." So the true money stored by the bank is still only $x, but the money now in circulation in the economy -- in the sense that there's the illusion of people having it, which is the only sense that money exists anyway -- is $x + $y. If that other person needs to immediately cash out a quantity of dollar bills, then $y < $x, so the bank can comfortably do that. If you both try to cash out at the same time, there is an obvious problem (the bank has failed!), but remember that this is a sort of insurance scheme of "divide that risk among lots of people and trust that their decisions follow a binomial distribution" -- in reality there is some proportion p of a lot of individuals who collectively need to withdraw in order for the bank to fail. Furthermore when this happens the federal government may declare the bank "too big to fail" and funnel tax money into it, to keep it going.

This PDF is arguing that the above explanation is precise in ways that many economics textbooks are loose; notice that the extra value has nothing, for example, to do with your putting the money into the bank. Why? Because suppose you spent that on a new car: your car dealership that you're buying from has an account with this bank (or some other bank; the economy collectively includes all of them after all) and they take this amount of money and put it in the bank! So that $x is getting deposited somewhere, assuming that you do not take it out of circulation yourself (in which case, it doesn't help mediate your purchasing of goods and services, so is it really money?). Modern textbooks omit this and refer instead to the banks as a "money multiplier" where "there is $100 deposited at first, the bank saves 20% of its deposits, it loans out $80 which gets immediately spent hence re-deposited in some similar bank, so that bank saves $16 and loans out $64 which similarly gets re-deposited, saving $13 and loaning out $51, at this point the economy has nominally $100 + $80 + $64 + $51 = $295, so we've multiplied the amount of money deposited into the economy by a factor of ~3x, and if you continue the progression out to infinity you find that this multiplier approaches 1/(20%) = 1/0.2 = 5." The problem with this thinking is that there's nobody in the economy who comes into this system at that crucial step 0 -- you got your money from the bank account of your employer or from a loan from some other bank. So, from your perspective, there's kind of nothing to multiply.

If that makes you feel breathlessly like everything is an illusion resting on an insane Ponzi scheme, that's mostly correct and you should feel all of that. You can spend hours thinking about "what is money, I mean really?" and if you're a founder-mentality you might even spend years on this wondering if there's an opportunity for disruption at an epic scale somewhere therein.

Probably the best way to understand money is still the engineer's, "I do something that someone finds useful, so they give me points in this augmented-reality game where the rules force them to give those points out of their own personal stash. As long as we collectively agree that useful things are happening, those points have some form of meaning as a way to symbolically trade hypothetical goods and services. When we lose this collective confidence then the points will no longer matter to us."

This is hard to summarize into a TLDR, but I'll try. The general summary: an anthropologist gets mired in a village during a timeframe where there is nothing to do but drink beer and talk; she therefore tries to tell the story of Hamlet. This is complicated by the fact that their culture has a different social structure, and a different model of the supernatural. In their model of the supernatural there are just witches, who are always male, who can create purely-visual hallucinations (called "omens", they cannot "walk" or "speak"), animate dead corpses ("zombies"), afflict people with temporary insanity ("madness"), and drown people. (Yes, nobody drowns unless cursed to do so by a witch.) The rest of this comment is a synopsis of the Hamlet variant they create, arranged into play order.

Much like we view technology, for these people witchcraft is not necessarily negative but can also be done for the good of others. King Hamlet (Hamlet's dead father) thus becomes the Omen, a (veridical and therefore good!) vision sent by some witch-elder who understood the truth of his death at the hands of his brother Claudius, but was afraid of Claudius' new power. (There is a brief confusion because in the original story he walks and talks, suggesting a zombie, but they settle on him being an omen and the original story was simply wrong about him walking or talking.) Claudius's two big sins are his sin of fratricide in the past and later a sin of afflicting Hamlet with madness. Notably when he marries Hamlet's mom the tribe basically yawns "yeah, and?" -- this is so obviously the right thing to do that they don't make any further comment; of course your brother marries your wife if you die, for who else is going to support her?

The tribe is okay with the nameless elder sending the Omen to soldiers and then to Horatio, and because Horatio is a "scholar" he is therefore automatically a witch, so it makes some sense that he can interact with the Omen. However the tribe is surprised that he does not refer the problem to an elder of the tribe as they need someone more wise to the dangers of witchcraft, instead referring it straight to Hamlet. But they go along with this, Hamlet sees the Omen which tells him that his father died from poisoning. However Hamlet is wise enough to know that false omens exist from evil witches, so he resolves to determine the truth of the Omen.

Now either events have to be reordered or somewhere before the storytelling, chief Claudius bewitches Hamlet with madness. Certainly he is mad when he interacts with his beloved Ophelia, and then he talks with his schoolmates and comes up with the idea for the storyteller friend they've brought with them to do a storytelling for Claudius which will determine the truth of the Omen. In response to this story, chief Claudius in his outrage and fear apparently continues to bewitch Hamlet with madness, but also sends Hamlet's mother to find out what he knows -- and of course he sends Polonius the elder (still Ophelia's father) to listen in, not trusting her to be totally honest with him. Hamlet's criminal audacity in scolding his mother is chalked up to madness. Then Polonius stirs and Hamlet claims that he sees a rat, but when he says "a rat?!" it is understood as a hunter's ritual warning to potential human victims standing in the way of the arrow, kind of like a demolitioner's "fire in the hole!", where if you hear a response you should almost certainly abort whatever you're doing. To save Polonius's reputation the narrator therefore explains that he responds "It's Polonius!" after Hamlet's "It's a rat!" but Hamlet kills him anyway because he's been afflicted with madness and thinks it's his chance to kill Claudius.

With Polonius gone you'll remember that his daughter Ophelia drowns. But since drowning requires witchcraft, the explanation given is that this was a treacherous act by Laertes (Polonius's son, Ophelia's brother), who was of course sent off to France where he boozed and gambled away his money irresponsibly. The explanation was that when he came back home, broke and in massive debt, he saw that his dad couldn't give him more money because he's dead, and he couldn't sell his sister for a handsome bride price because she's being actively courted by a chief's son and nobody wants to potentially piss off a future chief. So Laertes did the only thing he could do to raise a lot of money on short notice, afflicting her with the curse of drowning so as to sell her innocent body to malevolent witches to zombify as they willed. This is why he jumps into Ophelia's grave (to get her body out for the selling) and Hamlet jumps in afterwards because he senses the foul witchcraft afoot. Laertes therefore is pissed at Hamlet for robbing him of any benefit of killing his sister.

Claudius sees that Laertes is powerful enough in witchcraft to kill his own sister, and that is why he sets up this duel where both Hamlet and Laertes will kill each other, one by sword, the other by the poisoned cup of victory beer. The finale remains otherwise untouched and everyone dies, although again Hamlet's presumably killing Claudius out of madness instilled by Claudius, and we're never told how they reacted to a rival chief (Fortinbras) taking over everything afterwards.

We appear to be slashdotting the server; here's some cached copies:

Just text (loads instantly):

http://webcache.googleusercontent.com/search?q=cache:Jr34hZX...

Images etc. loaded from the site (seems to work, albeit slowly):

http://webcache.googleusercontent.com/search?q=cache:Jr34hZX...

Right. I was initially credulous to the idea that there is data in the system after the present, thinking, "Holy crap! That means that some other department in Facebook consists of chatbots which have randomly woven themselves into peoples' lives and have advance-scheduled chatter!"

But once it was like, "hey, we're predicting the outcome of a sports game before it happened based on this" then it's like "ooh, this is a cool fake story which just took a turn towards the supernatural, I get it..."