lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[lmi] Swiss-cheese input sequences


From: Greg Chicares
Subject: [lmi] Swiss-cheese input sequences
Date: Tue, 18 Oct 2011 13:13:32 +0000
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11

Five of the sequences in 'input_seq_test.cpp' are rejected by the GUI
input-sequence editor. Most are diagnosed as invalid (though the unit
test doesn't inspect the diagnostics as it should). One or two others
are dubious, e.g.:
  1 [1, 2); 3 [3, 3]; 5 (4, 5]; 7
which would be realized thus:
  0, 1, 0, 3, 0, 5, 7, 7...
What's interesting about that case is that a default of zero fills the
"holes" [0,1), [2,3), and [4,5). At present, formatted_diagnostics()
finds no problem with it, but in 'input_sequence_entry.cpp' it violates
an assertion (and if we plug the hole at [0,1), then it violates a
different assertion). Should a sequence with such "holes" be allowed?

I believe it should be forbidden. One reason is that a really good
default might fail to exist. Consider payment mode, chosen from:
  {annual, semiannual, quarterly, monthly}
Some policies permit only a single annual premium, while others are
customarily paid through monthly payroll deductions; there is no
universally appropriate default. Zero may seem to be a reasonable
default for currency amounts, but it's not very reasonable for the
initial premium. Besides, it's better to specify every amount without
relying on an invisible default that might someday need to change.

Moreover, half-open [begin,end) intervals in origin zero were added
primarily so that compact, unambiguous error messages could be written.
They were not intended to permit anything that cannot be expressed
directly in other forms--in particular sequences whose intervals are
not contiguous, which AFAICT can be expressed only this way. Interval
notation may appeal to programmers and mathematicians, but typical end
users would never see the assertions in 'input_sequence_entry.cpp' fire
because they'd never use this notation.

At the moment, I have no wish to modify the input-sequence class in
order to forbid sequences with "holes", when it has more important
documented defects. But someday it should be changed in line with the
assertions in the GUI. The GUI is fine as it is.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]