Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Aztec monks with 1/55 HP no longer die when picking up or dropping a relic

reddit.com

Post reply on HN
Print view View original

181–190 of 267 posts

Re: Aztec monks with 1/55 HP no longer die when picking up or dropping a relic

#181

Post by justinpombrio »

kortex wrote: post #177
justinpombrio wrote: post #163

Earlier quoted context omitted.

> 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 mo…

Yeah, fixed point is different from rational, and all those examples you gave sound to me like fixed point. And that can be implemented efficiently without dedicated hardware support: the denominator is fixed, and you store the numerator as an integer.

A 1/3 off discount on a $10 item is $6.67 (or $6.66 if rounding in the customer's favor), not $10/3.

(Except datetime, did you mean timestamp? A timestamp is an instant in time, and it often makes sense to store it in high precision because you're saying exactly when something happened. A datetime is for communicating between humans who are using some particular calendar; it rarely makes sense to have more than minute precision.)

Re: Aztec monks with 1/55 HP no longer die when picking up or dropping a relic

#182

Post by Reason077 »

LeoNatan25 wrote: post #170
vultour wrote: post #100

Earlier quoted context omitted.

Blizzard also pulled the original W3 downloads and switched everyone to a non-hd version of Reforged. I'm still mad about that because I paid for both and I'm no longer able to get one of them.

But isn’t Reforged using the same engine as the original, with higher res assets (mostly textures)? At least, I thought so, as that was part of the criticism of Reforged.

Nothing wrong with that, necessarily. In fact, I’d argue that’s exactly what I would want out of an ideal War3 reforged. Exactly the same game modernised for modern systems, with the “same” graphics just at higher resolution and detail.

Besides, World of Warcraft, StarCraft 2, and Heroes of the Storm were all built using upgraded versions of the Warcraft 3 engine, so it’s proven to be quite capable. It’s logical to use an updated version of the engine for an updated version of the same game.

Trying who port the game to an entirely different engine would not only be much more effort, it would risk introducing subtle differences in gameplay and feel that could mean it doesn’t play quite the same any more.

Re: Aztec monks with 1/55 HP no longer die when picking up or dropping a relic

#183

Post by fm77 »

GreymanTheGrey wrote: post #130
rini17 wrote: post #103

Earlier quoted context omitted.

Or it's vendors that don't care about correctness, like providing decimals by default and high performance floating point as an "optimized" option. Python did something like that by using bigints as a default for integers. What would not have been true 30 years ago? I remember "real" fixed-point type built-in in Turbo Pascal and explicitly documented as suitable for money. Common Lisp has had first class fractions su…

Slight correction, from a former Turbo Pascal (and subsequent Delphi) programmer... "Real" types were platform-dependent floating-point types, not suitable for monetary calculations whatsoever. and would map to either Single or Double depending on the underlying CPU architecture. Sort of like a C-style "int" that would map to an 8-bit, 16-bit, 24-bit, 32-bit, 36-bit, 60-bit, 64-bit etc integer, depending on the compi…

Slight correction from an Turbo Pascal expert ;-)

Turbo Pascal did NOT have an 8-byte fixed point "currency" type suitable for monetary calculations. It did have an int64 type called "comp" though which was handled as a float by the FPU and hence not slower than the types "single" (f32), "double" (f64) or "extended" (f80).

IIRC, "currency" came with Delphi V2.0 (or even later), but then still it wasn't slower than other floats when you did heavy calculations with it as it was also handled by the FPU. Only reads and writes from and to such variables were expensive as there was always a scaling (multiplication by 1e4 and 1e-4) involved — internally it was that int64 "comp" type. (But here I might be wrong, I never really used "currency", I disassembled lots of Delphi binaries with lots of different data types as I wanted to know how the compiler worked. Today however my Delphi knowledge is quite fuzzy).

Re: Aztec monks with 1/55 HP no longer die when picking up or dropping a relic

#184

Post by shilgapira »

dimgl wrote: post #113
shilgapira wrote: post #43

What a weird coincidence. I thought at first this would be about the Guild Wars game, but turns out they both have something to do with monks and 55: https://wiki.guildwars.com/wiki/55_Monk

Wow, another 55 monk enjoyer. I used to farm hydras outside of the Crystal Desert with this.

There were dozens of us, dozens!

Re: Aztec monks with 1/55 HP no longer die when picking up or dropping a relic

#185

Post by zelphirkalt »

still_grokking wrote: post #93
zelphirkalt wrote: post #18

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

> 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…

I think most (all due to standard?) Scheme dialects have rationals. Pyret seems to have inherited them from Racket, which inherited them from Scheme. Common Lisp also seems to have them (I just tried (/ 1 3) in SBCL REPL.). So there is quite a number of languages which have rationals, but many mainstreamy ones miss out in this aspect.

Re: Aztec monks with 1/55 HP no longer die when picking up or dropping a relic

#186

Post by dragontamer »

vippy wrote: post #10
dragontamer wrote: post #5

Earlier quoted context omitted.

Note that the April 2023 patch is live, and perhaps one of the biggest changes to the meta ever. I don't think anyone really knows how the new meta will shake out. Build orders will absolutely change this patch. Though I guess that only matters if you were hoping to get to a competitive level. Definitive Edition does have a very good tutorial mode for people interested in online combat, and "Extreme" AI is 100% legit…

What's up with all of these 18 feudal builds?? And to Hell with the Portuguese fast castle, organ gun OP on arena.

Oh, one more thing. April patch changed Portuguese Organ Guns.

The goal of the April patch was to make organ guns more of an anti-unit shotgun, and less of a wall destroyer. So you'll see fewer organ guns on Arena (one of the few maps that start off fully stone walled).

Re: Aztec monks with 1/55 HP no longer die when picking up or dropping a relic

#187

Post by lispm »

zelphirkalt wrote: post #185
still_grokking wrote: post #93

Earlier 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…

I think most (all due to standard?) Scheme dialects have rationals. Pyret seems to have inherited them from Racket, which inherited them from Scheme. Common Lisp also seems to have them (I just tried (/ 1 3) in SBCL REPL.). So there is quite a number of languages which have rationals, but many mainstreamy ones miss out in this aspect.

Scheme got rationals from Common Lisp. See R2RS.

Re: Aztec monks with 1/55 HP no longer die when picking up or dropping a relic

#188

Post by DaiPlusPlus »

marcosdumay wrote: post #127
jacquesm wrote: post #74

Earlier quoted context omitted.

> can we agree that an application-programming language today should also include signed-and-unsigned "money-safe" decimal types You mean like COBOL?

Yep, like COBOL, or SQL. But, in fact, I don't know of any language that doesn't. They are just not basic types.

Very few SQL implementations have unsigned integers (I think only MySQL+MariaDB has it out-of-the-box?). From my conversations with the MS SQL Server dev team, other than the overall lack-of-demand, it’s because ISO SQL leans very heavily on implicit conversions, and implicit conversions between signed and unsigned types are a massive pain to implement and gracefully handle all edge-cases and in a way that doesn’t behave too unexpectedly (and remember that most SQL language users are likely unfamiliar with all the gotchas of C-style unsigned integers: most SQL users are business analysts, not low-level systems programmers). Besides, if you just want to disallow negative values then just use a CHECK constraint.

———-

Also, in general, it’s not enough to just add loads of distinct numeric types to a language or library; in fact that’s probably the wrong thing to do as it burdens the programmer with having to make (often hair-splitting) decisions ahead-of-time - instead I’d like the language to have me set-up high-level constraints/invariants on a numeric parameter, local, or field and then the compiler chooses the best low-level implementation based on those constraints (and constraint-inference a-la Hindley–Milner would be nice too)

Re: Aztec monks with 1/55 HP no longer die when picking up or dropping a relic

#189

Post by DaiPlusPlus »

wruza wrote: post #154
hermitdev wrote: post #132

Earlier quoted context omitted.

> Because we cannot represent fractional units of the already smallest unit of currency, we have to choose a value anyway to charge or dispense. Unlike, say, if we stored it in dollars as a floating point and we can start compounding errors from the floating point type. I've spent 20 years mostly working in finance. You'd be surprised at the prevalence of floating points used to represent currency. I cringe every tim…

You'd be surprised at the prevalence of floating points used to represent currency. I cringe every time We all cringe but then there’s a “floating point or gtfo” ultimatum that most languages present to you. People would be happy to not use FP. But the reality is, you can have a monetary column in a 30 years old database engine, but not in a 5 years old language runtime. When you only have a hammer…

In that situation you’re meant to use integer-cents though.

Re: Aztec monks with 1/55 HP no longer die when picking up or dropping a relic

#190

Post by zX41ZdbW »

DaiPlusPlus wrote: post #188
marcosdumay wrote: post #127

Earlier quoted context omitted.

Yep, like COBOL, or SQL. But, in fact, I don't know of any language that doesn't. They are just not basic types.

Very few SQL implementations have unsigned integers (I think only MySQL+MariaDB has it out-of-the-box?). From my conversations with the MS SQL Server dev team, other than the overall lack-of-demand, it’s because ISO SQL leans very heavily on implicit conversions, and implicit conversions between signed and unsigned types are a massive pain to implement and gracefully handle all edge-cases and in a way that doesn’t be…

ClickHouse has support for unsigned integer types: UInt8, UInt16, UInt32, UInt64, UInt128, and UInt256.

The main applications are: hashes and identifiers, e.g., visitor identifier in clickstream.

Post reply on HN