When checking whether it is a multiple of some k, you can add/subtract multiples of k without changing the result, and those 99...9 are multiples of both 3 and 9.
I don't think that games, art and the demoscene can be used as evidence here. Implementing something like C# means you have a spec to implement. You have to be creative with the implementation without violating that spec.
All the three of games/art/demoscene on something like the C64 have a rough idea as the spec, but then you'll get creative about how much of that "spec" you can bend and violate to meet the technical limitations of the C64, while still being fun.
Spore (C64) also had that and was even a year earlier than Slimey's Mine. So even multiple instances of prior art are not a blocker towards getting a patent...
How did you come to the conclusion that those have not been peer-reviewed? Every uni course that presents the work of these people implicitly reviews it for consistency, and the advanced practices courses repeat their experiments.
"The system of peer review" in this context is the system where a scholarly journal editor sends your submitted paper out to other experts in the field to decide whether or not to publish it. This system came into use in the middle of the 20th century, and Einstein was famously outraged by it. It does not refer generically to every time someone reads or discusses a paper or replicates an experiment.
I don't think survivorship bias is particularly relevant for three reasons. First, both papers from 50 years ago and papers from 150 years ago are already heavily filtered. Second, if you look at journal issues from 150 years ago, you will find forgotten papers in the same issue with the foundational ones, and the quality is still much better than today's forgotten papers. Third, what I'm really concerned about is not that bad papers about bad research are being published, but that good papers about good research that would have been done are not, echoing Higgs's remark about how he couldn't have done his work on the Higgs boson today because he wouldn't get tenure. Or, read Freeman Dyson's autobiography, and contrast the years when he was working on nuclear energy to the rather uninspired following 50 years, because, as he put it, it stopped being fun.
I'm sceptical about fixing (in the sense of a lasting solution), but it might be a very powerful tool to communicate to devs what the UI should look like.
It would sound more logical to me to buy a stack of pre-made patterns (e.g. coin or cube form-factor) and glue them into a like-shaped slot in a 3d-printed playing piece. Assuming that is possible, and you'd still have to make a conductive path to the person touching the piece, but this would be much easier than printing the pattern yourself.
It is not a requirement to provide a conductive path to the person though. The patterns (glyphs as we call them) are detected and tracked regardless of whether they are being touched. However, when there is a conductive path to the person, the system detects that which provides another input vector.
This screams for compatibility with 3d printers. eg: design a piece to be "absorbed" by a LEGO brick (2x4, duh!), and design a capacitive pathway for "two buttons" a-la: https://a.co/d/f7wm3GA
3D print your goblin army, snap it to the base, touch the sword arm to attack, the shield arm to defend, etc. light up the base via capacitive to 0/1/2 inputs and you're set!
I'll soon get to make technology choices for a project (context: we need an MQTT broker) and Kafka is one of the options, but I have zero experience with it. Aside from the obivous red flag that is using something for the first time in a real project, what is it that you dislike about Kafka?
Note: by "client" I mean "consuming application reading from a Kafka topic"
Not your parent poster, but Kafka is often treated like a message broker and it ain't that. Specifically, it has no concept of NACK-ing messages, it is either processed or not processed. There's no way to the client to say "skip this message and hand it to another worker" or "I have this weird message but I don't know how to process it, can you take it back?".
What people very commonly do is to instead move the unprocessed message to a dead-letter-queue, which at least clears the upstream queue but means you have to sift through the dead-letter-queue and figure out how to rescue messages.
Also people often think "I can read 100 messages in a batch and handle them individually in the client" while not considering that if some of the messages fail to send (or crash the client, losing the entire batch), Kafka isn't monitoring to say "hey you haven't verified that message 12 and 94 got processed correctly, do you want to keep working on them or should I assign them to someone else?"
Basically, in Kafka, the offset pointer should only be incremented after the client is 100% sure it is done with the message and the output has been written to durable storage if you care about the outcome. Otherwise you risk "skipping" messages because the client crashed or otherwise burped when trying to process the message.
Also Kafka topic partitions are semi-parallel streams that are not necessarily time ordered relative to each other... It's just another pinch point.
Consider exploring NATS Jetstream and its MQTT 3.1.1 mode and see if it suits your MQTT needs? Also I love Bento for declarative robust streaming ETL.
That Github issue doesn't really stress how serious he problem is. They make it sound like unnecessary parentheses get removed when they should be kept for clarify. What actually happens is that necessary parentheses get removed, altering the meaning of the expression. The example I encountered myself was this or similar to it (can't remember exactly):
I feel like this is the time to mention "How Big Things Get Done", by Bent Flyvbjerg. "Long planning vs. start prototyping" is a false dichotomy. Prototyping IS planning.
Put another way, refining tickets for weeks isn't the problem; the problem is when you do this without prototyping, chances are you aren't actually refining the tickets.
Planning stops when you take steps that cannot be reverted, and there IS value in delaying those steps as much as possible, because your project then becomes vulnerable to outside risk. Long planning is valuable because of this; it's just that many who advocate for long planning would just take a long time and not actually use that time for planning.
Or, if you don't want to fight this battle in lieu of other tenants, _threaten_ to sue to either force the agency to reveal the name and address of the landlord, or ideally, have them put pressure on the landlord to return the security deposit.
I'm already suing over the security deposit - that's actually an open and shut case. In this case it's not clear that I actually suffered any personal damage so it's not immediately clear whether I have standing in a civil suit.
Did you ask a lawyer-- any lawyer-- before writing the sentence surrounding this word?
I assume the answer is yes. But I also think I remember reading a blog by you where you wasted hours attempting to reverse-engineer some hardware before finally sending it the help flag.
123456 = 1 * 100000 + 2 * 10000 + 3 * 1000 + 4 * 100 + 5 * 10 + 6 = 1 * (99999+1) + 2 * (9999+1) + 3 * (999+1) + 4 * (99+1) + 5 * (9+1) + 6
When checking whether it is a multiple of some k, you can add/subtract multiples of k without changing the result, and those 99...9 are multiples of both 3 and 9.
So 123456 is a multiple of 3 (or 9) iff
1 * 1 + 2 * 1 + 3 * 1 + 4 * 1 + 5 * 1 + 6 * 1 = 1 + 2 + 3 + 4 + 5 + 6
is. Apply the same rule as often as you want -- that is, until you only have one digit left, because then it won't get simpler anymore.