Why 0x7FFFFFFF but no infinity

[Enjay]

I figured this is probably a more general coding query rather than necessarily scripting related. The maximum number that ZDoom can accept for various things is 0x7FFFFFFF (2147483647 when converted to decimal). I believe this number is the largest possible value of an Int32. As a result, people use it for lots of things - e.g. giving an item a very high mass so that it will not move when hit (though this was given as advice a long time ago, it is unreliable and the DONTTHRUST flag should be used instead).

Similarly, over the years, there have been lots of people asking questions like "how can I make sure my powerup never runs out?" and the answer given is often something like "give it a duration of 0x7FFFFFFF which equates to almost 2 years game time and is effectively infinite for all practical purposes." That's just an example - it comes up in several other duration-related questions too.

So, what I was wondering is, why has a true infinity never been added that *ZDoom can see as a duration? Is there some kind of technical limitation? Would it be problematic to have some routine that recognises a symbol/word that means "never run out"?
e.g.

Code: Select all

Powerup.Duration Infinite

Code: Select all

Radius_Quake (9, Infinite, 64, 64, 0);

etc.

It's always just struck me as a bit of a weird thing, and it also itches at the back of my brain that 0x7FFFFFFF is not truly infinite (even if it is in practical terms) and a game could be left running for 2 years and the duration would expire. Given that the question has come up many times over the years, it seems like it might have been added already if there wasn't a good reason for it not to be. So, I was just wondering what that reason might be.

[MartinHowe]

Floating point values can have infinities; however, constants.zs doesn't define an M_POSINFINITY or M_NEGINFINITY and I'm not sure how you could get the value into a double as that requires direct access to the FPU, which ZScript doesn't expose.

The 'spare' INT value 0x80000000 is used for bit manipulations (e.g., flags) so is not free to use as an "integer infinity" and even if it was, there'd be nothing left to indicate the sign of the infinity.

To make INT generally have an infinity would need INT to be replaced with something akin to .NET's nullable types, in practice taking up an extra byte (at least) for the 'infinity flag'. Since we don't use infinity much in an integer context, this would be ridiculously wasteful unless some compiler magic was used via 'let'.

In short, it's a practical limitation.

[phantombeta]

Floating-point infinities almost always cause problems when you're actually doing maths. It's incredibly easy for an infinity to turn into a NaN (Inf / Inf and Inf - Inf...), and then you're screwed.
Mass and powerup durations specifically are ints. Adding infinities to ints would be annoying and require special code to be added that would make the whole game slower, as every single thing that used ints would be affected by it.
They could have "just" been made into floats, but floats have decreasing precision as they get further from zero, which you don't want to ever happen with timers and durations... And a bunch of the values are wasted on decimals you can never use, since durations are in tics. (And even if these issues didn't exist, at this point, changing it could cause problems for existing mods that assume they're ints)

For those examples with durations, IMO the correct way to handle it would be to make negative numbers mean the duration is infinite. Negative durations don't already have a meaning, and it's not particularly hard, nor more expensive, to handle that.
(Of course, it's already too late for that- it could break mods that it to a negative duration for some other reason, and also mods that have custom code that interacts with the duration of a powerup)

Floating point values can have infinities; however, constants.zs doesn't define an M_POSINFINITY or M_NEGINFINITY and I'm not sure how you could get the value into a double as that requires direct access to the FPU, which ZScript doesn't expose.

Positive infinity is exposed as double.Infinity. Negative infinity is just -double.Infinity. (Likewise, there's also `double.NaN`... Though that one's less useful)

These are all the constants defined for double:

Code: Select all

double.Min_Normal
double.Max
double.Epsilon
double.Equal_Epsilon
double.NaN
double.Infinity

double.Min_Denormal
double.Dig
double.Min_Exp
double.Max_Exp
double.Mant_Dig
double.Min_10_Exp
double.Max_10_Exp

[MartinHowe]

These are all the constants defined for double:

Code: Select all

double.Min_Normal
double.Max
double.Epsilon
double.Equal_Epsilon
double.NaN
double.Infinity

double.Min_Denormal
double.Dig
double.Min_Exp
double.Max_Exp
double.Mant_Dig
double.Min_10_Exp
double.Max_10_Exp

Thanks, PB, didn't know about those

[Enjay]

Thanks for the info. It makes sense.