• 6 Posts
  • 27 Comments
Joined 1 year ago
cake
Cake day: June 11th, 2023

help-circle





  • The one case where I prefer video is when I know next to nothing about the topic and the other choice is mediocre to low-quality writing. Most people aren’t great technical writers, and it’s easy to skip over steps either because the writer assumes too much prior knowledge or simply because it takes effort to put that information in. On the other hand, videos are the opposite where it takes effort to cut stuff out, so you usually get all the steps which is what I need when I don’t know anything.

    If I have the option of a well-written, step-by-step tutorial though, or if I already know the topic and have a vague idea of what I’m looking for, then text is much better for being able to search/skim/go back and forth at my own pace.


  • I consider YabaIRyS more of an epithet than a nickname. I can’t imagine anyone using it to replace her name like “I wonder what YabaIRyS (IRyS) is doing”, only as a description replacing yabai like “Bruh, YabaIRyS (yabai)” in response to something she did/said.

    Forgetting Faufau is pretty indefensible. It’s been a long time, but that puts it in the same boat as Kronini and Sanana which I did remember.

    I wasn’t sure if Fuwa-chan and Moco-chan count as nicknames or if they’re just how you say their names in Japanese. I guess dropping the last syllable is what makes it a nickname as opposed to just their real name + Japanese honorific?












  • My main point is that PRQL makes no distinction. If you didn’t inspect that SQL output and already know about the difference between WHERE and HAVING, you would have no idea, because in PRQL they’re both just “filter”.

    Hmm, I have to disagree here. PRQL has no distinction in keyword, but it does have a distinction in where the filter goes relative to the aggregation. Given that the literal distinction being made is whether the filter happens before or after the aggregation, PRQL’s position-based distinction seems a lot clearer than SQL’s keyword-based distinction. Instead seeing two different keywords, remembering that one happens before the aggregation and the other after, then deducing the performance impacts from that, you just immediately see that one comes before the aggregation and the other after then deduce the performance impacts.

    As far as removing arbitrary SQL features, I agree that that is it’s main advantage. However, I think either the developers or else the users of PRQL will discover that far fewer of SQL’s complexities are arbitrary than you might first assume.

    That’s fair, I was just thinking of things that frustrate me with SQL, but I admittedly haven’t thought too hard about why things are that way.


  • What are the implications of WHERE vs HAVING? I thought the only primary difference was that one happens before the aggregation and the other happens after, and all the other implications stem from that fact. PRQL’s simplification, rather than obscuring, seems like a more clear and reasonable way to express that distinction.

    I don’t know if PRQL supports all SQL features, but I think it could while being less complex than SQL by removing arbitrary SQL complications like different keywords for WHERE vs HAVING, only being able to use column aliases in certain places, needing to recompute a transformation to use it in multiple clauses, not forcing queries to be in SELECT… FROM… WHERE… order, etc.



  • Agreed, smartness is about what it can do, not how it works. As an analogy, if a chess bot could explore the entire game tree hundreds of moves ahead, it would be pretty damn smart (easily the best in the world, probably strong enough to solve chess) despite just being dumb minmax plus absurd amounts of computing power.

    The fact that ChatGPT works by predicting the most likely next word isn’t relevant to its smartness except as far as its mechanism limits its outputs. And predicting the most likely next word has proven far less limiting than I expected, so even though I can think of lots of reasons why it will never scale to true intelligence, how could I be confident that those are real limits and not just me being mistaken yet again?



  • Ask it a question about basketball. It looks through all documents it can find about basketball…

    I get that this is a simplified explanation but want to add that this part can be misleading. The model doesn’t contain the original documents and doesn’t have internet access to look up the documents (though that can be added as an extra feature, but even then it’s used more as a source to show humans than something for the model to learn from on the fly). The actual word associations are all learned during training, and during inference it just uses the stored weights. One implication of this is that the model doesn’t know about anything that happened after its training data was collected.