Peculiar result

Authoring Inform 7
1

I am trying to program a mathematically functional calculator. I’m on the first step, entering numbers and displaying them on the calculator. But I get a peculiar result, if I enter a number it registers a different number:

calcvalue is a real number that varies.  calcvalue is 0.0

punching in is an action applying to a real number and one thing.  understand "punch [a real number] into [calculator]" or "type [a real number] on/in/onto/into [calculator]" or  "push [a real number] on/in/onto/into [calculator]" or "input [a real number] on/in/onto/into [calculator]" as punching in when the calculator is held by the player.

carry out punching in:
	now calcvalue is the number understood;

report punching in:
	say "You punch in [calcvalue] into the calculator."

This generates output that is different than the inputted number:

It's a solar calculator with big buttons, the standard 10-key format with merely plus, minus, multiplication, and division and a clear button.  It has a large display.  

The display reads:  0
>punch 5650 into calculator
You punch in 1169199104 into the calculator.

>examine calculator
It's a solar calculator with big buttons, the standard 10-key format with merely plus, minus, multiplication, and division and a clear button.  It has a large display.  

The display reads:  1169199104

Though I’m used to errors (God knows, I make a lot of them), this has caught me totally off-guard. Any ideas as to why this shift in numbers is happening?

1 Like
2

I haven’t tested it yet but my guess is that Inform stores two different values, ‘the number understood’, which is an integer, and ‘the real number understood’, which is a real number. By asking it for ‘the number understood’, it’s giving you the last integer value that mattered, which apparently is 1169199104.

So it should work if you change it to ‘real number understood’.

3

Thank you. BTW I am borrowing heavily from your calculator code. Thank you for sharing. I also found it interesting that you have a PhD, looks like in mathematics. That’s pretty cool!

1 Like
4

That’s funny, I was just looking at my calculator code to try and remember what I had done! And yeah, getting a PhD was fun, although it hasn’t helped much with jobs over the years. Glad to help!

1 Like
5

Yep, there’s actually only a single underlying value for all the different “the [kind of value] understood”. You want “the real number understood”—right now what’s happening is taking the bits representing a real number and interpreting them as if they represented an integer, which isn’t what you want.

5 Likes
6

For those wondering what this actually means behind the scenes, I7’s [<kind of value> understood], whatever the kind of value, is read from the I6 global variable parsed_number - a hold-all variable used by the parser to store the value of any parsed token that is not an object (small-print it’s also used to store the encoded integer value representing a topic/snippet derived from a [text] token).

So ‘[<kind of value> understood]’ means ‘the contents of the I6 global variable parsed_number interpreted as an I7 <kind of value>’.

I7 doesn’t police what token most recently led to parsed_number being altered, so you can use this quirk of the parser to sort-of ‘cast’ between I7 kinds- at least as far as saying them goes:

"Values Understood" by PB

Lab is a room.

A colour is a kind of value. Some colours are red, white, green.

Interpreting is an action applying to one number. Understand "interpret [number]" as interpreting.

Report interpreting: say "The number [the number understood] represents [the colour understood].".

Mumbling is an action applying to one topic. Understand "mumble [text]" as mumbling.

Report mumbling: say "The topic snippet is encoded as [the number understood].".

Values Understood
An Interactive Fiction by PB
Release 1 / Serial number 240317 / Inform 7 v10.1.2 / D

Lab

interpret 2
The number 2 represents white.

mumble oh what a beautiful day
The topic snippet is encoded as 205.

small print parsed_number is not automatically reset to 0 at the start of parsing, so its contents might represent a value token or a topic token parsed in a previous command when no subsequent value/topic token has been parsed to override it.

very small print this means that ‘[the topic understood]’ can lead to a runtime error if parsed_number contains a value not derived from a [text] token, in which case it may contain an integer that is not a valid snippet encoding

1 Like