Bugzilla – Full Text Bug Listing
| Summary: | Smallfloat to string conversion does not agree with javagen | ||
|---|---|---|---|
| Product: | z_Archived | Reporter: | Kathy Carroll <carrollk> |
| Component: | EDT | Assignee: | Kathy Carroll <carrollk> |
| Status: | CLOSED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | hjiyong, jeffdouglas, jqian, mheitz, svihovec, tww |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
I spoke with Tim about this one as well, and we both agree that the behavior should be the default for the platform being used. For example, in Java: double actual = 2.539E7; System.out.println(actual); System.out.println(String.valueOf(actual)); prints: 2.539E7 2.539E7 In EDT, Java prints the same thing. We should write the code above in JavaScript outside of EDT, and the same behavior should occur in what we generate for JavaScript in EDT. NOTE: If you are reading this and say to yourself, "this is going to change a lot of things", please discuss this in more detail with Tim, Brian, and Jing before making the changes. I would rather let this one test case fail for .7 than start making fundamental changes in our generated code at this point. After thinking about this more, I think we should defer this one until we have time to discuss the implications of the change I proposed. According to comment 1 by Brian, I try it in pure javascript, the string value is 2539000 the same as EGL result. <script type="text/javascript"> var actual = 2.539e7; //also try 2.539E7 alert(actual); alert(actual.toString()); alert(""+actual); </script> So I think this is not a bug but a platform difference. So route this bug to Kathy to change the test case of EUnit. Matt, can you review this defect and let us know if you agree with the final decision? +1 I agree, because in cases like this we always defer to the target language. "Cases like this" are situations in which our definition of EGL allows us some leeway, and we have a choice between faster/easier/non-portable code vs. slower/complex/portable code. The leeway I refer to is in the doc comment on EString.asString(ESmallfloat). It says the result "may end with an exponent". It doesn't set any conditions as to if/when the result must have an exponent. Testcase has been modified. java and javascript produce the same result. RBD is the exception. verified with 2/21 build |
Use EUNIT to run the variations package mine; library SmallTester expectedStr string; variation string; function runConversionFunction07(){@Test} variation = "float asString conversion1"; actual float = 2.539E7; actualStr string = actual; expectedStr = "2.539E7"; LogResult.assertStringEqual1(expectedStr, actualStr); end function runConversionFunction08(){@Test} variation = "float asString conversion2"; actual float = -2.539e7;; actualStr string = actual; expectedStr = "-2.539E7"; LogResult.assertStringEqual1( expectedStr, actualStr); end function runConversionFunction09(){@Test} variation = "smallFloat asString conversion1"; actual smallFloat = 2.539E7; actualStr string = actual; expectedStr = "2.539E7"; LogResult.assertStringEqual1( expectedStr, actualStr); end function runConversionFunction10(){@Test} variation = "smallFloat asString conversion2"; actual smallFloat = -2.539e7; actualStr string = actual; expectedStr = "-2.539E7"; LogResult.assertStringEqual1( expectedStr, actualStr); end end