Money and Price Problems

Hello out there. I ran into some problems trying to create a money kind where I could change the dollar amount during play. Even putting [vTotalPrice] in a say statement causes an error. This is the code:

Ottawa is a room.

vHasCustomer is a truth state that varies. vHasCustomer is false.

Price is a kind of value. $10.99 specifies a price.
A thing has a price. The price of a thing is usually $0.00.

After examining something for sale:
	say "It can be yours for [the price of the noun]."

Definition: a thing is free if the price of it is $0.00.
Definition: a thing is for sale if it is not free.

vTotalPrice is a kind of thing. The price of vTotalPrice is $0.00.

Every turn when vHasCustomer is false:
	If a random chance of 1 in 2 succeeds begin;
		call taxi service;
	end if.

To call taxi service:
	say "You call a taxi.[line break]";
	now the price of vTotalPrice is $25.00;
	say "The cost of the taxi ride will be [vTotalPrice]";

The errors are as follows:

Problem. In the sentence ‘now the price of vTotalPrice is $25.00’ , it looks as if you intend ‘the price of vTotalPrice’ to be a property, but ‘a vtotalprice’ is not specific enough about who or what the owner is.


Problem. You wrote ‘say “The cost of the taxi ride will be [vTotalPrice]”’, but ‘vTotalPrice’ is used in a context where I’d expect to see a (single) specific example of a sayable value, not a description.

I tried everything I knew for several hours, Hunted for solutions here and on Google with no luck.

I need to store a dollar amount in a variable for calculations later in the game.


I think the compilation problem is that you have said “vTotalPrice is a kind of thing,” but there’s only one vTotalPrice, so you should say just “vTotalPrice is a thing.” That’ll create a specific offstage thing called vTotalPrice, which you should be able to manipulate as you want.

However, I’m not sure why you need vTotalPrice to be a thing–if all you need to do is store a dollar amount, you can make a variable holding a price like this:

vTotalPrice is a price that varies.

And then you can directly set vTotalPrice instead of “the price of vTotalPrice.” (Note that if vTotalPrice is a thing, “[vTotalPrice]” will print its name rather than its price–if you make it a price you won’t have that issue.)

Thank you Matt. This works perfectly.

Another question:

I need to add 15% gratuity to vTotalPrice. When I do this: “now vTotalPrice is vTotalPrice times 1.15;”, it gives me an outrageous dollar amount. It should be $28.75 but the answer is in the thousands.

Thank you for your help.

I think adding 15% should be vTotalPrice plus (vTotalPrice times 0.15).

The way you have it, you’re multiplying the price times itself plus an additional 15 percent.

10 x 10.15 = 101.5
10 + (10 x 0.15) = 11.5

Does not work.

I tried:

 now vTotalPrice is (vTotalPrice plus (vTotalPrice times 0.15));

but the answer is $11363639.72 instead of $28.75. (very weird)

I really want vTotalPrice to be $25.00 plus 15% tip = $28.75.

Price is a number that varies. Price is 25.
to say gratuity of (n - a number):
	say "[n times 0.15]".
To say plus tip of (n - a number):
	say "[n + (n times 0.15)]";

When play begins:	
	say "The bill is [price] plus [gratuity of price], so [plus tip of price] total.";

The bill is 25 plus 3.75, so 28.75 total.

I’m bad with math, but Inform can do it. Now the trick is getting values instead of to-say phrases, which may involve the bug @matt_weiner details below.

That’s not something you’re doing wrong–it’s a bug in multiplying multipart units by real numbers. More here; reported zarf had a workaround here but I think ultimately that OP decided it was better to forget about cash value in their game–which is not what I’m recommending here! But you might want to check that out.

1 Like

Thank you all.

I will take Matt’s proposed solution and change the dollar amounts to real numbers. Once done, Hanon’s way of computing the percentage will work like a charm.

Thanks again.

[EDIT: crosspost with Gilles’s last post!]

Or you could just make prices into real numbers like Hanon did! One thing about that is that you’d have to write something to make sure it prints $4.20 instead of $4.2 when necessary–I think in the other thread I linked I posted some code to do that but I’m not sure how well it works.

Also if you’re using the real numbers solution you probably want to make sure to write “[price to two decimal places]”, in case you ever have to leave a tip on 23.25 or something else that doesn’t multiply to an even number of cents. I’m not sure how that might interact with whatever you might use to print trailing zeroes, if that’s an issue!

I don’t have I7 on this computer so this is a shot in the dark, but:

Price is a kind of value. $9.99 specifies a price with parts dollars and cents (optional, preamble optional).

To decide what real number is (P - price) as a value:
    decide on the dollars part of P plus ((the cents part of P) divided by 100.0).

To decide what real number is the fractional part of (R - real number):
    decide on the remainder after dividing R by 1.

To decide what number is the integer floor of (R - real number):
    decide on (the floor of R) to the nearest whole number.

To decide what price is (R - real number) as a price:
    let D be the integer floor of R;
    let C be ((the fractional part of R) times 100) to the nearest whole number;
    decide on the price with dollars part D cents part C.

To decide what price is (R - real number) percent of (P - price):
    let P2 be P as a value;
    let P2 be P2 times (R divided by 100);
    decide on P2 as a price.

When play begins:
    say 115 percent of $1.75.

See if this works? Sadly I can’t test it myself so this may not work at all. But it’s based on WI§15.15.

In this case “floor” still yields a real number, so you should change “let D be the floor of R” to something like

  let D be (R minus the fractional part of R) to the nearest whole number;

(I can’t run Glulx projects on my Inform IDE though so I haven’t been able to check whether the code actually works.)

Now that’s a bit bizarre. Added an “integer floor” phrase now to get around that.

Wow. Thanks for the code. I tried Daniel’s code but it gives double the 15%. So 15% of $25, Daniel’s code gives $7.50 instead of $3.75.

Anyways, I fixed my problem by hardcoding the percent values into variables. I only needed to calculate 15% on 6 different dollar values, so now the percents are hardcoded.

If a working solution shows up, I will definitely use in my game.

Thanks a bunch.

Hmm. That’s odd. I can find my I7 machine and debug it further if you want, but it sounds like you have something else that works.

Daniel, your code example is very close.

Your code: say 115 percent of $1.75 = $2,30

But the actual result should be $2.01

If you want to spend time to tweak your code, it would be greatly appreciated as I could use it for other calculations (such as calculating sales tax on a purchase).

Just don’t spend too much time since I got my game to work with hardcoded values.

Thanks again.

Looks like it’s an integer/real-number problem: this works for me:

To decide what real number is (P - price) as a value:
    decide on the dollars part of P plus ((the cents part of P) divided by 100.0).

Does the Inform documentation have information about “operator” precedence? Coming from other languages, it seems backwards that “divided by” binds more loosely than “the cents part of”.

Hey Josh, you got it. It works.

Wow, such a big mess of code just to do a simple percentage calculation.


I’m not sure how well it’s documented, but operator precedence in Inform is kind of a mess IMO. Graham has said that by design “6 - 4 / 2” is different from “six minus four divided by 2”: “Arithmetic symbols obey the usual mathematical rules, but English doesn’t.”

Things get pretty unpredictable, to me, and I find the safest thing is to put in lots of parentheses if I’m in any doubt.

Aha! Thank you; edited that fix into my original post. Inform’s operator precedence is a mess sometimes.

Yep…you should be able to say “$12.34 times 1.5”, but that gives wildly incorrect results. It’s a known bug that’s been around for several years now.