Hello SMIL working group, this does not look like an accurate method to round: 'The mathematical definition of rounding is: coerced-integer-value = Math.floor( interpolated-value + 0.5 )' -> There are different mathematical definitions for rounding. This is a biased rounding because number=integer+0.5 is always rounded up (for other cases the rounding definitions are the same). This is not an accurate rounding method. This means, over a larger number of rounding the average rounding error is not zero. For an unbiased rounding, for example for even integers number is rounded down, for odd up... example: value, top eq. 'rounding' , unbiased rounding (round to even) 0.5 1 0 1.5 2 2 2.5 3 2 3.5 4 4 4.5 5 4 5.5 6 6 6.5 7 6 7.5 8 8 8.5 9 8 9.5 10 10 average 5 5.5 5 I would like to suggest to use the unbiased or 'round to even' method ... |
Dear Dr. Olaf Hoffmann , The SYMM Working Group has reviewed the comments you sent [1] on the Last Call Working Draft [2] of the Synchronized Multimedia Integration Language (SMIL 3.0) published on 13 Jul 2007. Thank you for having taken the time to review the document and to send us comments! The Working Group's response to your comment is included below. Please review it carefully and let us know by email at [hidden email] if you agree with it or not before 02 nov 2007. In case of disagreement, you are requested to provide a specific solution for or a path to a consensus with the Working Group. If such a consensus cannot be achieved, you will be given the opportunity to raise a formal objection which will then be reviewed by the Director during the transition of this document to the next stage in the W3C Recommendation Track. Thanks, For the SYMM Working Group, Thierry Michel W3C Staff Contact 1. http://www.w3.org/mid/200708101159.48572.Dr.O.Hoffmann@... 2. http://www.w3.org/TR/2007/WD-SMIL3-20070713/ ===== Your comment on 17.4.4 Animation Module: > Hello SMIL working group, > > this does not look like an accurate method to round: > > 'The mathematical definition of rounding is: > coerced-integer-value = Math.floor( interpolated-value + 0.5 )' > > -> There are different mathematical definitions for rounding. > This is a biased rounding because number=integer+0.5 is always > rounded up (for other cases the rounding definitions are the > same). This is not an accurate rounding method. > This means, over a larger number of rounding the average > rounding error is not zero. > For an unbiased rounding, for example for even > integers number is rounded down, for odd up... > > example: > value, top eq. 'rounding' , unbiased rounding (round to even) > 0.5 1 0 > 1.5 2 2 > 2.5 3 2 > 3.5 4 4 > 4.5 5 4 > 5.5 6 6 > 6.5 7 6 > 7.5 8 8 > 8.5 9 8 > 9.5 10 10 > > average > > 5 5.5 5 > > > I would like to suggest to use the unbiased or > 'round to even' method ... Working Group Resolution: The workgroup had decided to remove the offending sentence. This means that it is now up to the implementer to come up with the best way to "round to the nearest integer". Implementations may choose to follow the rule that was now removed, or to round to an even integer, if the value is exactly halfway. ---- |
In reply to this post by Dr. Olaf Hoffmann
Dear Dr. Olaf Hoffmann , The SYMM Working Group has reviewed the comments you sent [1] on the Last Call Working Draft [2] of the Synchronized Multimedia Integration Language (SMIL 3.0) published on 13 Jul 2007. Thank you for having taken the time to review the document and to send us comments! The Working Group's response to your comment is included below. Please review it carefully and let us know by email at [hidden email] if you agree with it or not before 20 Nov 2007. In case of disagreement, you are requested to provide a specific solution for or a path to a consensus with the Working Group. If such a consensus cannot be achieved, you will be given the opportunity to raise a formal objection which will then be reviewed by the Director during the transition of this document to the next stage in the W3C Recommendation Track. Thanks, For the SYMM Working Group, Thierry Michel W3C Staff Contact 1. http://www.w3.org/mid/200708101159.48572.Dr.O.Hoffmann@... 2. http://www.w3.org/TR/2007/WD-SMIL3-20070713/ ===== Your comment on 17.4.4 Animation Module: > Hello SMIL working group, > > this does not look like an accurate method to round: > > 'The mathematical definition of rounding is: > coerced-integer-value = Math.floor( interpolated-value + 0.5 )' > > -> There are different mathematical definitions for rounding. > This is a biased rounding because number=integer+0.5 is always > rounded up (for other cases the rounding definitions are the > same). This is not an accurate rounding method. > This means, over a larger number of rounding the average > rounding error is not zero. > For an unbiased rounding, for example for even > integers number is rounded down, for odd up... > > example: > value, top eq. 'rounding' , unbiased rounding (round to even) > 0.5 1 0 > 1.5 2 2 > 2.5 3 2 > 3.5 4 4 > 4.5 5 4 > 5.5 6 6 > 6.5 7 6 > 7.5 8 8 > 8.5 9 8 > 9.5 10 10 > > average > > 5 5.5 5 > > > 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". ---- |
.... > > > > 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. |
Free forum by Nabble | Edit this page |