I might have found a bug in one of the arithmetic routines. When I try to convert a decimal fractions to an integer, it seems to repeat the last digit; e.g. 0.7 becomes 77 instead of 7.
Here is the code and the result.

To decide what number is silverv :
let G be floor of money of player to the nearest whole number; [convert to integer]
say "[line break]gold = [G]";
let Sr be money of player - G;
say "[line break]spr = [Sr]";
let S be (Sr * 10) to the nearest whole number;
say "[line break]sp = [S]";
decide on S;

Hmm. If you break up (Sr * 10) to the nearest whole number into two lines, it works, apparently. Not sure why. I do know that, yes, arithmetic is messed up in Inform 7.

Ha! I figured it out I think. Thereâ€™s no full stop at the end of your line

I think part of the problem is that the arithmetic functions are not as expected. The int() function actually ROUNDS to the nearest integer, instead of truncating as most int() functions do (every one Iâ€™ve found, actually). What I need was the floor() function, which removes the decimal fraction and converts from a real number to a number.

I made my on trunc() function. I was able to get what I wanted with this code. The phrase â€śto the nearest whole numberâ€ť converts from a real number to an integer number.

To decide what number is silverv :
let G be goldv;
let Sr be money of player - G;
let S be (Sr * 10) to the nearest whole number;
decide on S;

Thatâ€™s all I have: the To decide phrase to produce silverv. This Decide rule works.
For the problem with the arithmetic function, see the topmost post when I opened the topic.

But whatâ€™s calling for this decision? Is whatever is asking for the decision also printing something? It must because where else is that â€śfinal spâ€ť coming from in your output?

Like Bosh suggested, you could try adding either a period or a line break to the end of

say "[line break]sp = [S]";

then test again to see if you get the same output or not. It seems likely the break will happen between the two 7s