OMNeT++/OMNEST Bug Tracker - OMNeT++
View Issue Details
0000115OMNeT++IDE / INI editorpublic2009-11-13 11:122010-04-26 10:26
jeromerousselot 
andras 
normalminorhave not tried
resolvedfixed 
4.0 
4.1 
0000115: when defining many values for an iteration variable, the upper bounds of a range is ignored if the step is fractional

When defining an iteration variable 'distance' in an ini file that includes several ranges, the last value of a range is ignored when the step is not integer.
Example:

sim.node[1].mobility.x = ${distance=1..4 step 0.2, 5..10 step 1, 15..50 step 5, 60..100 step 10}

leads to the value 4 being skipped:
1, 1.2, 1.4, 1.6, ... 3.4, 3.6, 3.8, 5, 6, 7, 8, 9, 10, 15 ... 50

It's not that the run is not executed: everything runs as if I had entered:
sim.node[1].mobility.x = ${distance=1..3.8 step 0.2, 5..10 step 1, 15..50 step 5, 60..100 step 10}

Workaround: include the missing value twice.
sim.node[1].mobility.x = ${distance=1..4 step 0.2, 4..10 step 1, 15..50 step 5, 60..100 step 10}
No tags attached.
Issue History
2009-11-13 11:12jeromerousselotNew Issue
2009-11-13 12:07jeromerousselotNote Added: 0000194
2010-04-25 19:55andrasNote Added: 0000249
2010-04-26 10:26andrasNote Added: 0000250
2010-04-26 10:26andrasStatusnew => resolved
2010-04-26 10:26andrasFixed in Version => 4.1
2010-04-26 10:26andrasResolutionopen => fixed
2010-04-26 10:26andrasAssigned To => andras

Notes
(0000194)
jeromerousselot   
2009-11-13 12:07   
Actually this doesn't happen all the time. The line described above leads to the correct number of runs.

I will update this bug with an iteration variable definition that does lead to the bug.
(0000249)
andras   
2010-04-25 19:55   
This is likely because 0.1 cannot be represented in floating point exactly, so the internal iteration variable does not become 4.0 but e.g. 4.00000000001.

A possible fix is to include the end value if the iteration variable gets very close to it (e.g. within 1% of the step value).

envir/valueiterator.cc
(0000250)
andras   
2010-04-26 10:26   
Use upper bound + 0.000001*step instead of upper bound, to mitigate the effect of floating point rounding errors