HN user

mb7733

910 karma
Posts0
Comments335
View on HN
No posts found.

Maybe I was unclear. The part that I meant a constructivist would disagree was the subjective part: "This kind of proof (existence of a counterexample) provides more insight into the problem than simply finding a counterexample."

I find it hard to believe that a constructivist would agree that across the board, proof of existence of X is more interesting than a construction of X. Isn't that the point!?

To roughly repeat myself from a sibling comment: I may have been unclear. I didn't claim that the only way to disprove something in a constructive system is to produce a counterexample.

The part that I was referring to was the last statement from the OP: that "a proof of existence of a counterexample necessarily provides more insight than a counterexample". I can't imagine a constructivist would agree with that in general.

Are you thinking of proof by contradiction, which is rejected by constructionism?

[Dis]proof by counterexample is the most straightforward way to show a statement to be false. What better way is there to disprove a general statement like 'all x are y' than finding an 'x' that isn't 'y'?

It's even worse than implicit casting, if the value can't be cast to the the column's type, it's just inserted without casting. Eg. into an integer column, '10' -> 10 and '1O' -> '1O'

An intuitive motivation for the solution in the article (2n choose n). For an n*n grid you have to you will take 2n steps, n "over" and n "down". All that matters is the order of the steps. So if you think of there being 2n "slots", you have to pick n to be "over", and the rest are forced to be "down". So it's n choose 2n indeed.

You can also think of it another way, without using the formula combinations, and only the fact that there are n! permutations of n objects. We can think of this a permutation of 2n items, made up of two groups of n identical items each. Using (2n!) will overcount, due to the fact that each of the "over" steps are identical, and similarly for the "down" group. We have cut down our answer by dividing out all of the repeated sequences. There will be n! redundancies for all the ways we can permute the "over" group and, the same for the "down" group. So this results in (2n!) / (n! * n!), which is exactly equal to 2n choose n. See [1] which explains permutations with repetion this in general. [Note: We pretty much re-derived the formula for combinations!]

[1] https://brilliant.org/wiki/permutations-with-repetition/

Is it a pint? 4 months ago

Preferences vary on both sides of the Atlantic. Another comment on this post complains that Americans pour beer wrong because they _do_ pour with a head.

Also in the US (probably due to lack of training and the customer too embarrassed to complaining) tend not to fill it the brim (and so not even 16''). I've seen 2-3 inch heads and asked them to top it up. They look at me as if I've just insulted George Washington

Overall I agree with the approach, but just wondering, why do the first point if you are already doing the last two?

* Use the issue id at the start of every commit message for that issue

* Use a single branch per issue, whose name also starts with the issue id

* Use a single PR to merge that branch and close the issue

To me the noise at the start of every message is unnecessary, and given a lot of interfaces only display 80 chars of the message by default, it's not negligible.

programmers who don't care about code quality and thus brutally reject code that is not of exceptional quality.

Is there a typo here? If they don't care about code why would they reject code based on quality?

Uncrossy 6 months ago

Really fun. The undo/redo functionality is much appreciated.

Yeah and (1) the codegen produces massive headers that slow compilation of anything that touches them (2) the generated classes are really awkward to use. Not a big fan of the experience of protobuffer generated code in a large C++ code base.

It's lead to a huge layer of adapters and native c++ classes equivalent to the protobuffers classes to try and mitigate these issues.

In a real-indexed vector, that notion doesn't apply. It's "infinity plus one" all the way down: whatever real value you pick to start with, x, there's no delta small enough to add to it such that there's no number between x and x+d.

Just to clarify, uncountability isn't necessary for this. It's true for the rational numbers too, which are countable.

Interesting! On the guitar when alternate tunings are used, the pitches are written as they sound.

I wonder if maybe the difference is due to the fact that alternate fingerings are very common for guitar (because of having more strings spaced closer together). So notating pitches assuming a specific fingering doesn't make sense.

Plus I don't think the mapping from the staff to muscle memory for guitar is nearly as strong because we have frets.

That's not a good analogy. Mostly shows you don't understand the problem being solved.

It's not "faking" an analog system within a digital system. (If anything, that's what a full digital DJ set up is.) It's an adapter between the two.

As such a purist, would you prefer that digital music is never used? Or that digital music must only be used with digital controller? In that case DJs that use both types of music have to lug around two separate controllers.