It would be nice to get the line type working 100%. Thomas says the
problem is input/output format. I don't completely understand.
The issue is in choosing an external format for LINE which does not lose
precision during dump/reload. Internally, LINE is described by a formula
which is likely
Thomas Lockhart [EMAIL PROTECTED] writes:
The issue is in choosing an external format for LINE which does not lose
precision during dump/reload.
Why is this any worse for LINE than for any of the other geometric
types (or for plain floats, for that matter)?
We do need a solution for exact
Tom Lane wrote:
Thomas Lockhart [EMAIL PROTECTED] writes:
The issue is in choosing an external format for LINE which does not lose
precision during dump/reload.
Why is this any worse for LINE than for any of the other geometric
types (or for plain floats, for that matter)?
We do need
...
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
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
Actually... as one with the vested interest...
I'm not opposed to entering an equation in one of the basic algebraic forms. Given
that line types and line segment types both exist, I'm happy to weigh the cost/benefit
between choosing an lseg and entering 2 points, or choosing a line and
...
Well, the \dT documentation used to show line as two points, so I
assumed that was how it was specified.
Hmm. And it seems I entered it a few years ago ;)
Cut and paste error. At that time the line type was defined but has
never had the i/o routines enabled.
No one likes entering an
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
Thomas Lockhart [EMAIL PROTECTED] writes:
No one likes entering an equation. Two points seems the simplest.
That it does.
On the other hand, if you want to enter two points why don't you just
use lseg to begin with? There's not much justification for having a
separate line type unless it
Tom Lane wrote:
Thomas Lockhart [EMAIL PROTECTED] writes:
No one likes entering an equation. Two points seems the simplest.
That it does.
On the other hand, if you want to enter two points why don't you just
use lseg to begin with? There's not much justification for having a
No one likes entering an equation. Two points seems the simplest.
That it does.
On the other hand, if you want to enter two points why don't you just
use lseg to begin with? There's not much justification for having a
separate line type unless it behaves differently ...
They are
On Tuesday 16 July 2002 04:42 pm, Thomas Lockhart wrote:
On the other hand, if you want to enter two points why don't you just
use lseg to begin with? There's not much justification for having a
separate line type unless it behaves differently ...
They are different. One is infinite in
OK, I have added comments to \dT and SGML docs to mention that 'line' is
not implemented. This should help future folks.
It would be nice to get the line type working 100%. Thomas says the
problem is input/output format. I don't completely understand.
13 matches
Mail list logo
