[ET Trac] [Einstein Toolkit] #1595: Is *) allowed as upper boundary for a parameter range?

[Einstein Toolkit]

#1595: Is *) allowed as upper boundary for a parameter range?
-----------------------+----------------------------------------------------
  Reporter:  eschnett  |       Owner:  sbrandt            
      Type:  defect    |      Status:  reopened           
  Priority:  minor     |   Milestone:  ET_2015_05         
 Component:  Cactus    |     Version:  development version
Resolution:            |    Keywords:  postrelease        
-----------------------+----------------------------------------------------

Comment (by rhaas):

 > - disallow open/closed specifications for integer ranges (they are not
 necessary, and are confusing)
 Fine with me.

 > - disallow strides for real ranges (they cannot be implemented correctly
 due to round-off, except for integer multiples of powers of 2)
 Fine with me in principle, yet Ian's comments on possibly breaking things
 for no good reason apply since right now one CAN use these options, they
 are just not documented (same as quotes around ranges)

 > - disallow {{{1::2}}}, since we don't allow omitting range endpoints in
 any other case either
 They are already not usable since an earlier part of the Perl parser
 breaks. They are however documented as an option in particular the docs in
 UserGuide.pdf section C1.4.1 explicitly say that "A missing end of range
 (or a ‘*’) implies negative or positive infinity." so this is actually a
 bug. Independent of this it would be good to fix the parser so that it can
 handle "::" in the range eg for string type parameters where "::" appears
 if one wants to construct a fully qualified grid variable or parameter
 name (currently we work around by usin "THORN[:][:]PARAMETER").

 > - disallow {{{f}}} and {{{l}}} suffixes, since the parser doesn't handle
 them, and we interpret all numbers as {{{CCTK_REAL}}} and {{{CCTK_INT}}}
 anyway
 Fine with me. Needs update to the docs.

 > - continue to accept {{{d}}} for exponents for backward compatibility
 without warning, but advise against it in the documentation
 This never worked since the C code always just passed the string to strtod
 which does not handle "d". This bug was introduced in a2c2335 by me. Right
 now only parameter ''values'' in par files can use "dD".

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