#1958: parfiles accept 1.0, 0.0, 1e3 for integer typed parameters -----------------------+---------------------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: optional | Milestone: Component: Cactus | Version: development version Resolution: | Keywords: -----------------------+----------------------------------------------------
Comment (by rhaas):
I admit to being confused. Since the check only happens at runtime (when the .par files are read) then compilation seems to not be sufficient (also since C++ will let you do "int a = (double)b"). I would also expect that all tests in the testsuite will pass since the pre-piraha parser would allow 1.0 so no test could rely on it. It would however be good to check if things like: {{{ thorn::par = 2*1 }}} still work after the change or not. Please note that I am only suggesting that {{{ thorn::par = 1.0 }}} should fail, not {{{ thorn::par = 1.0*1 }}} (mostly since the later would require that we re-introduce integer arithmetic into the evaluator if all arguments of an expression are integers).
If you make the change, please also update the user guide which currently states that "In cases where this is clear, types will be converted, e.g. 3.0 will convert to an integer, but not 3.1." in section B 3.2. Booleans being represented as {{{CCTK_INT}}} is documented in the UserGuide (section C1.6 section "Parameters" in my current checkout) documenting C's convention for true/false. There is however a body of Fortran code around that uses {{{param.eq.1}}} to test for truth rather than the more correct {{{.not. (param.eq.0)}}}, so at least for the actual code we are stuck with representing true/false as 1/0.