I had no clue what the headline was all about. I imagined some Aztec monks with a 1/55 HP motor trying to do something and just dying for no reason.
Aztec monks with 1/55 HP no longer die when picking up or dropping a relic
171–180 of 267 posts
Re: Aztec monks with 1/55 HP no longer die when picking up or dropping a relic
#172Earlier quoted context omitted.
> The more I write code, the more I notice how rarely one truly should want floats in most kinds of programs and how they almost always carry a whole bag of problems with them. This! Imho you more or less never want floats under "normal" conditions. Also in most application domains it makes exactly no difference that floats have HW support, as the bottlenecks are there usually elsewhere. And in case you really need r…
Floats are a computer representation of scientific notation, used for scientific computation. Coincidentally, hardware support is extremely important for scientific computation. (A bit less now than in the 90's but still a showstopper.) Hardware support is also extremely important for games, but floats are not a good representation for most of it. IMO, game data should be composed exclusively of integral numbers, but…
> Floats are a computer representation of scientific notation
No, they aren't. They are IEEE 754 binary floating point data. Something extremely weird, without precedent outside of computers science.
> Coincidentally, hardware support is extremely important for scientific computation.
Maybe it was once, but today it isn't.
If you need to do any serious number crunching you use nowadays dedicated hardware for that (which isn't part of the main CPU usually). (You could use CPU integrated GPUs or FPGAs for that, sure, but the point is that the FP unit on the CPU is usually way to slow for anything more serious.)
> Hardware support is also extremely important for games
That's more or less the only valid usage in mainstream left by now. But even there:
> but floats are not a good representation for most of it.
Exactly!
As said, you could and should use ints for most things. For the rest you want actually rationals. Only in some very special circumstances floats are a good enough approximation. But the cases where this is true are mostly related to rendering, as it doesn't matter if some pixels shown for the fraction of a second have a marginally wrong color or are marginally off. But rendering is done on the GPU anyway. So again no reason to use FP features on the CPU.
Even games using vector and quaternion math extensively this is just lib code in the engine. So there is no real reason this couldn't be moved to the GPU also, given an adequate architecture of the game engine. Such an approach brings even amazing possibilities for games; just have a look at for example https://store.steampowered.com/app/1468720/Ultimate_Epic_Bat... Want to animate 10 million of individual NPCs? No problem, if you do it on the GPU!
So imho the case for FP on the CPU is very shallow. But the need for rationals and decimals is a real thing. That's what the average cooperate developer needs day to day.
It's a shame HW is stuck in the past since decades and there is still no promise of progress on the horizon. (Maybe FPGA accelerators build into CPUs will change that at some point. But we still don't have that, even it's overdue.)
Re: Aztec monks with 1/55 HP no longer die when picking up or dropping a relic
#173Earlier quoted context omitted.
Seems all that could have been avoided by using rationals in general and the condition for living being >0 instead of dying The more I write code, the more I notice how rarely one truly should want floats in most kinds of programs and how they almost always carry a whole bag of problems with them.
> Seems all that could have been avoided by using rationals in general It's 2023: I'm still surprised that so many new languages/platforms still only provide only basic integer and IEEE-754 types for numerics: Rust, C#, Java, Swift and others still lack built-in, runtime-provided, nor even standard-library-provided rational types, which I assume really should be the preferred type for most business/domain/application…
Foundation has the Decimal type (not technically part of the Swift standard lib, but in practice available for most uses of Swift).
Re: Aztec monks with 1/55 HP no longer die when picking up or dropping a relic
#174Earlier quoted context omitted.
> IMO the best approach for business logic values is picking the smallest meaningful unit and representing it with integers. How would you design an RTS unit stats system to avoid this AoE Monk HP bug using only integer types?
`(new_maxhp * old_hp) / old_maxhp` avoids the original problem when using integers. Though you still need to make sure your type is big enough to not overflow. Or using fixed-point (which are a relatively simple abstraction over integers): `old_hp * (new_maxhp * old_maxhp)`.
They probably just added:
return ROUND()...
and went back to play
Re: Aztec monks with 1/55 HP no longer die when picking up or dropping a relic
#175Earlier quoted context omitted.
I'm (vaguely) surprised there hasn't been a hardware type for rationals. Then the GCD operation could be done in hardware and everything would be fast (at least as fast as floats). Not surprising, because adding new hardware data types is hard, but the financial institutions would benefit from something like that. A rat64 could be: - 1 sign bit - 3 format bits. Determines where the decimal is located, e.g. 30.30 vs 5…
> Then the GCD operation could be done in hardware and everything would be fast (at least as fast as floats). Could it? Is there a fast way to do GCD in hardware? Googling gave me https://en.wikipedia.org/wiki/Binary_GCD_algorithm , which needs O(log₂(max(u, v))) operations to compute gcd(u,v) , but I wouldn’t know whether that’s the best we can do in hardware, or whether that’s ‘as fast as floats’. Also, I don’t see…
Sorry, abuse of notation. 30.30 would be 30 bits numerator, 30 bits denominator.
I would imagine it would not need to fully reduce after every operation, there's probably tricks where if you know the factors going in, there will be obvious ones after multiplication/division.
It's not my best idea :p
Re: Aztec monks with 1/55 HP no longer die when picking up or dropping a relic
#176I don’t understand why they didn’t just use an integer. You can’t have half a HP in AoE and nothing has HP so high that it would overflow a 32 bit integer. Seems like it would avoid a lot of problems.
I had a really fascinating conversation with the lead architect at Frost Giant the other day. They're making the next StarCraft, basically.
They don't use floating points.
He didn't mention (IIRC) the possibility of rounding bugs; the reason he cited was something a bit more interesting: Floating points are not deterministic, which makes multiplayer challenging, as they simulate game state on each client's computers and only send commands across the wire.
One wonders if the "out of sync" errors that plagued Age of Empires in my youth were partially explained by FP determinism issues!
Re: Aztec monks with 1/55 HP no longer die when picking up or dropping a relic
#177Earlier quoted context omitted.
I'm (vaguely) surprised there hasn't been a hardware type for rationals. Then the GCD operation could be done in hardware and everything would be fast (at least as fast as floats). Not surprising, because adding new hardware data types is hard, but the financial institutions would benefit from something like that. A rat64 could be: - 1 sign bit - 3 format bits. Determines where the decimal is located, e.g. 30.30 vs 5…
> 60 bits of numerator and denominator. The trouble is this isn't enough, even for ordinary usage. The numerator and denominator grow in proportion to the total number of operations you have performed . For example, if you start with `1` and then multiply by `80/81` a thousand times, you get a number that's around 1e-6, but when expressed as a rational the numerator and denominator have hundreds of digits: https://ww…
But how often are people using decimal types to do that? Most of the uses I could see this type being used for - currency, percent scaling, datetimes, audio/video codec frame rates - all are basically fixed point operations. Anything involving powers of 80/81 would probably need bigint based rationals anyways.
Actually if you had an int64 type which was scaled by flicks, that'd give you quite a lot of latitude for most day to day stuff.
Re: Aztec monks with 1/55 HP no longer die when picking up or dropping a relic
#178Not knowing it was about a game, that was one of the strangest headlines ever to read on here.
Conversely, I didn't even have to even click in to understand it hah. Been playing AoE for around 20 years.
I was confused as well, because I just had chatted with someone about whether the aoe2 monk conversion ability on certain buildings was hardcoded or not (they can't convert i.e. Town Centers, Monasteries) ... turns out it at least used to be, no idea about now.
Re: Aztec monks with 1/55 HP no longer die when picking up or dropping a relic
#179Rather than linking to this Reddit thread, wouldn't it make more sense to either link to: * The linked-to patch notes? https://www.ageofempires.com/news/age-of-empires-ii-definiti... * The particular comment explaining this bug fix? https://old.reddit.com/r/Games/comments/12jbb9d/age_of_empir...
I tried to and thought I had linked to the comment. I did wonder if the link went only to the thread, but the Reddit mobile web interface is so broken that I couldn't tell where the link was going to, though I figured the Aztec monk bug would stay at the top either way so people would figure it out.
(the official patch notes don't explain the bug)
Re: Aztec monks with 1/55 HP no longer die when picking up or dropping a relic
#180Earlier quoted context omitted.
> The old "Multiplying and dividing is associative... for the set of reals Psstt... Dividing is not associative for the reals.
I think the original intent was referring to the fact that given the same operand, the order of multiplication and division shouldn't matter, e.g. A * X / X should give the same result as A / X * X, but in reality they can give different results when done by a computer due to precision limits, overflow, etc.
Ah that makes sense.