Units have been defined as in Metric Units; to square an area, I have:
To decide what area is the square of (N - a length):
decide on N * N.
This returns a fascinating array of results; I’m quite curious as to why:
1 m --> 1 sq m
2 m --> -2 sq m
3 m --> 2 sq m
4 m --> 2 sq m
5 m --> -1 sq m
I cannot reproduce your results. This code:
[code]Include Metric Units by Graham Nelson.
Tiananmen Square is a room.
To decide what area is the square of (N - a length):
decide on N * N.
Squaring is an action applying to one length. Understand “square [length]” as squaring.
Carry out squaring:
say “That would be [square of length understood].”
Test me with “square 1m / square 2m / square 3m / square 4m / square 5m”[/code]
Leads to the expected results (1, 4, 9, 16, 25).
Obviously, you are located at one of the few places in the universe where two-dimensional space is warped through the third dimension and the laws of geometry break down. 
Robert Rothman
I suspect you’re defining such a large scale of units that the numbers overflow. You’d need to show the unit definitions for any more accurate debugging, preferably a minimum complete test case that shows the behavior.
I’ve got it–it only happens in Z-code. Observe.
[code]Length is a kind of value.
1m (in metric units, in m) or 1 m (in metric units, in m) or 1 meter (in meters, singular) or 1 metre
(in metres, singular) or 2 meters (in meters, plural) or 2 metres (in
metres, plural) specifies a length.
1cm (in metric units, in cm) or 1 cm (in metric units, in cm) or 1 centimeter (in centimeters,
singular) or 1 centimetre (in centimetres, singular) or 2 centimeters
(in centimeters, plural) or 2 centimetres (in centimetres, plural)
specifies a length scaled down by 100.
1km (in metric units, in km) or 1 km (in metric units, in km) or 1 kilometer (in kilometers, singular)
or 1 kilometre (in kilometres, singular) or 2 kilometers (in
kilometers, plural) or 2 kilometres (in kilometres, plural) specifies
a length scaled up by 1000.
Area is a kind of value. 1 sq m (in metric units, in sq m) or 1 square meter (in square meters,
singular) or 2 square meters (in square meters, plural) or 1 square metre
(in square metres, singular) or 2 square metres (in square metres, plural)
specifies an area.
Length times length specifies an area.
To decide what area is the square of (N - a length):
decide on N * N.
When play begins: say “The square of 1m is [square of 1m]. The square of 2m is [square of 2m]. The square of 3m is [square of 3m]. The square of 4m is [square of 4m]. The square of 5m is [square of 5m].”
The geometry lab is a room.[/code]
Indeed, z-code behaves differently from glulx. That shouldn’t happen.
If you remove the lines defining cm and km, the code works as it should. But those lines shouldn’t mess anything up. Things are going weirdly wrong: I believe the game thinks that 1 m is 0.1 km, for instance.
I would report this whole example as a bug.
I don’t think it’s a bug. The Z-machine just doesn’t have the capacity to handle large numbers and when you use a scale from 1cm to 1km you need numbers that go from 0 to 100,000 and that’s too much for Z-machine. That’s why the Metric Units extension is Glulx-only.
I noticed that when I was working on the Multitudes extension:
Juhana is correct.
I don’t see why you would need numbers that go from 0 to 100,000? Is there a reason Inform couldn’t store a length as X kilometre + Y metre + Z centimetre? And isn’t is strange that Inform (rather untransparantly) decides to use the smallest unit defined as the unit of length, even though we have defined something else as the unit of length?
I can see why this technical solution was chosen, so I can see where arguments that it is not strange would be coming from. But I don’t think authors can be expected to understand what is going on when you define new measures. If Inform sees it cannot handle these measures, perhaps it should generate a warning at compile time? That would be a lot friendlier than the current behaviour, which amounts to: (a) Inform decides, on its own, how to map the measure on integers; (b) if this leads to overflows, it never tells you about it.
I like the idea of a warning. I7 doesn’t have compile-time warnings, though. Run-time warnings on arithmetic operations would be nice, but inefficient. Maybe in debug mode only?
You can reasonably call a compile-time error in this case, where the largest unit of length is more than 32767 times the smallest unit. Not all cases are as simple, however. If you had lengths scaled from meters to kilometers (factor of 1000), and also areas, then Z-code couldn’t handle a square kilometer – but you don’t want to call that a compile-time error, because a game might very well just need kilometers (of length) and square meters (of area).
I agree with Victor that the approach of basing all unit calculations on the smallest unit is sufficiently counter-intuitive that there should be some kind of warning.
Robert Rothman
This is off-topic, I suppose, but why not? It seems like there are some common things that are probably but not necessarily errors (e.g., “the [kind],” when the programmer usually means “the noun” or “the item described”) that it might be a good idea to issue a warning for them.
That’s a poor example – “the KIND” really should be an error. (There’s a feature request in on it.)
I found the no-warnings thing strange on the face of it. But then I realized I didn’t miss them. In practice, there are two ways of dealing with warnings – you eradicate all of them, or you ignore all of them. (If you want to pay attention to only some of them, tough luck. In the long run, ignoring some errors means you’re training yourself to ignore all of them. This is true of experienced programmers as well as newcomers.)
So it’s not so weird. Any “This looks wrong, but maybe you meant to do it” warning is better served by a “do it the right way” error. A “That might break under some circumstances” warning (such as this units case) will only annoy the people who are handling the circumstances correctly.
I find warnings useful only in the short term – I might ignore certain things for a few compiles while I attend to other things. This is a weak argument for them, especially in a system meant to be used by people who didn’t grow up with C and lint.
Oh, I forgot the case of deprecation warnings. (Which I7 does do.) Special case, obviously, where the language is changing out from under the source code, and an error is lurking in the future.
I was aware of the feature request, and my first thought when I saw it was “Why not issue a warning?” Figuring that it behaves as documented, and if anyone is using it as documented then disallowing it would break their code gratuitously. But maybe no one actually uses as documented. On warnings in general, you’re a lot more expert than I am.
Maybe it should be deprecated? That’d give people notice to change their source code if they’re using it.
I agree totally, especially how non-strange it became. Still, I wouldn’t mind a Use grammar nazi option or something similar to the deprecation one. I’d rather NOT have extra errors/warnings when I’m coding a first draft, for example. (The standard set’s annoying enough, ha-ha.)
I’d also like to define new Problem messages when someone accidentally misuses an extension I wrote. I think this is already on the suggestions forum.
Where in the documentation are you looking?
Gug, maybe it isn’t. I always thought that it said somewhere in the documentation that “a” and “the” were ignored (except in text substitutions, initial definitions of objects, “two of the devices,” and a couple other situations). But perhaps that’s just Inform folklore. Searching the documentation for “‘the’” doesn’t turn it up (and I’m not about to search it for “the”).
All right then, it’s an error (and should definitely be documented).
You know, I posed a question once before about the differences between the z-machine and glulx.
Why now, does I7 have the z-machine as the default compiler? Why aren’t all new games set to glulx by default? If the z-machine can’t handle large numbers such as for metric conversions, maybe it’s a bit outdated for modern IF. Offering the z-machine at all may be just perpetuating a system with issues.