Re: textToIntevsal(s) and exceptions
Oliver & All,
I have been quiet for a while mostly due to teaching, but hoping to pick up now.
On Mar 23, 2015, at 2:22 PM, Oliver Heimlich <oliver@xxxxxxxxxxxxxxxxxxx> wrote:
> Am 23.03.2015 um 18:14 schrieb John Pryce:
> …
>>
>> ===============
>> 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.
Yes, the answer is No, at least for C++: one cannot overload based on return values.
>
> 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.
I find it simpler to have infsup implementing the bare textToInterval, and if we need to construct a decorated interval then do newDec and avoid infsupdec. I prefer that a function does one thing only.
>
> 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.
I agree that it needs to be seen. However, I feel it will be better to promote explicitly and let the compiler
force me to do this.
> 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
My preference would be
x = textToInterval("[1,2]"); # [1, 2]
y = textToInterval("[1,2]"); # [1, 2]
z = textToInterval("[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)
and then e.g.
newDec(y) + z # [2, 4]_dac (decorated operation evaluation)
or when creating y do
y = newDec(textToInterval("[1,2]"));
and then
y + z
The code is not as "clean", but I think it is more readable in the sense that it helps me not to miss
what is going on.
Also, in an implementation, I would prefer to keep the function names as in the standard, or as close as possible.
Regards,
Ned