From: Dr. Olaf Hoffmann <Dr.O.Hoffmann@gmx.de>

Date: Sat, 17 Nov 2007 17:54:51 +0100

To: www-smil@w3.org

Message-Id: <200711171754.51965.Dr.O.Hoffmann@gmx.de>

Date: Sat, 17 Nov 2007 17:54:51 +0100

To: www-smil@w3.org

Message-Id: <200711171754.51965.Dr.O.Hoffmann@gmx.de>

.... > > > > I would like to suggest to use the unbiased or > > 'round to even' method ... > > Working Group Resolution (LC-1801): > Originally the working group had relaxed the definition of rounding so > that it became implementation-dependent how ties were to be rounded. > However, the working group has decided to revert its decision. Rounding > is now once again defined as floor(x+0.5). The reason for this are: > - It is important for interoperability that rounding is well-defined (i.e. > that implementers know what to do); > - This method of rounding was already widely deployed in existing > players; > - There is indeed a bias, but the working group feels that the bias is > small; > - This method of rounding is very easy to implement on small devices, > whereas the method of rounding ties to even is much harder to implement. > > The motto here is "practicality beats purity". > > ---- Well, this argument applies for the strongest caveman with the biggest mace too. However those guys where never under suspicion to be responsible for the progress of mankind or even only to get the Nobel Prize ;o) I think, it is not the task of a W3C recommendation to specify basic cultural methods like additon, multiplication and rounding. Especially not, if the specified method is sloppy and not state of the art, maybe since a few centuries ;o) And the propper method does not depend on feeling or arbitrary desicision, it depends on proofs or in this case on simple statistical calculations. However, this is intended only for integers, not even in general for rounding. What are the main applications for this specification? Values for animateColor? Then we have different notations, we have 'red', #f00, #ff0000, rgb(255,0,0), rgb(100%,0%,0%). Except for the last one, the final value is a vector of three integers, but for the last one it is a vector of three floats. Having sloppy rounding for the integers may result in a different result depending on the notation of the values. And which method has to be used, if there is a mixture? For example the underlying value is rgb(100%,0%,0%), a low priority additive animation used something like values="#00f;#0f0" and a higher priority additive animation uses either those prose values of again percentage notation? Which notation and therefore which rounding method is responsible for the final presentation value? Indeed, for most users and for low quality devices for advertisement and fun applications it will not be important at all - no one will care, whether rounding is done sloppy or not. Therefore those devices have no requirement for a specification of rounding at all and developers will not care anyway. But it is another thing to put such a bloomer in a recommendation to force developers of high quality implementations to be sloppy or to implement low quality methods - this indeed is the method of 'the strongest caveman with the biggest mace beats everything, including purity'. And guess, what will be the relevant source for the question of propper rounding, a SMIL recommendation or books about mathematics and statistics having proofs for the method with the minimal statistical errors and without a bias? And guess what is the impression about SMIL for authors with high requirements on the meaning of there documents, if they read such bloomers in the recommendation? For such authors, having for example documents for scientific or educational purposes, 'elearning', the quality of the document depends on a propper recommendation, not on specific versions of viewers with maybe sloppy software. Therefore they will not have any problem with low quality devices for advertisement and fun applications, but they may have a problem, if their information is not archived in their documents because of a sloppy recommendation. This taints the semantical meaning of the content and can therefore be an argument against the usage of the format at all for serious purposes. On the other hand, of course there can be a requirement for fast and sloppy rounding too, especially for timed or animated content this may appear. There are different alternative approaches to do something useful to avoid the impression of 'nonsense' here. a) Leave the specification of rounding to books about mathematics and numerics, relying on the competence of their authors b) Specify it in a propper way to avoid any doubts about the quality of the recommendation; or specify that for color values always the percentage notation has to be used to determine the presentation value to avoid any complication with integer rounding c) Specify an additional attribute to leave the decision to the author. The authors should know best, if they require quality or fast rendering. This could look like this: integerRounding = "auto | fast | ceil | floor | even | odd" (maybe it can be generalised to 'rounding' and would be applicable for any rounding, then the value definitions have to be modified slightly) Determines the rounding rule (for integer rounding) of the element itself or its children (animation elements). - ceil: round to the next integer not smaller as the value - floor: round to the next integer not larger as the value - even: unbiased rounding, method 'round to even'; round to the next integer, for the value 0.5 round to the next even integer - odd: unbiased rounding; round to the next integer, for the value 0.5 round to the next odd integer - fast: method depending on an analysis of hardware, software and document, resulting in a fast rendering, the requirement is only to have a maximal error below 1 - auto, the default value, this is implementors optimised choice among the other values. Authors may use this or simply do not specify the attribute, if the result is not important for the intended effect as can be expected for most applications. In SVG 'real world' examples I already had some problems with rounding to the device pixel, therefore such effects are visible sometimes both for authors as for users, therefore such attribute values as ceil and floor are interesting sometimes too, maybe especially for designers or artists to avoid some nasty artefacts from rounding. Such people are sometimes fussy about artefacts and residuals from numerics, while people with educational or scientific applications have more a requirement for unbiased rounding. To make all of them happy, one method is not enough. The choice of the default value 'auto' ensures, that there are no backwards compatibility problems.Received on Saturday, 17 November 2007 17:10:52 UTC

*
This archive was generated by hypermail 2.3.1
: Tuesday, 6 January 2015 20:34:28 UTC
*