Re: [SMIL30 LC comment] rounding in 17.4.4 and 19.4.4 ( LC-1801)

....
> >
> > 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