Re: [Geopriv] Direction for draft-ietf-geopriv-binary-lci

[Cullen Jennings <[e-mail]>]

Ok, so in your example of a range is 15.999 to 16.034 what is the  
largest 9+25 bit fixed point number in binary that is less than or  
equal to  15.999 and the binary number that greater than or equal to  
16.034?  what  value of res would see as being used? The question I  
want to get to here is if your statement is correct that the smallest  
range we are going to end up with a 32 degree range. Alternatively we  
could work with the example (which I have not personally checked but  
just copied out of binary lci)

              binary                    decimal
000011111.1111111111111111111001110  31.99999850
000100000.0000000000000000001011100  32.00000274

001000000.0000000000000000000101010  64.00000124  sum
000100000.0000000000000000000010101  32.00000062  average
000000000.0000000000000000010001110  00.00000423  difference

Which gets to a 27 bits of resolution.

Thoughts?

Cullen <in my roll of a individual contributor trying to understand>


On Feb 24, 2008, at 11:56 PM, Dawson, Martin wrote:

> Hi Cullen,
>
> Here's the text from 3825 for LaRes:
>
> " .This value is the number of high-order Latitude bits that should be
>    considered valid.  Any bits entered to the right of this limit  
> should
>    not be considered valid and might be purposely false, or zeroed by
>    the sender.
>
>    The examples in the appendix illustrate that a smaller value in the
>    resolution field increases the area within which the device is
>    located."
>
> In the example you suggest, you don't have any mechanism to  
> communicate
> the 0.01 part using DHCP. You've only got significant digits. Using  
> the
> decimal version of 3825, and assuming you wanted to send 20.0, you'd
> send something like:
>
> 020.000000 with Res set to 4. which is 020.000000 to 020.099999 (let's
> say 20.01).
>
> So, yes, you'd be stuck with something between 0 and 100 (99.999...)  
> if
> you wanted to enclose your region.
>
> Now, you may have been wanting to apply a typical interpretation of
> precision - except that it's usually a half the significance of the
> remaining digits.
>
> i.e. 20.0 is 20.00 +/- 0.05 which is 19.05 to 20.05
>
> I don't believe the 3825 text points to that interpretation. But,
> nevertheless, this also doesn't give me any power to represent  
> specific
> areas because the size of the area isn't coupled to the precision with
> which a point is measured. It's certainly not a satisfactory
> representation of your 19.09 to 20.01 (I'm prepared to stand corrected
> but I think that .a 08 difference in latitude accounts for about  
> 9km) -
> or the infinite number of other possible regions that could be  
> anywhere
> within that range.
>
> If 3825 *intends* to convey the interpretation that the precision is
> plus or minus the maximum value of the remaining "insignificant"  
> digits
> then it needs to say so. It doesn't - and, in fact, the example in  
> 3825
> is consistent with the "the other digits can be anything"
> interpretation.
>
> Regardless, and this is the important thing, there should be no talk  
> of
> 3825 being useful for conveying "areas" or "regions". Significant  
> digits
> (or precision) alone do not have the necessary expressive power to do
> this. Since it's not possible for the sender to communicate a specific
> region using DHCP, it's really really important that receivers don't
> attempt to interpret the received value that way - it's just a point
> with significant digit numerators or precision (and it's unclear what
> use those are to the receiver). I would actually prefer 3825 to make
> this clarification explicitly - currently it leaves readers with the
> opposite impression - as does binary-lci.
>
> Cheers,
> Martin
>
> -----Original Message-----
> From: Cullen Jennings [mailto:[e-mail]]
> Sent: Monday, 25 February 2008 5:15 PM
> To: Dawson, Martin
> Cc: Richard Barnes; GEOPRIV
> Subject: Re: [Geopriv] Direction for draft-ietf-geopriv-binary-lci
>
>
> On Feb 24, 2008, at 5:53 PM, Dawson, Martin wrote:
> > I'm not sure that there's anything more to be said as far as working
> > through the example.
> >
> > The range is 15.999 to 16.034
> >
> > 3825 allows me to encode it as a 34 bit fixed decimal number, with 9
> > bits before the decimal point. The only binary range that completely
> > encloses the target range is 0-32 degrees. The *next smallest* range
> > is 0-16 and that leaves out the upper 0.034 degrees of the
> > region(which is actually the largest part of it). So - the 3825
> > encoding that includes the whole region is:
> >
> > 0000xxxxx.xxxxxxxxxxxxxxxxxxxxxxxxx with Res set to 4
> >
> > Of course, you have to put some numbers in the other 21 non-
> > siginficant bits when you populate the fields in the option but, by
> > definition, they are not significant; they can be anything.
> >
> Let me see if I follow your argument here.... Lets just change the
> example slightly to 19.09 and 20.01 and work in base 10 instead of
> base 2. You are saying that if I wanted to represent the measurement
> 20+/-0.01 with significant digits in base 10, I would need to write
> 100 because only 0 to 100 fully covered the range 19.09 to 20.01 ? I
> was sort of expecting I could write 20.0
>
>
> ------------------------------------------------------------------------------------------------
> This message is for the designated recipient only and may
> contain privileged, proprietary, or otherwise private information.
> If you have received it in error, please notify the sender
> immediately and delete the original.  Any unauthorized use of
> this email is prohibited.
> ------------------------------------------------------------------------------------------------
> [mf2]
>
>

_______________________________________________
Geopriv mailing list
[e-mail]
http://www.ietf.org/mailman/listinfo/geopriv