Re: On Arnold's challenge & Paul's Observation...
> Subject: RE: On Arnold's challenge & Paul's Observation...
> Date: Fri, 28 Nov 2008 14:59:22 -0700
> From: "Kreinovich, Vladik" <vladik@xxxxxxxx>
> To: "Dan Zuras Intervals" <intervals08@xxxxxxxxxxxxxx>
> Cc: <stds-1788@xxxxxxxxxxxxxxxxx>
>
> Dear Dan,=20
>
> I think we are converging.=20
>
> I of course understand that in interval computations (if done right), we
> always get an enclosure, the difference is whether we get a narrower or
> wider. (But thanks for a good example anyway.)=20
>
> I think we agree on almost everything, including the need for two modes,
> with or without transformations, our main (reasonably minor) general
> disagreement is what is the default use of intervals
Actually, while I agree with the need for more than
one OPTION that the user might want to use in the
interpretation of his code, I would hesitate to use
the term 'modes' to characterize those options.
Perhaps this is a nit. Your call.
>
> * I think that the default mode should be an inexperienced user (at
> least this is our objective, to make currently inexperienced user use
> intervals more), i.e., a user who placed an expression because this is a
> mathematical expression, not because he or she knows how an interval
> compiler will process it
I will go so far as to say that statistically, at least,
the vast majority of users will fall into the catagory
of 'inexperienced' WRT the idiosyncrasies of intervals.
So vast, in fact, that the exceptions can be measured in
parts per million.
>
> * you think that by default, we should assume that the user is a
> specialist, and allow to switch off this feature (and enable
> optimization).=20
Not precisely. I believe no matter how likely it is to
be true that, by default, we cannot assume the user wants
the value of his expressions changed by a 'friendly'
compiler into something other than what was asked.
It is not a question of who is right or who is better.
It is a question of who has the right to choose.
If we do what is asked of us (by default) and provide a
battery of alternatives (for the user to choose) then I
believe we are doing the right thing.
If we help the user silently or without permission then
I believe we invite trouble.
>
> This may be a minor point, as long as both options are available.=20
>
> If you still believe that we have a more serious general disagreement
> let me know.=20
>
> Vladik
>
> P.S. There seems to be, however, a minor misunderstanding still about
> your specific original transformation example, and I think this is why
> you may have missed the point of my original posting: the motivation for
> the transformation listed below is NOT the assumption that x is the
> dominant term. The motivation is COMPLETELY DIFFERENT:=20
Ah, english is such a poor medium for the exchange of
ideas. Made all the worse by the medium of email.
When I mention the unstated motivation, I refer to the
mathematical motivation (or justification) for the
transformation in question.
I understand that your motivation was to reduce the use
of each interval to a single instantiation. I think
that can be assumed even in expressions too complex for
algebraic rearrangement.
>
> * in the original form, straightforward interval computations lead, in
> general, to excess width because x occurs twice,=20
>
> * while in the transformed expression, each variable occurs only once
> and therefore (ignoring rounding and overflow) we get the exact range.=20
>
> . . .
>
> Let me give a more trivial example. Yes, even with 2x-x there can be an
> example when 2x leads to an overflow. Does this mean that we should not
> replace it with x? It may be that a programmer used some ingenuity and
> 2x-x is exactly what the programmer wanted, but to me, this is a rare
> situation (see the above description of our minor disagreement).=20
Ah, a MUCH better example. Do I believe that 2x-x
cannot be (or should not be) replaced by x?
Yes, that is exactly what I believe.
While I might have no idea why a programmer might use
the expression 2x-x rather than the much simpler x I
also believe that such a tortured expression must be
respected if only BECAUSE the programmer went out of
his way to express it in that way.
I have no problem with a compiler that warns the user
"hey, guy, you know that '2x-x' can be replaced by 'x'
don't you?" so long as it compiles it as 2x-x.
I also have no problem with a (non-default) compiler
option that the programmer can choose to make such
transformations automatically. Or a lint-like scan
of the programmer's source that points out how many
things might be changed for the better.
So long as the user is made aware of all these things
we are in good shape.
For, after all, how else are we to transform all those
inexperienced users out there into interval professionals
but by showing them better ways of programming?
>
> If we do not allow any automatic transformation, then inexperienced
> programmer will be forced to get their results via straightforward
> interval computations only -- which of course will lead to huge excess
> widths.=20
Yep. That is the danger we (and they) face.
>
> My apologies if you have understood this from the very beginning when
> replying to my email.=20
>
You have nothing to apologise for. I believe we have
understood each other as well as any can given our
medium of exchange. It is simply that we come at
the problem from two different perspectives.
Besides that, I am infamous for my poor prose style.
Ask anyone at 754. Almost none of my words ended up
in the document without major rewrites.
I do better in person. I'll stand you dinner next
time you're in the San Jose area & we can find out.
Anyway, I've enjoyed the discussion.
Dan