vertere

I'm confused about their definition of RL.

> ... SFT is a subset of RL.

> The first thing to note about traditional SFT is that the responses in the examples are typically human written. ... But it is also possible to build the dataset using responses from the model we’re about to train. ... This is called Rejection Sampling.

I can see why someone might say there's overlap between RL and SFT (or semi-supervised FT), but how is "traditional" SFT considered RL? What is not RL then? Are they saying all supervised learning is a subset of RL, or only if it's fine tuning?

You seem to have a very narrow view of what is a relevant or a valid comment. Just because a counterargument doesn't completely refute the original comment, or "introduces" new concepts, doesn't make it irrelevant or "misdirection".

Someone compared treatment of X 20 years ago to treatment of Y today -- seems pretty natural to bring up treatment of X more recently. You can't just say "the original comment didn't mention it so you can't mention it either".

I don't see how your accusations of bad faith are warranted.

Indentation of comments also means something. GP was not responding to the neuroscience comment.

It's still pretty meaningless unless you have some idea what the previous profit was (which the average headline reader probably doesn't). 95% of last quarter's profit could be a trivial amount or a huge amount. If last quarter's profit was $100 and this quarter's was $5, describing it as a "plunge" is misleading as it hasn't really changed.

Maybe they don't believe there are no elephants in Germany.

If someone came up to you on the street and said "You are an elephant. Are you an elephant?" you wouldn't say "yes".

I agree that treating production vs non-production as a dichotomy can be problematic, but that doesn't mean some systems aren't more sensitive than others.

Also security is not one dimensional. A system's required level of confidentiality might be very different from its required level of availability. Being explicit about this might be better than trying to lump different requirements into a "production" label.

> is best avoided, phobia or no.

Strongly agree. I briefly developed a morbid fascination a few years ago, which then developed into a rather unpleasant sort of phobia/aversion.

> It's really not a lot to grok, at least by most other language's standards.

Yes, but people have been attracted to Python largely because it's not like a lot of other languages. It is/was concise, simple, dynamic and fairly easy to learn. I think some of the new features, even if they don't make it a worse language, make it less "Pythonic", and so tend to undermine its comparative advantage. For experienced programmers the new features might not seem complicated, but python is used by a lot of people who are not in that category, including people for whom software development isn't their primary job.

Indeed. Any suggestion that economists (neo-classical or otherwise) don't care enough about relative price changes is utterly ridiculous. They just don't call them inflation.

I can't see where they criticize the term "black box". So, ironically, this is just a complaint that they used some terminology you don't approve of.

Standard notation like sigma for sum isn't really a descriptiveness issue, everyone knows what that means. Not dissimilar to programming languages using `+` instead of `plus()`. Non-standard variables are where more descriptive names would be useful, though the tendency to use single letter (greek or otherwise) names is reinforced partly by writing `ab` for `a*b`.

Also much of math notation is effectively 2d. Programming langs use linear text. Latex syntax is sometimes used for a linear-text representation (even if it's not intended to be rendered), but it reduces readability.

And people still write equations by hand a lot, because the notation is more efficient than typing it out.

It seems like broader adoption of Markdown (or similar lightweight markup) would greatly help with broader adoption of git.

Many software projects have their documentation in Git. That is partly to have the documentation sitting alongside the code, but I would argue it's also because Git is good for managing documentation. Other fields have similar types of documentation and content that Git could be be similarly useful for (whether it's worth learning Git just for those purposes is another question).

Nobody has mentioned pull requests, content review, managing commit/write privileges. There's a bunch of basic workflow things there that version control systems can facilitate. That doesn't mean you specifically need Git (or even a general VCS) for those things, but there are places where it could beat the status quo significantly.

For drafting yes, but at some point someone will probably want to edit or review the parts collectively. It's easy to prematurely consolidate the chapters into one file, and then any further changes have to be merged into the 'master'. A proper VCS can help here.