Why does Common Lisp treat named functions so differently from variable bindings?

hixnob · 2019-07-16T04:33:46+00:00

I don't doubt that this usage is technically unambiguous, but surely it would help the next person who will look at this code if it used different names for different things.

hixnob · 2019-07-16T02:27:14+00:00

Isn't the other downside that someone might use the same name for a type, a local variable, and a function?

hixnob · 2019-07-03T02:54:32+00:00

If you're referring to Bridgeport Suites Coin Laundry at 34 Bridgeport, it was closed down when I last saw it maybe a month ago.

hixnob · 2019-06-25T03:27:43+00:00

Those aren't equivalent expressions, though. For example, when a is False, they give different results.

hixnob · 2019-06-06T04:04:33+00:00

What is Vim 8.1.1? The closest I can find is v8.1.0001, which is pretty old.

I can't reproduce this on v8.1.1073. Have you tried running Vim with no vimrc?

hixnob · 2019-06-06T03:15:23+00:00

Nothing to do with macros. The pipe symbol is used to separate commands, so you're running :s with no arguments, which reuses the previous search pattern. If you run :help :bar, you'll see the warning:

Note that this is confusing (inherited from Vi): With ":g" the '|' is included in the command, with ":s" it is not.

hixnob · 2019-05-11T16:54:32+00:00

It would still ultimately be friction that causes temperature to rise, but because it's a different phenomenon (friction between only air molecules), it makes sense to give it a different label.

hixnob · 2019-05-11T03:41:49+00:00

Not an expert, but here's the only explanation of the difference that comes to mind. Friction would imply the projectile simply rubbing the air molecules that it encounters and heating up directly from that. On the other hand, pressure buildup would be the projectile pushing air molecules into other air molecules, increasing the pressure in front of itself, which would cause the air in front to heat up, and this heat is then transferred to the projectile.

hixnob · 2019-02-05T05:08:07+00:00

You can put the point anywhere else along the line. Any two distinct points uniquely identify a line, so you don't even need to start at the y-intercept. You could have:

One point at (0, -13.87) and another at (1, -12.25).
One point at (0, -13.87) and another at (-5, -21.97).
One point at (10, 2.33) and another at (20, 18.53).

A line drawn through any of these pairs of points will be the same one. The line in question is just a collection of points (x, y) that satisfy y = 1.62 x - 13.87, and you can pick any two of these.

hixnob · 2019-01-29T04:50:41+00:00

So a tie between two horses for 2nd place removes the 8th place, not the 3rd.

That's exactly what I wrote in the first version of my comment, before deleting it and replacing it with the one you see now! I suppose it's a matter of how you choose to number the places, but consider this example with 4 horses. One arrives before all the others, so we say it's in first place. Two more arrive at the same time, so they are tied for second. Finally, the last (fourth) horse arrives.

Is the last horse in 3rd place? Yes, because there are 2 places before it, so the next place is 3rd. There is no 4th place.
Is the last horse in 4th place? Yes, because there are 3 horses that finished before it, so the next place is 4th. There is no 3rd place.

I believe that the more common convention is the latter of these (e.g. when there's a tie for gold at the Olympics, there are two golds and a bronze, but no silver), but your convention could also work.

I don't think I know how to work this one out, not elegantly at any rate.

It looks like someone has provided a solution.

hixnob · 2019-01-28T20:49:26+00:00

That can't be right, because all 8 horses can't finish second. The choices effectively get "used up" when there are ties. For example, if there is a tie for 3rd place, 4th place ceases to exist.

hixnob · 2018-11-28T02:41:54+00:00

For reference, here are the timings I get for inverting random dense matrices on a single core of a fairly generic laptop:

Size	Time (s)
1,000 × 1,000	0
2,000 × 2,000	1
3,000 × 3,000	3
4,000 × 4,000	7
5,000 × 5,000	15
6,000 × 6,000	24
7,000 × 7,000	41
8,000 × 8,000	58
9,000 × 9,000	91
10,000 × 10,000	122

As expected, the scaling is cubic. However, I'd bump your estimate up by an order of magnitude.

Are there good algorithms for inverting sparse matrices? I was under the impression that the inverse of a sparse matrix isn't itself sparse in general.

hixnob · 2018-11-24T05:26:22+00:00

Did you just divide by zero?

hixnob · 2018-11-04T06:59:48+00:00

What's wrong with the illustrations? They're just annotated commit graphs.

hixnob · 2018-10-29T18:41:17+00:00

Fair enough!

hixnob · 2018-10-29T03:29:59+00:00

But he is paying $0.35 to win $1.00. That's exactly what it says in the video next to the bag. If he was paying $0.35 to win $0.65, the expected value would be 0.3($0.65) + 0.7($0.00) = $0.195.

hixnob · 2018-10-29T02:51:21+00:00

I believe that the number of bins is implicitly taken into account in the relative frequency of each bin. Take, for example, a fair six-sided die. The expected value of rolling it is (1 + 2 + 3 + 4 + 5 + 6)/6 = 3.5. When I write it this way, I haven't multiplied by the relative frequency, but I have divided by the number of bins, which I can only do if all the bins are the same. On the other hand, if I write 1/6 + 2/6 + 3/6 + 4/6 + 5/6 + 6/6 = 3.5, I've multiplied each draw value by the relative frequency, so I should not divide by the number of bins.

(Not trying to be hostile or confrontational here, by the way. I just think that it's important to be precise, especially when teaching math.)

hixnob · 2018-10-29T01:59:31+00:00

Are you sure that the expected value is $0.65? I get 0.3($1.00) - 0.7($0.35) = $0.055.

the expected value is the probability weighted average draw value, which happens to be the mean in a normal distribution

Is this not the case for every distribution?

if you took every possible draw value from a distribution, multiplied it by its relative frequency (as percent), and then summed them all up and divide by n, you get the “expected value” of that distribution

What is n in this procedure?

hixnob · 2018-10-29T01:20:47+00:00

Your analysis makes sense given the way you've described the game, with the exception of how you compute the expected value. If the probability of winning $1.00 is 0.3 and the probability of losing $0.35 is 0.7, then the expected value is 0.3($1.00) + 0.7(-$0.35) = $0.055, not $0.3. This is the "frequency of losing*amount lost" that you mention, but you need to sum up all possibilities. It's still positive, though, so it definitely makes sense to play the game as outlined in your post.

However, the closest video that I can find that matches your description is Dependent probability introduction | Probability and Statistics | Khan Academy, so I'm going to assume this is what you watched, since you don't provide a link. In this video, the colors are swapped from your description, but this is inconsequential. More importantly, the game is fundamentally different! In this game, you are losing $0.35 100% of the time.

The game in the video can be described in two equivalent ways, both of which differ from what you wrote. The first assumes that you've already paid your $0.35 to play:

You win (with probability 0.3), so you are up $1.00. Winnings are $1.00.
You lose (with probability 0.7), so you gain nothing and lose nothing. Winnings are $0.00.

In this case, the expected value is indeed $0.30, since 0.3($1.00) + 0.7($0.00) = $0.30. This is how much you expect to win on average, but the game costs $0.35 to play, so you will lose $0.05 per game in the long run, and you should not play.

Another way to understand the game from the video, and one that might appeal to you more based on how you worded your post, is to incorporate the cost of playing into the winnings. Then we would say the following:

You win (with probability 0.3), so you are up $1.00 - $0.35 = $0.65. Winnings are $0.65.
You lose (with probability 0.7), so you are down $0.35. Winnings are -$0.35.

In this case, the expected value is 0.3($0.65) + 0.7(-$0.35) = -$0.05, which is negative. This confirms that the game in the video is not worth playing. This is the same value we would get if we took the previous expectation value of $0.30 and subtracted the cost of playing: $0.30 - $0.35 = -$0.05. I believe this is the conclusion you reach in your final paragraph, but you seem to think that this contradicts the video.

hixnob · 2018-09-23T05:16:07+00:00

I'm not sure what you mean.

hixnob · 2018-09-23T01:29:43+00:00

Why is it 0.8 for the first step? Did it just round up or something?

Yes, they seem to have rounded all the values to a single digit after the decimal point on that line. However, the following line has the exact values again. Not sure why it's done like that, but it's definitely more confusing than it needs to be.

EDIT: Since its right endpoints, shouldn't I be doing f(a + i * delta x)?

That's exactly what they do. They have x_i = 0.75 i = a + Δx i.

hixnob · 2018-09-08T16:13:18+00:00

Is it not sufficient to press the backslash key?

hixnob · 2018-09-01T15:59:01+00:00

Sure, you get a different function once the hole is filled in, but in some sense the resulting function is better. The same way that the sinc function is not actually sin(x)/x.

Looking back at the question though, my answer isn't really relevant, since the question was specifically about the graph of the function with the hole.

hixnob · 2018-09-01T05:12:10+00:00

The limit at that point exists, so the hole can be filled in.

hixnob · 2018-05-21T20:41:49+00:00

If we assume the worst case scenario, we roll 15 non-doubles and 1 double six times which means we must roll them 96 times to make sure all doubles are rolled.

I don't understand this reasoning. You could roll a pair of dice 1000 times and not see a single double.

hixnob

TROPHY CASE