[ET Trac] [Einstein Toolkit] #1958: parfiles accept 1.0, 0.0, 1e3 for integer typed parameters

[Einstein Toolkit]

#1958: parfiles accept 1.0, 0.0, 1e3 for integer typed parameters
-----------------------+----------------------------------------------------
  Reporter:  rhaas     |       Owner:                     
      Type:  defect    |      Status:  new                
  Priority:  optional  |   Milestone:  ET_2016_11         
 Component:  Cactus    |     Version:  development version
Resolution:            |    Keywords:                     
-----------------------+----------------------------------------------------

Comment (by knarf):

 I agree with Steve here. Let me summarize.

 We have the cases
 {{{
 int/int without remainder
 }}}
 I believe we should allow this, and make the result an integer. Assigning
 integers to reals takes care of real parameters.

 {{{
 int/real
 real/int
 }}}
 Those have to be reals. The question remains what to do with reals that
 could be represented as integers, in case this would be needed (e.g.,
 variable assignment). We have this question in multiple places, so let me
 call it 'Q'.

 {{{
 int/int with remainder
 }}}
 This is a question up for debate. Possibilities are
 1) Treat '/' as integer division, throwing away the remainder
 2) Treat '/' as integer division, and making a non-zero remainder an
 error.
 3) Treat '/' as usual division, making the result always a real. Question
 'Q' becomes an issue.

 My thoughts:
 1) This is the C/C++ way of handling this, but is dangerous. I would like
 1/2 to mean 0.5, not 0.
 2) This is better than 1), but I like 3) more.
 3) I think we should be able to use 1/2 as 0.5. But this assumes we can
 treat certain reals as integers where necessary, or that we introduce a
 separate integer division operator for when this would be needed.

 'Q': If we would convert reals to integers where possible without loss, it
 would mean we can safely use 1/2 to mean 0.5, but we would get an error if
 we'd assign that to an integer parameter. At the same time, 2/2 could be
 use there.

 My personal verdict: I liked the way it was before: with automatic
 conversion where possible.

 One problem I could see is 'real' precision, e.g., 3*(1/3) not being
 exactly '1', and with that, not being converted to an integer.

 The question of implementing the 'where possible' correctly is a separate
 issue.

-- 
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1958#comment:22>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit