“History is written by the victors.” - what I immediately thought of.
- 0 Posts
- 23 Comments
Pseudo-Shrink: “Just reimagine yourself! Be what you need to be! Rebrand yourself as a bishop, then you’ll be happy :-)”
If you want the magic explained, here’s a start: https://en.wikipedia.org/wiki/Lempel%E2%80%93Ziv%E2%80%93Welch
Huh, really? I thought there were slightly more women than men, but maybe that depends on the economies etc.
As for your second point, yes, exactly. They don’t reproduce. So it doesn’t matter if many men get one wife each, or if a few men get many wives each, the number of pregnancies won’t change, and the number of pregnancy-related deaths won’t change either. So (again), I don’t see how polygyny helps in this situation.
Edit: This first point was wrong, but the second point still stands.
Polygyny wouldn’t solve the aforementioned problem if we suppose that the birth rate of men and women is roughly the same. If one man has many wives, some of whom even die, then several other men won’t have any wives.
Kayana@ttrpg.networkto
Technology@lemmy.world•ESET in Germany recommends installing Linux as alternative for older HW running Windows not supported by Windows 11English
6·11 months agoHardly a surprise, since Windows 10 didn’t need new hardware to run. You could install it on anything.
Kayana@ttrpg.networkto
Games@lemmy.world•Alan Wake, Control developer agrees €15m convertible loan from TencentEnglish
396·1 year agoNot only is that headline’s grammar exceptional(ly bad), for a moment I thought the developer of Control was named Alan Wake. Like, how did they manage to butcher that so badly?
Because you don’t need to have significant experience or rent a VPS in order to do that, and I can respect that. We don’t need to force FOSS developers to become proficient in everything.
What needs to happen is some kind of tool (ideally FOSS) that lets you spin up an actual forum with the same difficulty to set it up as Discord.
That could work too, but for many people, being able to dodge/avoid hits is exclusively the DEX bonus to AC, and they believe it doesn’t have to do anything with hit points.
I’m on two minds about that: On the one hand, it’s true that you’re far better at dodging in lighter (or no) armor. OTOH, I agree with you that experience teaches you to decide where you’re going to get hit if at all. So it might be something like “raise your arm so the strike doesn’t hit your belly”.
I rationalize it as “You took some blows so now you have a better pain tolerance”.
Possible formula: Tax for n-th house = n-th Fibonacci number + 5 * max(0, n - 2). So low numbers like three get penalized by that linear part, and high numbers grow exponentially due to the Fibonacci number.
Can you even kill something that’s already dead?
Gotcha, I didn’t catch that on my first read-through.
This seems wrong…
10^17 milligrams
-> 10^14 grams
-> 10^11 kilograms
-> 10^8 tons
So it should actually be 553 402 322 tons, which means that we can do it only using the rice produced in 2022.
Kayana@ttrpg.networkto
AnarchyChess@sopuli.xyz•if this post gets 32 upvotes, i will post again with twice as wide en passant
2·1 year agoBut you just completely ignored everything I said in that comment.
Mathematically, that is precisely how O notation works, only (as I’ve mentioned) we don’t use it like that to get meaningful results. Plus, when looking at time, we can actually use O notation like normal, since computers can indeed calculate something for infinity.
Still, you’re wrong saying that isn’t how it works in general, which is really easy to see if you look at the actual definition of O(g(n)).
Oh, and your computer crashing is a thing that could happen, sure, but that actually isn’t taken into account for runtime analysis, because it only happens with a certain chance. If it would happen after precisely three days every time, then you’d be correct and all algorithms would indeed have an upper bound for time too. However it doesn’t, so we can’t define that upper bound as there will always be calculations breaking it.
Kayana@ttrpg.networkto
AnarchyChess@sopuli.xyz•if this post gets 32 upvotes, i will post again with twice as wide en passant
6·1 year agoIt’s very pedantic, but he does have a point. Similar to how you could view memory usage as O(1) regardless of the algorithm used, just because a computer doesn’t have infinite memory, so it’s always got an upper bound on that.
Only that’s not helpful at all when comparing algorithms, so we disregard that quirk and assume we’re working with infinite memory.
To be honest, I don’t really like it either, which might surprise you considering my last sentence. I just couldn’t resist making a small pun myself.
Got a laugh from me, but I did mean only the ‘a’, not the ‘ar’. I couldn’t think of any other English word with that sound unfortunately, do you have a better suggestion?
Try pronouncing the ‘a’ in pan like the ‘a’ in large, then you’ll end up with a rather well-done pun.




There are two different things mentioned here, which I feel I need to clarify:
First, what you said about merging / creating a PR with broken tests. Absolutely you shouldn’t do that, because you should only merge once the feature is finished. If a test doesn’t work, then either it’s testing for the wrong aspect and should be rewritten, or the functionality doesn’t work 100% yet, so the feature isn’t ready to get merged. Even if you’re waiting for some other feature to get ready, because you need to integrate it or something, you’re still waiting, so the feature isn’t ready.
At the same time, the OP’s point about tests being supposed to fail at first isn’t too far off the mark either, because that’s precisely how TDD works. If you’re applying that philosophy (which I personally condone), then that’s exactly what you do: Write the test first, checking for expected behaviour (which is taken from the specification), which will obviously fail, and only then write the code implementing that behaviour.
But, even then, that failing test should be contained to e.g. the feature branch you’re working on, never going in a PR while it’s still failing.
Once that feature has been merged, then yes, the test should never fail again, because that indicates a new change having sabotaged some area of that feature. Even if the new feature is considered “essential” or “high priority” while the old feature is not, ignoring the failure is one of the easiest ways to build up technical debt, so you should damn well fix that now.