home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!virgin!unhtel!mozz.unh.edu!noc.near.net!not-for-mail
- From: jcurran@nic.near.net (John Curran)
- Newsgroups: comp.protocols.tcp-ip.domains
- Subject: Decimal units in DNS (was Re: Positional data within DNS)
- Date: 26 Jan 1993 21:39:36 -0500
- Organization: New England Academic and Research Network
- Lines: 26
- Distribution: inet
- Message-ID: <1k4sl8$b64@nic.near.net>
- References: <VIXIE.93Jan24005212@cognition.pa.dec.com>
- NNTP-Posting-Host: nic.near.net
-
- In article <VIXIE.93Jan24005212@cognition.pa.dec.com> vixie@pa.dec.com (Paul A Vixie) writes:
- >radians are a more rational (in my opinion) way to represent polar
- >coordinates, but they are generally fractional. i'm not sure this
- >matters, since the best idea i've heard so far is to allocate N bits
- >for the coordinate and then choose a unit that will maximize
- >resolution for the neccessary range. thousandths of seconds would fit
- >in an unsigned 32-bit integer, for example. my bit-field idea was
- >over-designed. if we use radians rather than degrees, we have to pick
- >an implied decimal point, or ...
-
- On a tangential topic:
-
- In the bind beta code, is the zone file read routine (db_load.c) still
- disfunctional with respect to decimal SOA records? Last time I looked,
- the code was as such:
-
- while (digit or .) {
- if (ch=digit) n=n*10+digit_val
- if (ch=.) n=n*1000
- }
-
- which works great for most values ('1.2' becomes 10002, etc.), but overflows
- for such things as '9212.001' (which becomes 9212000001 !). Would anyone
- object if the mapping for pseudo-decimals were fixed in the future?
-
- /John
-