mb7733

It is off by default.

Green lights... are synchronized to avoid collisions.

The metaphor backfires because if everyone runs red lights they will collide with one another, as well as with those going through green lights.

It wasn't abelist but I don't understand the analogy with schizophrenia.

That's interesting, because I've noticed the exact opposite between VSCode and Sublime. What version of sublime are you using?

He was working in Seattle, not at Tile.

1-2 loads of laundry every day for 4 people? How small is your washing machine?

What is the point of that comparison?

B to F is a fifth; that interval is called a diminished fifth (one semitone less than a perfect fifth like B to F#).

As someone who has had to move often for work and school, renting has been pretty good for me and my partner. What would the alternative be?

The schedule / lifestyle of an academic is almost opposite to the 9-5 'just a job' the OP is looking for.

> I think we should start pressurise politicians so that they force companies to pay royalties to open source contributors based on % of revenue.

...If someone makes something and gives it out for free, the government can't retroactively force users to pay for it. It's up to the creator to choose a different lisence.

Sure, but data.table also fits those criteria.

What part of Google Photos is discontinued?

Yeah the storage size was a real clincher for me, as much as I appreciate a SQL database.

Re: concurrent reading and writing, for my use case the files are immutable so that isn't a concern. But I agree, I don't think pure parquet is a good fit there.

In common usage does OLAP automatically imply data that is too large for a single node to handle? I'm wondering if a lot of OLAP workloads couldn't be handled with some parquet files (or some other column based storage)?

I realize parquet is used by the hadoop/spark ecosystem, but do you really need those systems? I'm thinking that a lot of companies reach for a hadoop cluster when some parquet files in a regular for system would be much simpler. I've done things like this and in my experience it works quite well. But only for personal projects.

I think you're missing the point of the article (and the material you included). It's not that the method of inference is that interesting, its the fact that the game is able to make use of that inference at all. Every thing else about the algorithm is interesting: rollback, reconciliation, (de)synchronization, choice of delay, the the separation of game logic from rest of the game loop, etc. As the article details, it's extremely complex to do this right, to the point where many games just don't bother trying.

Think about the time scale under which this prediction is made: 60Hz. Even the best players do not change input at nearly that rate. So it's clear that the current value is going to be the best estimate for the next value. That realization doesn't even begin to solve the problem though!

I'm missing something here. Why would hammer use be declining?

You think that young people don't use hammers?

I'm not clear on the point here. You can make an application that handles arbitrary SQLite files, (for example: the SQLite shell, or a GUI database broswer), or you can make an application that only uses SQLite files with certain content/schema. Does this mean that SQLite does or does not define a file format?

If not, what do you call the specification of how data is stored in a SQLite file besides a 'file format'?

I'm genuinely curious what you mean by this. Of course SQLite imposes a file format... That format is a SQLite database

I think the pedestrian experience of 4-way stops is pretty great - you always get right of way.

Pedestrian experience is probably the one downside of roundabouts.

As an avid mountain biker, I can tell you that the high-end for mountain bikes is definitely not titanium, it's carbon fibre. Titanium mountain bikes are rare, probably even more than road bikes.

Every major brand uses carbon fiber in their high end bikes.

I think what you're missing is that a big part of the design of traditional music notation is that it is intended to be read easily and efficiently, even sight-read. The musician reading the score knows the intervals that apply in the given key, down to muscle memory. The fact that a note lies outside the key is important, and that is why an accidental is marked explicitly.

Likewise, when a musician sees a run of adjacent notes without accidentals, they immediately know what to play. They don't need to inspect each one in turn to determine how many semitones it lies from the previous note. Likewise, when a composer wants to write such a run, they can just draw some black dots in a row. They don't need to squint at a grid and select the correct rows each time.

To sum up, traditional notation is uses a form of compression that makes reading and writing diatonic music easier.

Taking this even farther, some systems of music notation compress things even further and don't explicitly list all of the notes to be played. For example: figured bass, basso continuo, or even just chords that accompany lyrics. In fact, even regular sheet music doesn't usually precisely represent of duration of all of the notes. Some notes are sustained and bleed into others, some are meant to be played strictly in time. Human interpretation is an important part of the process.

On the other hand, the piano roll is a MIDI editor. It is a great way to tell a computer exactly what to play, but it is not easy to read quickly and it is impractical to print or write by hand. Both forms of notation have advantages and disadvantages but it seems to me you haven't spent enough time with the standard notation to fully appreciate its advantages. In other words, the piano roll notation might be your blub language for music. [1]

[1] https://wiki.c2.com/?BlubParadox

On a piano roll the black and white keys are equally spaced. Two adjacent rows are always a semitone apart.

How are accidentals obfuscated on a traditional score? They are explicitly marked. It's on a piano roll that they would be easy to miss -- they appear the same as any other note.

Similarly, key changes are explicit in sheet music but hard to see on a piano roll without careful inspection.

Just because something is easy to measure doesn't mean it's a valuable metric. You can make the same argument about LOC.

As someone who used to log lifting in plain text files (copied from a notebook) I think this is a really good idea.

To avoid all of the comments from people asking about GPS tracking, I think you should make it clear that it's primarily for strength training. The format is clearly oriented around that.

An addition that could make it more useful for recording cardio workouts like swimming/track/indoor cycling would be the concept of rest intervals. For example, it's common to prescribe a part of a swimming workout in a format like this:

  4 x 100 at 1:20

Meaning you have 1:20 to complete each 100m rep, where any extra time is rest. You could also add extra fields for recording the actual time taken to complete rach rep. E.g:

  #Unit: m
  #TimeFormat: M:S
  
  4r 100 @1:20
    1:05, 1:07, 1:11, 1:06

No, tying knots isn't an application of knot theory. To learn about some applications of knot theory, you could read the textbook in the OP.

I think learning and tying knots is cool too, but just a heads up, the mathematical knot theory discussed in the OP is not related to that. It's a branch of topology that studies the possible shapes and transformations of closed curves in 3-space (without self intersection).

It's not concerned with practical properties of knots tied with rope, like strength, stability, ease of use, etc.