| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Dear Arnold, Here are some comments on your document. While reading it, I tried to keep an eye on what had already been achieved on the C++ proposal for intervals (I have just added links to it on the wiki). - I find it strange to mention "standard intervals" and "non standard intervals". I would just focus on intervals (your current standard intervals), and not mention non standard intervals. Otherwise it looks like we put some constraints on something we don't do completely and that we want to be out of scope of the document. IMO, better leave them away, otherwise all functions would have to mention "the behavior for nonstandard intervals is not specified", like 1.5.8). This affects for example the isStandard() and standard() functions in 1.5.1/1.5.2, which could be replaced by an isValid() function. - 1.5.4 : isEntire() is nice, maybe it would be nice to add isPositivelyBounded() and isNegativelyBounded() ? Or intervalClassify(), similar to C99's fpclassify() ? Other suggestion : isSingleton() ? (there may be other ideas in the C++ proposal, feel free to have a look at it) - 1.5.6 : anyInterval(l,u) : what happens if e.g. l>u ? Should some "undefined behavior" notion be defined somewhere and used here? - 1.5.7 areDistinct() : this is syntactic sugar for the language level, I would remove it from here. - 2.6 "Exact expressions" : I was wondering what the reason of this was. I see 2 reasons : * being able to parse a complete expression: it seems like this belongs to the language level. * being able to get tighter intervals for constants which you want to specify as simple expressions. This is a good thing, but I think we can generalize it to any kind of sub-expression, not only those exact "constant" expressions. The idea is that we should allow an implementation to produces tighter results for combined operations when it can do so. For example, it should be possible to turn the function "(x/7)*7" into "x", or turn "sqrt(x*x)" into "abs(x)", since these transformations produce proovably tighter intervals compared to the step-by-step evaluation, and the containment guarantees are still there for the whole function. Unless I miss some arguments which would make these transformations invalid for some applications, I think that we should mention it, otherwise we may prevent some optimization opportunities. - 2.8 : (exact interval -> text conversion): just a note : it is possible to exactly represent binaries in decimal text, you may only need many digits. - 3.3 : (accuracy levels) : should we add that "empty" always propagate? (the c++ proposal explicitly has "all functions, except set operations, taking the empty interval as argument must return the empty interval.") - Remark 3 at the end of Part 3 : should we have several levels of conformance? Just a data point wrt C++: my belief is that it is unlikely that the C++ standardization committee accepts a complete proposal including all hard-to-implement functions, as part of the C++ standard proper. We may end up with a separate document (still validated by WG21 though). That said, I am thinking that it might be possible to split the functions into an easy-to-implement base (no elementary functions, only +, -, *, sqrt and set operations), which could be part of the C++ standard proper, and the other functions part of a separate document. If this combination is accepted, then it would be nice to refer to "the C++ standard implements IEEE-1788-part1", and "the C++ interface to IEEE-1788-part2 is available in this other official document". That's an argument for having several parts, and with this particular split in mind. - 4.2 (Boolean valued operations) : comparisons should also mention == and !=. Moreover, you mention 3-valued return value, but it may be desirable to have a 4-valued return value. This is what we did for the C++ proposal where interval comparisons return std::bool_set which stands for "true", "false" "true or false" and "neither true nor false". In practice, the last value is returned when you compare against the empty interval. You get more information out of the comparison (the empty interval propagates :) ), and there is no significant added cost. - 5.1 (float -> interval) : apart from the arguments already raised, I think that writing "floating-point or integer x converts to interval [x,x]" is wrong if we consider cases like 32-bit integer conversion to interval<float>, or 64-bit "double" converting to interval<float>: the input floating-point or integer may have more precision that the bounds of the interval, in which case a conversion cannot be made to a singleton interval. In general, for finite values, can't we simply require "the tightest" conversion instead? -- Sylvain Pion INRIA Sophia-Antipolis Geometrica Project-Team CGAL, http://cgal.org/
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature