Lamar Owen wrote: > On Tuesday 16 July 2002 11:29 am, Thomas Lockhart wrote: > > > > We do need a solution for exact dump/reload of floating-point data, > > > > but I don't see why the lack of it should be reason to disable access > > > > to the LINE type. > > > > I don't understand why dumping the two point values isn't sufficient. > > > Which two point values? LINE is handled as an equation, not as points, > > unlike the LSEG type which has two points. > > > One possibility is to have the external representation *be* the same as > > LSEG, then convert internally. Then we need to decide how to scale those > > points; maybe always using a unit vector is the right thing to do... > > Lines are entered now by specifying two points, anywhere on the line, right? > The internal representation is then slope-intercept? Why not allow either > the 'two-point' entry, or direct entry as slope-intercept? How do we > represent lines now in output? Do we pick two arbitrary points on the line? > If so, I can see Thomas' point here, where the original data entry might have > specified two relatively distant points -- but then there's a precision error > anyway converting to slope-intercept, if indeed that is the internal > representation. So why not dump in slope-intercept form, if that is the > internal representation?
Yow, I can see the pain of having slope/intercept and trying to output two points. What if we store line internally as two points, and convert to slope/intercept when needed. That way, it would dump out just as it was entered. -- Bruce Momjian | http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026 ---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
