#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.