Skip Navigation

InitialsDiceBearhttps://github.com/dicebear/dicebearhttps://creativecommons.org/publicdomain/zero/1.0/„Initials” (https://github.com/dicebear/dicebear) by „DiceBear”, licensed under „CC0 1.0” (https://creativecommons.org/publicdomain/zero/1.0/)QW
Posts
6
Comments
44
Joined
2 yr. ago

  • Do you care about modeling the cells? If not, you could represent each row with just a number. When X plays, add 1 to all the rows that include the position they played, and when O plays, subtract 1. If any row reaches +3 or -3, that player wins.

    As for rotation/reflection invariance, that seems more like a math problem than a Rust problem.

  • 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.

  • Thanks for the embed preview trick. I didn't mind needing a Spotify account but then it refused to play it in the browser and wanted me to download their app instead, which was too much for something I have no intention of ever using again.

  • I disagree with the author on operator overloading. They claim that this function in C

     C
        
    float foo(float a, float b) {
        return a+b;
    }
    
    
      

    is perfectly clear because you know it's doing floating point addition, while this function in Python isn't

     Python
        
    def foo(a, b):
        return a + b
    
    
      

    because you don't know if it's floating point addition, integer addition, or string concatenation, and what happens if the inputs are different types?

    I think that's fundamentally mistaken. You could also ask of the C version if it's doing normalized floating point addition, denormalized floating point addition, infinity addition, or NaN propagation. What happens if you mix different types of floats? And the answer is that it doesn't matter. These are all just aspects of floating point addition. It returns the most sensible result in whatever format is best to hold that value, and you don't need to worry yourself about how floats are stored under the hood.

    The same is true of the Python version. It doesn't matter if it's integer addition or floating point addition or string concatenation. Those are just different aspects of the addition operator and it returns the most sensible result in whatever type is best to hold that value.

  • ...

    Jump
  • What web games are you playing? Do you count the time it takes to load the web page? I can't think of a single game that loads so fast, web or otherwise. agar.io is super slow and bloated, hanab.cards takes about half a second to make a room, candybox2.github.io comes close but the network tab reports 128 ms to download the javascript.

  • I think that's a British influence. Rs in English words tend to get transcribed into katakana as long vowels to resemble British pronunciation, like parking → パーキング or art → アート. For a Japanese person who hasn't formally learned a romanization system but knows a decent amount of these English → Japanese word pairs, it seems pretty reasonable to try to reverse the process by turning long vowels into Rs when writing Japanese in Romaji.

  • Some clarifications: f(x) = -2x/3 + 5 isn't technically correct. It happens to equal that when x is between 6 and 9, but the function is different outside of that range. Similarly, your equation for F(x) is only correct when x is between 6 and 9. The reason this matters is because F(0) = 2 doesn't mean C = 2. That only works if the function is the same all the way to x = 0, which it's not.

    If you want to solve by integrating, you would have to integrate each section and find the right C for each section that makes the integrals all connect to each other.

    Alternatively, you can use the property that F(b) - F(a) = the area under f(x) from a to b. I think that region from x = 4 to 6 is supposed to be a semicircle, so each section is a standard shape and you can calculate the area using geometry.

  • Just a guess, but was there an extra space after the comma? Unlike in English, the full-width comma takes up an entire square worth of space like all other characters and shouldn't have an extra space after it. I don't know if Duolingo even considers spaces when marking answers though so that may not be it.

  • Is that a GregTech pack? I tried InfiTech 2 a while back but hated the mining so much. I resorted to using JourneyMap waypoints to teleport to all the ores but still couldn't stand it and gave up. GregBlock was more to my taste being a skyblock with automatable ores, but all the crafting and the machines always ending up with an odd amount of liquid left over got to me. Never made it past MV. Are Omnifactory/Nomifactory any better?