Re: Draft decoration system for discussion
On 2012-12-13 09:03:33 +0000, John Pryce wrote:
> The simplest is not to allow any interval objects computed at one
> threshold to be input to operations at a different threshold. One
> can't tag an individual interval with a threshold value (no room in
> a "compressed" object for this). One might have a way to "kill" all
> existing compressed objects at run time when the threshold changes.
> Or statically stop it ever being possible.
I don't think you can do that with every language, in particular
in the case of a library implementation. This would mean that the
implementation would have to record every interval object creation
and destruction. This would be complex and take time (possibly more
than using uncompressed IA or tagging intervals), in particular
with parallel applications, where intervals could have been sent
to a different machine.
> Or you could think of other solutions no doubt.
How about changing the spec to:
If xx is the empty interval, return (yy,dy) = (Empty,emp).
If xx is a non-empty interval, return (yy,dy) = (xx,t)
where t is the threshold.
If xx is a decoration d:
If d is ill or emp, return (Empty,d).
Otherwise return (Entire,d).
It's still up to the user to make sure that the non-empty interval
case is correct in his application if he has increased the threshold
before doing normalInterval(xx). However nothing invalid can be
returned.
> I suggest a "statically stop it" solution by saying that at Level 2
> there be a separate compressed type for each threshold value.
But what about languages that are not strongly typed, or dynamically
typed languages? In the latter case, this would be equivalent to
tagging.
An implementation could be allowed to have separate compressed types
and forbid things like implicit type conversions and/or operations
between different compressed types, but this should not be required.
--
Vincent Lefèvre <vincent@xxxxxxxxxx> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)