Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000319Core InformEquations, units, arithmeticpublic2010-10-02 13:322010-10-28 00:30
ReporterRon Newcomb 
Assigned Tograham 
PrioritynormalSeveritymildReproducibilityalways
StatusclosedResolutionfixed 
PlatformPPCOSMac OS XOS Version10.4
Product Version6E72 
Target VersionFixed in Version6F95 
Summary0000319: Checking a truth state fails (via "whether or not")
DescriptionIn the code below, the if-statement [if print-it is true] says false when it should say true. According to the generated I6, checking the value of a truth state variable is done by comparing it to, exactly, 1. But in Inform 6, "true" means "non-zero" not "exactly one", so the below code fails regardless whether the if-statement asks "is true" or "is false".

Either checking truth states could be more forgiving, or, the "whether or not" phrase which typecasts a condition to a truth state could be a bit more vigilant.

Minimal Source Text To Reproduce
"A bit of trouble"

Important num is a number that varies.

Print-it is a truth state that varies.

To decide if (bit - a number) is in the bitfield (bitfield - number):
	 (- (({bit}) & ({bitfield})) -).

When play begins:
	now important num is 5;
	now print-it is whether or not 4 is in the bitfield important num; [ 4 ANDed with 5 should be True ]
	
say "[print-it] [if print-it is true]= true[else]= false".

spot is room.
Additional InformationGenerated I6 code:


[ R_740 ;
      ! phrase 1
      ! [1: now important num is 5]
       (Global_Vars-->9) = 5;
      ! phrase 2
      ! [2: now print-it is whether or not 4 is in the bitfield important num]
       (Global_Vars-->10) = ((( ((4) & ((Global_Vars-->9))) ))) ;
      ! phrase 3
      ! [3: say ~[print-it] [if print-it is true]= true[else]= false~]
      say__p=1;ParaContent(); print (DA_TruthState) (Global_Vars-->10); ParaContent(); print (PrintText) SC_10;
if (~~(((((Global_Vars-->10) == 1))))) jump L_Say1;
ParaContent(); print (PrintText) SC_11;
jump L_SayX1; .L_Say1;
ParaContent(); print (PrintText) SC_12; .L_Say2; .L_SayX1;
   rfalse;
];
TagsNo tags attached.
Effect(serious/mild) Game compiles but misbehaves
Attached Files

- Relationships

-  Notes
(0000654)
Ron Newcomb (reporter)
2010-10-02 13:35

Arrg, somehow the "minimal source text" inserted an extra blank line before the say statement. That line should obviously be in the WPB rule.
(0000657)
jmcgrew (administrator)
2010-10-02 16:36
edited on: 2010-10-02 16:39

Here's another test case that doesn't rely on an I6 inclusion. It should print "true" but instead prints "neither true nor false".

<code>
Home is a room.

To foo, softly, gently, sweetly, or discreetly:
        let F2 be whether or not gently;
        if F2 is true:
                say "true";
        otherwise if F2 is false:
                say "false";
        otherwise:
                say "neither true nor false".

When play begins: foo, gently.
</code>

zarf notes that the phrase "if (sc - scene) has happened" can also return arbitrary nonzero values when true.

(0000658)
zarf (developer)
2010-10-02 19:00

Also note that saying "[truth value var]" uses a zero/nonzero distinction, but "if truth value var is true" tests ==1.
(0000661)
graham (administrator)
2010-10-03 05:11

Possibly we should be more puritantical in type-safety of "truth state", but instead I've changed its comparison schema to

(*1 && true) == (*2 && true)

rather than

*1 == *2

and this solves the problem by making all non-zero integers indistinguishable. (I6 implements && differently from C: it always produces "true" or "false".)

- Issue History
Date Modified Username Field Change
2010-10-02 13:32 Ron Newcomb New Issue
2010-10-02 13:35 Ron Newcomb Note Added: 0000654
2010-10-02 16:36 jmcgrew Note Added: 0000657
2010-10-02 16:36 jmcgrew Severity serious => mild
2010-10-02 16:36 jmcgrew Status new => confirmed
2010-10-02 16:39 jmcgrew Note Edited: 0000657 View Revisions
2010-10-02 19:00 zarf Note Added: 0000658
2010-10-03 05:11 graham Note Added: 0000661
2010-10-03 05:11 graham Status confirmed => resolved
2010-10-03 05:11 graham Resolution open => fixed
2010-10-03 05:11 graham Assigned To => graham
2010-10-25 21:14 jmcgrew Fixed in Version => 6F95
2010-10-28 00:30 jmcgrew Status resolved => closed


Copyright © 2000 - 2010 MantisBT Group
Powered by Mantis Bugtracker