Subject: [Geopriv] [geopriv] #30: Accuracy Issue

From: "geopriv issue tracker" <[email-masked]>
Date: Sat, 13 Feb 2010 01:12:50 -0000

#30: Accuracy Issue
---------------------------------------+------------------------------------
 Reporter:  bernard_aboba@…            |       Owner:  barnes@…                  
     Type:  defect                     |      Status:  new                       
 Priority:  major                      |   Milestone:  draft-ietf-geopriv-3825bis
Component:  rfc3825bis                 |     Version:  1.0                       
 Severity:  Active WG Document         |    Keywords:                            
---------------------------------------+------------------------------------
 Referring to the fix for Issue #3 proposed by Richard Barnes:
 http://www.ietf.org/mail-archive/web/geopriv/current/msg08278.html

 [Martin Thomson]

 I notice that there is a small error in the first paragraph.
 Section X: s/versions 1 and 2/versions 0 and 1/

 I’ll also note that the difference between setting bits and using
 exponents of two is quantifiable.  The error in the upper value is 2^-25.

 [Richard Barnes]

 Good point on the quantification: Suggested fix:
 s/up to floating-point errors/up to a possible error of 2^-25/

 [Martin Thomson]

 The error is absolute (it’s 2^-8 for altitude), it doesn’t make sense to
 say “up to”.

 [Richard Barnes]

 Are you referring to the quantization error?
      highvalue = value | mask
 versus:
      highvalue = ( value | mask ) + 1 (== lowvalue + scale)
 (the all-0xFF high value vs. the next low value)

 If that's the concern, then we might as well just adjust the fixed-point
 version to use the "+1" version.

 I guess I'll agree that you're unlikely to get errors simply due to the
 fact that you're doing floating-point arithmetic in this case.

 [Martin Thomson]

 The question is whether you consider the trailing 1 bits in the high value
 to be limited to the 34 (or 30) bits that are available, or whether you
 let the 1 bits continue indefinitely.  The +1 favours the latter
 interpretation (and avoids any 4mm gaps).

 Ultimately, this is rather academic.  It’s less than 4mm (in both cases).
 Given the other limitations of the representation, that’s nothing.  Let’s
 just add the 1 to the mask and keep everything nice and simple.

    highvalue = (value | mask) + 1
    (or highvalue = lowvalue + scale)

 (Single precision floating point will likely lose this detail, but doubles
 have space aplenty :)

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/geopriv/trac/ticket/30>
geopriv <http://tools.ietf.org/geopriv/>

---

From: "geopriv issue tracker" <[email-masked]>
Date: Sat, 13 Feb 2010 18:42:52 -0000

#30: Accuracy Issue
---------------------------------------+------------------------------------
 Reporter:  bernard_aboba@…            |        Owner:  barnes@…                  
     Type:  defect                     |       Status:  closed                    
 Priority:  major                      |    Milestone:  draft-ietf-geopriv-3825bis
Component:  rfc3825bis                 |      Version:  1.0                       
 Severity:  Active WG Document         |   Resolution:  fixed                     
 Keywords:                             |  
---------------------------------------+------------------------------------
Changes (by bernard_aboba@…):

  * status:  new => closed
  * resolution:  => fixed

Comment:

 [Bernard Aboba] Do we have agreement on the text changes?

 [Richard Barnes] I think so. Just add "+1" to the binary version:

 OLD: highvalue = value | mask
 NEW: highvalue = (value | mask) + 1

-- 
Ticket URL: <http://rsync.tools.ietf.org/wg/geopriv/trac/ticket/30#comment:1>
geopriv <http://tools.ietf.org/geopriv/>