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/)H
Posts
4
Comments
392
Joined
2 yr. ago

  • But there are examples of twins who grew up apart and still look almost identical

  • I don't think root comment was saying the AI would generate perfectly accurate images. I think 90% accuracy is doable, just from DNA

  • But they could probably get 90% the way there with just DNA. I think that was the point.

  • Don't know why you're being downvoted, it's a good point that shows that genetics is the main factor for your appearance

  • Got any examples of some of the issues LLMs can't solve? I still feel like an "advanced beginner" and want to know what's beyond

  • A lot of times its tech opinion articles. Stuff like "why AI is bad". And I read the arguments and judge them for myself.

  • Ok well there's probably a dozen different ways to tackle this issue but I'll let you explore them since that's part of the fun (and I'm lazy lol)

  • I recall OpenAI saying to a courtroom judge that modern AI requires training off copyrighted material. And obviously the AI labs cannot just release those.

    Distlled models (aka models that train themselves off the responses from other AI models) could probably release all the AI responses they used for training, since afaik AI generated content is not copyrightable..

    However I suspect that most modern models are built from previous models. For example Claude Fable is probably based on Claude Sonnet or something. And for a downstream model to be fully "open source" and reproducible, you would need to reproduce the upstream model too. So even if a downstream model didn't use copyrighted data (eg it only used distills), one of the upstream models likely did.

  • Please read the whole post. OP is asking for the datasets used to train the models.

  • maybe just "if velocity < 0.01, find which side is closest to the floor, and if its within 1mm of the floor, take the opposite side (the one facing up) as the answer"

    The only edge case I can think of is if it gets close to balancing on an edge, and then finally tips over to one side or the other. But in that case I don't think the face closest to the floor would be within 1mm of the floor, so it should still work.

  • I think of it like age verification. Slipperly slope to a proprietary kernel-level "security compliance module" on all devices, aka the end of general computation.

  • Can you predict the resolution when it is close enough to settled? Worst case maybe have an algorithm that estimates the probability of each face ending up on top, and if one face is overwhelmingly more probably, choose it. Otherwise let it settle using your physics engine

  • I don't think the "what is a hash" question was a great example, but paired with the rest of the comment and context, I understood their point

  • How does it lead to dependency hell? I thought the point was that it didn't share dependencies with the host, so different apps could have different versions of the same package and everything would still work.

  • Well great news, the world has mostly settled on Flatpak now.

  • You actually get them all the time, because the programmer is more deeply knowledgeable about the features they wrote and can identify gaps better.

    Boss: "Can we move the widget to the left side of the page?"

    Programmer: "Sure but that means when the sidebar opens it will obscure the widget, making it hard to see both at the same time. Do we want that?"

    Boss: "Hmm I didn't consider that. Let me ask the UX team what they think."

  • Automation means that the code is the documentation...usually

  • The point is that in a real software engineering process, specs and requirements are rarely defined precisely from the start, and the programmer should be able to identify the gaps and clarify them. A generic answer doesn't help as much as a clarifying question.

    A common but amateur mistake is to just make assumptions about how something should work and then forge ahead. As a programmer in a company, you are building things for somebody else (your boss, your client), so you need to ask them first.