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.

Good point, but then the question is why haven't more suitable diff tools been developed?

I assumed most people were talking about dealing with single sites. From your previous comment about API documentation and "hand evaluating" Javascript I gathered that you were too. How would those things help one solve the general case?

The title is problematic but I don't see how that justifies someone calling the whole article low quality or spam.

Related episode of Build For Tomorrow (formerly Pessimists Archive) podcast:

https://player.fm/series/build-for-tomorrow/you-are-not-addi...

Definitely applicable here. There's no way we're going to eliminate all problems with spaces etc, so why invite trouble.

I wouldn't say it's always poor engineering though, especially the 'liberal in what you accept' half.

This. People are saying spaces improve ergonomics. Unless everyone always quotes their paths in documentation, emails, etc -- which they won't -- I say it actually reduces readability.

Also programs automatically that turn paths into links don't work with spaces.

I'm a bit surprised the DuckDB file size is that large (5x Parquet, and nearly as large as sqlite). I haven't used DuckDB, but I thought it had columnar storage and so would have better compression.

I don't believe there is any 'just parquet' library for R. The `arrow` package is perhaps the easiest way to handle parquet files in R.

According to [0][1], car makers are unwilling or unable to switch from older Intel chips to modern (smaller process) Intel ones. Switching architectures doesn't sound more feasible.

[0]: https://jalopnik.com/i-asked-experts-why-carmakers-cant-just...

[1]: https://news.ycombinator.com/item?id=28728965

That was 2006. Australia had a car industry well after that. It died a slow death, I doubt you can blame it on one supplier.

https://en.wikipedia.org/wiki/Automotive_industry_in_Austral...

Pretty much the opposite here. Dealing with lots of different formats from different sources, often once off. There's all kinds of crazy things people will call "data" (CSV 'variants' are the tip of the iceberg).

I envy your life of pristine CSVs and compatible implementations, where JSON doesn't solve any problems. But CSVs have a broad range of uses, and there are, in fact, plenty of implementations that do not follow RFC 4180, and even if everything did there would still be issues like the header row being optional (without an in-band way of telling). JSON is, in practice, much more well-defined.

On text vs numbers, at least some widely-used software (e.g. R, Excel) will try to guess for you. It should be obvious how this might cause problems. Maybe one should turn auto-conversion off (or not use things that don't let you turn it off) and specify which columns are numbers. Some datasets have a lot of columns, so this can be a PITA, even if you do know which ones should be numbers. But the bigger problem is if you have to deal with other people, or the files that they've touched. There are always going to be people that edit data in excel, don't use the right options when they import, etc.

Doesn't count, you still need light to make it human-readable.

/s

My guess is that it has more to do with popularity of the term "data scientist" in job ads than the popularity of those products. Total results for SAS etc are probably a lot more stable.