sicp-enjoyer

11 ms·

1.
by sicp-enjoyer 4y ago
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 commen
2.
by sicp-enjoyer 4y ago
Your comment cautioned against marriage for its "cost". Now you are talking about lifestyle preferences.
3.
by sicp-enjoyer 4y ago
> 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
4.
by sicp-enjoyer 4y ago
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
5.
by sicp-enjoyer 4y ago
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.
6.
by sicp-enjoyer 4y ago
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 term
7.
by sicp-enjoyer 4y ago
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.
8.
by sicp-enjoyer 4y ago
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...
9.
by sicp-enjoyer 4y ago
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. s
10.
by sicp-enjoyer 4y ago
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.
11.
by sicp-enjoyer 4y ago
> 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 compari
12.
by sicp-enjoyer 4y ago
Do you know about std::unique? Generally sets are a poor tool for removing duplicates.
13.
by sicp-enjoyer 4y ago
Can many hashes be combined quickly in a uniform way? This is another benefit of `<`, it composes.
14.
by sicp-enjoyer 4y ago
You need both access patterns (otherwise you do a double-lookup to insert a default value) and C++ already provides both.
15.
by sicp-enjoyer 4y ago
> 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
16.
by sicp-enjoyer 4y ago
My goto build system is: - make - Google's closure compiler (standalone Jar) - imagemagick It builds fast and never goes out of date.
17.
by sicp-enjoyer 4y ago
Did windows 3.1 even have memory separation? So a bad program could crash the whole system?
18.
by sicp-enjoyer 4y ago
So you would say programs today are equally efficient and more stable, just have more features?
19.
by sicp-enjoyer 4y ago
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
20.
by sicp-enjoyer 4y ago
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 scalin
21.
by sicp-enjoyer 4y ago
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 combin
22.
by sicp-enjoyer 4y ago
And that 1 share still outperformed the equivalent amount of S&P.
23.
by sicp-enjoyer 4y ago
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.
24.
by sicp-enjoyer 4y ago
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.
25.
by sicp-enjoyer 4y ago
You could see they had free cash flow.
26.
by sicp-enjoyer 4y ago
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.
27.
by sicp-enjoyer 4y ago
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.
28.
by sicp-enjoyer 4y ago
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
29.
by sicp-enjoyer 4y ago
Why should this be faster than a local postgres instance with no traffic?
30.
by sicp-enjoyer 4y ago
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.

More ›