sicp-enjoyer

Now you're talking about financial burden again. I don't wish the situation you are describing on anyone, and I am sympathetic to making choices to avoid that happening. I don't think that is inconsistent with my other comments.

Just to add, here are a few other things that also limit your day to day freedom and add some risk of legal nightmares:

- operating a business

- owning a home or other building

- running for political office

- raising a child

- using a professional license (medical, law, civil engineer, etc)

Your comment cautioned against marriage for its "cost". Now you are talking about lifestyle preferences.

> the failure rate is too high

The rate dramatically changes with demographic, for example many of those were married young and did not complete education.

> who you pick to marry

The quote doesn't say whether :) Married men also tend to make more money and work for longer periods of time. There is a cynical view of whether that's good or not, but 40-50 year old single men don't seem to be a particularly successful demographic.

I have noticed that Phd holders usually advise buckling down and dealing with whatever abuse or bureaucratic nightmares are required to finish.

I think I agree with 1 year out, but I would be surprised if this hasn't been going on for longer.

You are correct. Sorry if I am being pedantic. I was also trying to suggest it could be a b-tree but others have pointed out that it doesn't quite fit the spec.

This person is already putting sets inside vectors, so I don't think they are worried about storage.

But yes, you either need to stop occasionally and remove the duplicates or use a set, if the storage is prohibitive.

Otherwise in terms of performance, sorting and unique is much faster than inserting one element at a time in a set.

Yes, and eventually you start computing another hash of the buffer of the concatenated members. I'm not saying it can't be done, I'm just comparing it with recursive memberwise comparison.

If you do that 10 times for all members of your struct, do you get good uniformly distributed keys?

This post doesn't think so: https://stackoverflow.com/questions/5889238/why-is-xor-the-d...

This is quite unfortunate. The way to get a really good hash table is by enforcing a bunch of simplifying assumptions (power of 2 sizes, sentinel values, etc). But the C++ committee has to make the "one true table" for everyone.

std::map actually seems to fit this role better. It works reasonable well for many workloads and types without tuning a bunch of parameters.

All of <algorithm> uses ordering operators as well. If you have a "regular" type with proper comparison and assignment operators, it works for everything, container keys, sorting, etc, etc.

> so hash map will generally be faster in this regard.

Complexity is not a measure of runtime. The performance drawbacks for std::map have to do with cache, not O(log) vs O(1). log(billion) is 30. And that's exactly how many comparisons you have to do, not a constant multiple of that.

With an open addressing hash table, who knows how many steps you will need to find an element. It's even more questionable if it does linked list chaining.

> binary search tree.

It's usually a red black tree and maybe could be a b-tree? "Search tree" is accurate.

Do you know about std::unique? Generally sets are a poor tool for removing duplicates.

Can many hashes be combined quickly in a uniform way? This is another benefit of `<`, it composes.

You need both access patterns (otherwise you do a double-lookup to insert a default value) and C++ already provides both.

> developer time is a significantly more expensive resource than compute

This also presupposes that making a fast program is a lot more work. However poor performance is usually due to negligence rather than a lack of optimization effort. All you need to write reasonably fast code by default (without micro-optimizing) is:

1. a good knowledge of available algorithms 2. a good understanding of the problem

1. Is a one-time investment on the programmers part that benefits all future programs they write. There is no marginal cost to being familiar with what's available in <algorithm>. 2. Has a marginal cost, but it's probably a time saver anyway. Measure once, cut twice.

My goto build system is:

- make

- Google's closure compiler (standalone Jar)

- imagemagick

It builds fast and never goes out of date.

Did windows 3.1 even have memory separation? So a bad program could crash the whole system?

So you would say programs today are equally efficient and more stable, just have more features?

The quantum mechanics is a cop out, since everything observable at the scale of our lives is compatible with a determinism. Only experiments at microscopic level can falsify it.

> The point about systemic risks is they don’t go away just because they haven’t happened yet.

I agree. But observing a state of instability or unpredictability is different than saying "X economic event a 10% chance of happening".

Usually web applications fork and runs processes to do the computational work you describe (ffmpeg, imagemagick, git, etc). These are usually written in variety of fast(er) languages like C, C++, Java, etc. Plus now you get multicore scaling for free.

I agree that risk is about lack of information. So I don't think PG could have been right. He has his view of the market, and other people have theirs. Turns out, he was missing a lot of information.

I guess I can see some crazy combination of physical objects colliding and nobody being able to predict where they land, I'm just not sure thats the right model for valuation of an asset.

> tail risk

Sorry if I introduced that. I just meant that it's occurrence far outside of the regular distribution.

And that 1 share still outperformed the equivalent amount of S&P.

Yes, I am doubting that big events in the economy function like dice rolls. When you say it's a tail risk, you're talking as if that outcome is actually realizable.

I don't see how that's the case. If he had 95% of portfolio in S&P and the FB he bought was 5%, he still did better in dollar terms than 100% S&P.

You could see they had free cash flow.

Obviously one way to hedge risk is to use smaller amounts. His gains on that portion are still greater than if it was parked 100% in VTSAX.

In FTX case it had already happened when the media reported. In fact, prior to the scandal most of the media about FTX was positive.

In your view, in what sense are alternative outcomes are actually statistically probably. It sounds to me like you're saying:

when the tweet was made the universe was about to make a dice roll. There was a probability that bitcoin went down and a probability that bitcoin went to the current price, and the universe rolled and happened to land on the current state, but the others could also have happened if luck had gone another way?

Why should this be faster than a local postgres instance with no traffic?

I completely agree, but I think that "rich mythology" you refer to is fueled by the public also believing in it to a great extent.