Re: [lmi] Why not DBL_MAX?

[Evgeniy Tarassov]

On 3/26/07, Greg Chicares <address@hidden> wrote:
> On 2007-3-26 10:05 UTC, Evgeniy Tarassov wrote:
> > On 3/24/07, Greg Chicares <address@hidden> wrote:
> >> 20070316T1310Z_DBL_MAX_to_static_limit_maximum.patch
> > [...]
> >> makes good sense. But why use this:
> >>     double stratified_entity::limit_maximum = DBL_MAX;
> >> instead of just writing DBL_MAX?
> >
> > Only to simplify the code. So that the same constant is named the same
> > way everywhere it is used. And of course only where it has the same
> > semantics.
>
> This limit is inherent in the problem domain: the last interval
> has no finite upper bound in the real-number system. I find it
> less simple to express that other than by DBL_MAX in computer
> floating point.
>
> This patch would also change a 'my_*' file. Such files have

Oh, I was not aware of such a 'point of extension'. I just read the
description for the 'my_*' files.

> proprietary versions that are used only to build programs that
> create product files--programs that aren't distributed, and
> whose source doesn't appear in any public cvs. Any change in a
> public version calls for changes in the proprietary version;
> it's not obviously certain that they won't be problematic in
> some surprising way. I'd rather not open that can of worms.

And of course changing DBL_MAX to something else is not compelling
vis-a-vis compatibility with the existing user code.

> >> Is there some arcane reason, e.g., that this quantity:
> >>     static double const max_double = std::numeric_limits<double>::max();
> >> in a removed line might not equal DBL_MAX for some woeful
> >> compiler? (Really old versions of MinGW gcc did have an
> >> incorrect value for DBL_EPSILON.)
> >
> > I don't know, but using the same value (DBL_MAX or
> > stratified_entity::limit_maximum), it ensures that the program will
> > not produce bogus output for such a compiler.
>
> If we're really concerned that
> >>     static double const max_double = std::numeric_limits<double>::max();
> doesn't equal DBL_MAX, then we could change 'tier_view_editor.cpp':
>
> -        limits().push_back(max_double);
> +        limits().push_back(DBL_MAX);

Yes, that was my first reflex -- to change max_double to the same
constant from stratified_charges. And then i saw the <cfloat> include
and by reflex changed it into a static constant variable of the class.
I mean that i completly agree that the line:
 limits().push_back(max_double);
has to be corrected to whatever is used in stratified_charges.

[...]
> > by grepping 'limit_maximum' one will only find occurences of this
> > constant for cases where it is used for stratified_entity limit array
> > values 'terminator'. When one sees DBL_MAX it only says the exact
> > value, not the real meaning of the constant in the local context.
>
> because it's defining the problem in terms of the real number
> system. If it's not sufficiently clear with the above changes,
> then let's further improve that documentation of the problem
> domain. But I don't want to change old code in a way that, to me
> at least, makes it less clear to those who have already read its
> documentation and understood the problem domain.

Ok.

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

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

The basic idea: to automatically sort the bands upon user editing the
data. If a value entered for a limit makes limits array not sorted,
then to find the correct position for the band and move it there (also
moving the selection in table grid).
 5, 15
 10, 25
 100, DBL_MAX
User selects first band and starts editing limit (* is the cursor)
 5, 15*
 10, 25
 100, DBL_MAX
User changes 15 to 95
 5, 95*
 10, 25
 100, DBL_MAX
User hits enter. Bands are automatically reordered:
 10, 25
 5, 95
 100, DBL_MAX

There are other approaches:
- to present an error box if the entered value makes limits to be unsorted
- to correct the neighbor bands automatically to preserve the array
non-decreasing order

IMHO all such automatic things could be annoying for a person who
tries to enter his data quickly and do not loose any existing data
(for example mistakenly adding an extra-zero to the entered value).

--
With best wishes,
Evgeniy Tarassov