Re: [lmi] Why not DBL_MAX?

[Greg Chicares]

On 2007-3-26 22:49 UTC, Evgeniy Tarassov wrote:
> On 3/26/07, Greg Chicares <address@hidden> wrote:
> 
>> We could have made the upper bound implicit in the GUI, by
>> preventing users from specifying it--for example, by forbidding
>> them from typing anything in the last row of the second column.
>> I didn't do that in the legacy system, though it would have
>> avoided the need to format DBL_MAX in a way that makes sense to
>> users. If you can think of a good way to handle that problem,
>> then the GUI might not need to know about this upper limit;
>> otherwise, it can't be written without understanding this part
>> of the problem domain.
> 
> Ok, I will prepare a patch -- disable editing the last row of the second
> column.

Okay--assuming it's easy enough for you to do. It wasn't easy
with the grid control I was using years ago for the legacy
system. This will be experimental: it's an untested idea, and
we can't really tell whether we'll like it until we see it.
And I'd say you can defer it until later if that suits you.

>> BTW, does the GUI enforce the other problem-domain constraints?
>>   /// Limits are constrained to be positive and nondecreasing.
>> Those constraints really do need to exist in the code, and the
>> GUI should enforce them. I'd rather reuse is_sorted() in file
>> 'stl_extensions.hpp' than rewrite it, of course: it uses an
>> sgi implementation that's been widely exposed for years.
> 
> I will shorty try to add a patch which enforces the constraints on GUI
> level.

[big snip]

Let's pause here.

As a general rule, I'd rather not attempt to correct invalid
input automatically. In my experience, that takes a lot of
effort and doesn't please users. Often the "correction" is
incorrect.

IIRC, a user who tries to save a file that violates the rules
gets an error message. Wendy, would you please take a look at
the current behavior and say whether you think it's already
good enough? Following the behavior of the legacy application
may be good enough for now. We could consider expanding it
in some really simple way, if we can devise one, but I think
it best to keep this very simple.

For instance, I think we've already got:
  if highest limit isn't what it must be
    then complain about that in a messagebox
    (only when attempting to save the file)
If that's working well enough, but it's the only test, then
we might add:
  if any band isn't positive
    then complain as above: "All bands must be positive"
  if bands aren't uniformly increasing
    then complain about that as above

Let's think carefully before doing much more than that.