Am 23.03.2015 um 18:14 schrieb John Pryce:
…
I guess you are advising that we should be as un-prescriptive as
possible on things we don't have enough experience to be prescriptive
about. That seems wise.
Following this advice I removed the "each bare constructor shall have
a corresponding decorated constructor" text entirely because it's
hard to define "corresponding" briefly. Instead, after the
definitions of the bare numsToInterval & textToInterval I've put:
===============
1 These constructors shall have decorated versions as follows.
2 – The decorated operation numsToInterval(l,u) has value newDec(x)
if the bare operation has value x.
3 – The decorated operation textToInterval(s) has:
4 – value xd if s is a decorated interval literal of the flavor
with value xd;
5 – value newDec(x) if s is a bare interval literal of the flavor
with value x.
6 A flavor may define extensions of these constructors and/or provide
other constructors.
7 ...[Example about Kaucher improper interval, + giving constructor
an extra argument like Marco's]
...
8 An implementation may relax at Level 2 the accuracy mode ...
===============
Points:
- This is only prescriptive about the two standard constructors
numsToInterval & textToInterval.
- It is short.
- It drops the "Otherwise it has no [common] value" stuff.
- It explicitly includes promotion of the kind Dmitry put in (line 5).
I think it would look weird not to include it.
- In line 4 it refers to the sx_sd syntax, hence this is required in all
flavors.
Thank you, very good! This makes the standard's requirements clear and
reasonable.
One thing that I am missing here: What shall the decorated
textToInterval do, if s is an invalid combination x_xd in the flavor
(e. g. [1, Inf]_com for set-based intervals)? Or should this be
implementation dependent?
For promotion I'm undecided, and wait for advice from language
experts.
If it's part of the standard, does that make it different at
implementation
level, from making it a consequence of library design and language
features,
e.g., by using class inheritance?
Do you have an example?
No, I am hoping you, Dmitry or Marco can provide some. I was
thinking, suppose in C/C++ one has code like
string s = "[1,2]";
decoratedInterval x;
x = textToInterval(s);
and textToInterval *doesn't* implement line 5 in my text above.
Is there any mechanism in the language to make it try *bare*
textToInterval, after *decorated* textToInterval sees s is not a
decorated literal, and then apply newDec?
Now I think about it, I guess the answer must be No, except by
explicitly coding it into decorated textToInterval.
I can give an example with the GNU Octave interval package (version
0.1.4), where “infsup” implements the bare textToInterval and
“infsupdec” implements the decorated textToInterval.
This implementation automatically promotes bare intervals if the user
calls an operations with mixed arguments, i. e. if at least one
operand is decorated. Whether this has been a good or bad decision
remains to be seen. Demotion does not happen automatically and the
user must explicitly call “intervalpart” for that purpose.
pkg load interval
x = infsup ("[1,2]"); # [1, 2]
y = infsupdec ("[1,2]"); # [1, 2]_com (automatic promotion cf. (5))
z = infsupdec ("[1,2]_dac"); # [1, 2]_dac
y + z # [2, 4]_dac (decorated operation evaluation)
y + x # [2, 4]_com (input x became promoted)
z + x # [2, 4]_dac (input x became promoted)