Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Calculating Distance from a Point to a Plane

216 views
Skip to first unread message

renopre...@gmail.com

unread,
Sep 4, 2019, 9:22:03 AM9/4/19
to
Good Morning Everyone. I work in a sector where we deal with three dimensional data on a daily basis. Today I'm in need of a (TCL) solution for calculating the distance from any given point in 3D space to a plane.

Can anyone point me in the right direction?

Thank you everyone for sharing your thoughts and recommendations.

Reno

Arjen Markus

unread,
Sep 4, 2019, 10:11:13 AM9/4/19
to
The geometry package in Tcllib is limited to 2D problems at the moment, though it does contain similar procedures for lines and points in 2D.

It depends a bit on how you represent the plane. One option is as a list {n1 n2 n3 k}, so that the equation n.x = k represents the plane (n1, n2, n3 the three components of the normal vector n). I have no time right now to concoct a proper procedure and the Wiki has no ready-made solution I am afraid, but it should not be too hard to work it out from basic vector maths.

Regards,

Arjen

Roderick

unread,
Sep 4, 2019, 10:23:12 AM9/4/19
to

On Wed, 4 Sep 2019, renopre...@gmail.com wrote:

> I work in a sector where we deal with three dimensional data on a
> daily basis.

I also worked in such a sector, at school, homeworks on daily basis.
I got a lot of experience at that work and hope, you also get it.

> Today I'm in need of a (TCL) solution for calculating the
> distance from any given point in 3D space to a plane.

> Can anyone point me in the right direction?

The plane is generated by two vectors, and the space by a third one more,
let us say the cross product of the two. The coordinate of any
point in the last vector is easy to calculate and has to do with
the lenth. Why? How? You must bring it into equatios and a program,
but not without a justification.

Rod.

Christian Gollwitzer

unread,
Sep 4, 2019, 11:56:55 AM9/4/19
to
Am 04.09.19 um 15:22 schrieb renopre...@gmail.com:
> Good Morning Everyone. I work in a sector where we deal with three dimensional data on a daily basis. Today I'm in need of a (TCL) solution for calculating the distance from any given point in 3D space to a plane.
>
> Can anyone point me in the right direction?

Hesse normal form solves this.

https://en.wikipedia.org/wiki/Hesse_normal_form

Write the plane as an equation:

a*x + b*y + c*z - d = 0

Normalize the eqution, i.e. divide by sqrt(a^2 + b^2 + c^2).

Then, if you input any point x,y,z in this equation, the result is the
distance to the plane. If it is 0, the point is on the plane (as in the
equation). How to get the coefficients a,b,c,d depends on the form that
you have the plane in the first place. For the typical inputs like two
vectors and a point, there are relatively simple equations (cross
products etc.) to get there.

Christian


Arjen Markus

unread,
Sep 5, 2019, 3:58:10 AM9/5/19
to
On Wednesday, September 4, 2019 at 5:56:55 PM UTC+2, Christian Gollwitzer wrote:
> Am 04.09.19 um 15:22 schrieb reno:
It is not quite that easy (I also made that mistake yesterday). Take a line in the plane (it is easier to draw :)):
The line with the equation x + y = 1 would have a distance to the origin of 1 according to the above, but in truth, it has a distance of 1/sqrt(2) to the origin. The plane with equation x + y + z = 1 has a distance of 1/sqrt(3) to the origin. That said, it is not all that hard:
- Determine the line perpendicular to the plane through the point
- Determine the intersection of that line and the plane (a point in the plane)
- Determine the distance between these two points
That is your answer.

Regards,

Arjen

Christian Gollwitzer

unread,
Sep 5, 2019, 4:07:01 AM9/5/19
to
Am 05.09.19 um 09:58 schrieb Arjen Markus:
> On Wednesday, September 4, 2019 at 5:56:55 PM UTC+2, Christian Gollwitzer wrote:
>> Hesse normal form solves this.
>>
>> https://en.wikipedia.org/wiki/Hesse_normal_form
>>
>> Write the plane as an equation:
>>
>> a*x + b*y + c*z - d = 0
>>
>> Normalize the eqution, i.e. divide by sqrt(a^2 + b^2 + c^2).
>>
>> Then, if you input any point x,y,z in this equation, the result is the
>> distance to the plane. If it is 0, the point is on the plane (as in the
>> equation). How to get the coefficients a,b,c,d depends on the form that
>> you have the plane in the first place. For the typical inputs like two
>> vectors and a point, there are relatively simple equations (cross
>> products etc.) to get there.
>>
>> Christian
>
> It is not quite that easy (I also made that mistake yesterday). Take a line in the plane (it is easier to draw :)):
> The line with the equation x + y = 1 would have a distance to the origin of 1 according to the above, but in truth, it has a distance of 1/sqrt(2) to the origin.

You haven't normalized the normal vector. I wrote: "Normalize the
eqution, i.e. divide by sqrt(a^2 + b^2 + c^2)."

i.e. from the equation x+y = 1 you rewrite into:

x + y - 1 = 0 / : sqrt(1+1)

-> 1/sqrt(2) x + 1/sqrt2 y - 1/sqrt2 = distance

Christian

Christian Gollwitzer

unread,
Sep 5, 2019, 4:09:17 AM9/5/19
to
Am 05.09.19 um 10:06 schrieb Christian Gollwitzer:
> from the equation x+y = 1 you rewrite into:
>
> x + y - 1 = 0 / : sqrt(1+1)
>
> -> 1/sqrt(2) x + 1/sqrt2 y - 1/sqrt2 = distance
>

Unfortunately it is not in the English Wikipedia, but the German article
shows this use case of the HNF:
https://de.wikipedia.org/wiki/Hessesche_Normalform#Abstandsberechnung


Christian

Arjen Markus

unread,
Sep 5, 2019, 7:13:09 AM9/5/19
to
Oops, you're right :).

Regards,

Arjen

Nicolas Robert

unread,
Sep 5, 2019, 2:17:11 PM9/5/19
to
Hi Reno,

I created a page on the wiki https://wiki.tcl-lang.org/page/Distance+from+a+Point+to+a+Plane+%283D%29?V=0

Hope this helps

Nicolas

Roderick

unread,
Sep 6, 2019, 3:34:25 AM9/6/19
to

On Wed, 4 Sep 2019, Arjen Markus wrote:

> The geometry package in Tcllib is limited to 2D problems at the moment,

It is like having addition, substraction and product, but no division
(too complicated).

I ask me if there is a simple way to bind classical numerical libraries
to tcl in a coherent way without going through a third piece of software
like octave. Here you see what octave offers:

https://octave.org/doc/v4.0.1/External-Packages.html

It seems, python is much more advanced in this sense.

Rod.

Christian Gollwitzer

unread,
Sep 6, 2019, 3:40:21 AM9/6/19
to
Am 06.09.19 um 09:34 schrieb Roderick:
Because numpy is more accepted in Python as a universal numerical array.
VecTcl was my try at this (it links LAPACK)

Christian

Arjen Markus

unread,
Sep 6, 2019, 4:00:00 AM9/6/19
to
And I have doen work on wrapping various libraries as well - https://chiselapp.com/user/arjenmarkus/repository/mathemaTcl/index

(BTW, the question has inspired me to extend the set of geometrical procedures in Tcllib :)).


Regards,

Arjen

Roderick

unread,
Sep 6, 2019, 4:34:44 AM9/6/19
to

Arjen, Christian, I will take a look at your work.

> Because numpy is more accepted in Python as a universal numerical array.
> VecTcl was my try at this (it links LAPACK)

Well, I though on a way of binding the libraries to tcl and have
a unified way to call them, namely to glue them through tcl, namely
to do exactly what mathlab (and its clone octave) did and do
without binding mathlab or octave to tcl.

The question should be more about acceptance of tcl or acceptance
of python as gluing language.

Rodrigo

Christian Gollwitzer

unread,
Sep 6, 2019, 5:06:22 AM9/6/19
to
Am 06.09.19 um 10:34 schrieb Roderick:
>
> Arjen, Christian, I will take a look at your work.
>
>> Because numpy is more accepted in Python as a universal numerical
>> array. VecTcl was my try at this (it links LAPACK)
>
> Well, I though on a way of binding the libraries to tcl and have
> a unified way to call them, namely to glue them through tcl, namely
> to do exactly what mathlab (and its clone octave) did and do
> without binding mathlab or octave to tcl.
>

I got that. Have a look at

http://auriocus.github.io/VecTcl/tutorial.html

VecTcl is inspired by Matlab, you can translate straightforward Matlab
code into it with simple changes (indices start from 0, [] instead of ()...)

Of course, it only contains a tiny bit of what's available for Matlab.

Basically VecTcl is for Tcl what numpy is for Python. The big difference
is that numpy is universally accepted in the Python world, so anyone who
considers bindings for numerical work in Python will link to numpy.
VecTcl is just any of 100 extensions for Tcl. If anyone wants to bind a
numerical package, creating a dependency on VecTcl seems like a Big
Thing, so these packages stick to lists etc.

Of course, all the rest of the world never thinks of Tcl for numerical
processing, so you can't expect that anyone else will magically make
their software available for Tcl. That ship has sailed into the Python
world.

Christian

Roderick

unread,
Sep 6, 2019, 5:25:42 AM9/6/19
to

On Fri, 6 Sep 2019, Christian Gollwitzer wrote:

> I got that. Have a look at

Yes, that is! :) I will play with later.


On Fri, 6 Sep 2019, Arjen Markus wrote:

> (BTW, the question has inspired me to extend the set of geometrical
> procedures in Tcllib :)).

I think, that could be left as homework to those who need it.

Much more interesting is the work of binding libraries. mathemaTcl looks
chanlenging.

Rod.

Arjen Markus

unread,
Sep 6, 2019, 5:26:01 AM9/6/19
to
On Friday, September 6, 2019 at 11:06:22 AM UTC+2, Christian Gollwitzer wrote:

>
> Of course, all the rest of the world never thinks of Tcl for numerical
> processing, so you can't expect that anyone else will magically make
> their software available for Tcl. That ship has sailed into the Python
> world.
>
> Christian

Yes, but some of us float around with Tcl and the odd bit of numerical processing anyway :).

Regards,

Arjen

Rich

unread,
Sep 6, 2019, 9:30:50 AM9/6/19
to
Roderick <hru...@gmail.com> wrote:
>
> On Wed, 4 Sep 2019, Arjen Markus wrote:
>
>> The geometry package in Tcllib is limited to 2D problems at the
>> moment,
>
> It is like having addition, substraction and product, but no division
> (too complicated).

Also, do keep in mind that almost *all* of these Tcl library add-ons
are created by volunteers. The best way to have one's desire resolved
is to create, and submit, some additional code for inclusion.

> I ask me if there is a simple way to bind classical numerical
> libraries to tcl in a coherent way without going through a third
> piece of software like octave. Here you see what octave offers:

Creating the C bindings to hook to a C library (assuming these
'classical numerical libraries' expose a C library API) is not terribly
hard (provided one knows enough C to get around in writing some C).
The issue again is often lack of volunteers. This case needs the
rather rare combination of a volunteer, with time, who knows enough C,
who wants to write Tcl bindings to a C library, and who's want to use
that C library from Tcl is sufficiently strong enough to devote the
time to creating the C bindings, and who is willing to then submit
their code for inclusion. These things very much end up becoming a
case of "if you want it, you'll need to write it" because that rare
combination occurs so infrequently.

Alexandru

unread,
Sep 6, 2019, 2:31:54 PM9/6/19
to
Thanks for opening the page.
I added my own procedures for computing the distance of a point to a plane in 3D.
The procedures are optimized for performance.
https://wiki.tcl-lang.org/page/Distance+from+a+Point+to+a+Plane+%283D%29?V=1

Roderick

unread,
Sep 7, 2019, 3:02:55 AM9/7/19
to

On Fri, 6 Sep 2019, Christian Gollwitzer wrote:

> I got that. Have a look at

Just played a little with it. Later more. :)

> VecTcl is inspired by Matlab, you can translate straightforward
> Matlab code into it with simple changes (indices start from 0,
> [] instead of ()...)

Well, it has not to be syntactic like mathlab. I think, there is
room for crativity. The important thing is that it be easy to deal
with and be a unified interface for glueing the many libs.

I like tcls representation of content of a variable named v with $v.
For a simple vexpr I would expect consistence with expr. But something
more expresive than vexpr could have other syntax. Perhaps one could
embed in tcl restricted FORTRAN IV like code (to be interpreted)
with a way to pass values to the tcl interpreter.

And for a matrix A, cos(A) should be, if A is quadratic, the
cosine calculated in the ring of that matrices, not the cosine
applied to each element. For the last is other syntax better.

> Basically VecTcl is for Tcl what numpy is for Python. The big difference is
> that numpy is universally accepted in the Python world, so anyone who
> considers bindings for numerical work in Python will link to numpy. VecTcl is
> just any of 100 extensions for Tcl. If anyone wants to bind a numerical
> package, creating a dependency on VecTcl seems like a Big Thing, so these
> packages stick to lists etc.

Perhaps the main goal should be a frame for easy binding?

Rod.

Roderick

unread,
Sep 7, 2019, 3:36:25 AM9/7/19
to

On Fri, 6 Sep 2019, Rich wrote:

> Creating the C bindings to hook to a C library (assuming these
> 'classical numerical libraries' expose a C library API) is not terribly
> hard (provided one knows enough C to get around in writing some C).

The most of theese 'classical numerical libraries' are written in many
FORTRAN dialects that must be, in some way, compiled or translated
to C. I think, the problems lie allways in the details.

Perhaps Arjen Markus, that seems to have done a lot in this direction,
knows better if it is "not terribly hard".

Rod.

Roderick

unread,
Sep 9, 2019, 3:03:24 AM9/9/19
to

On Sat, 7 Sep 2019, Roderick wrote:

> Perhaps the main goal should be a frame for easy binding?

I just saw this in python (that I never used):

https://pgi-jcns.fz-juelich.de/portal/pages/using-c-from-python.html

Such a thing seems to be very practical for this issue. One imports
the library as is and the rest of the work is scripting. Of course,
knowledge of C remains unavoidable.

Erik Leunissen

unread,
Sep 9, 2019, 3:25:03 AM9/9/19
to
See:

http://www.swig.org/

Regards,
Erik.
--
elns@ nl | Merge the left part of these two lines into one,
xs4all. | respecting a character's position in a line.

Christian Gollwitzer

unread,
Sep 9, 2019, 3:52:25 AM9/9/19
to
Am 09.09.19 um 09:13 schrieb Erik Leunissen:
> On 09/09/2019 09:03, Roderick wrote:
>>
>> On Sat, 7 Sep 2019, Roderick wrote:
>>
>>> Perhaps the main goal should be a frame for easy binding?
>>
>> I just saw this in python (that I never used):
>>
>> https://pgi-jcns.fz-juelich.de/portal/pages/using-c-from-python.html
>>
>> Such a thing seems to be very practical for this issue. One imports
>> the library as is and the rest of the work is scripting. Of course,
>> knowledge of C remains unavoidable.
>
> See:
>
>   http://www.swig.org/
>

SWIG is one option, but requires to have a C compiler, temp files etc.

ctypes in Python is more like ffidl in Tcl:


https://wiki.tcl-lang.org/page/Ffidl

Christian

Arjen Markus

unread,
Sep 9, 2019, 7:03:24 AM9/9/19
to
My approach has always been to provide a small wrapper library in C and leave the actual (numerical) code in Fortran (or FORTRAN, as the case may be). But then Fortran is my other main programming language :).

Regards,

Arjen

kch

unread,
Sep 18, 2019, 9:10:33 PM9/18/19
to
Several of the responses are correct but provide scant details. Here is more info on why it works.

The general form for a hyperplane in N dimensions is:

K1 * V1 + K2 * V2 + K3 * V3 + ... + Kn * Vn + K0 = 0.

For a 3D plane this reduces to:

A * X + B * Y + C * Z + K0 = 0, where X is V1, Y is V2, and Z is V3 above.

A 3D plane is defined by three non-colinear points, P0, P1, and P2.

The vectors Vec1 = P1 - P0 and Vec2 = P2 - P0 are used to calculate the normal vector to a plane. The vector points one direction if you use Vec1 X Vec2 (cross-product) and points in the opposite direction if you use Vec2 X Vec1. The direction of the normal vector determines which halfspace (space on one side of the plane) is 'positive' and which is negative.

The vector computed by Vec1 X Vec2 is represented by (A, B, C), and is usually _not_ normalized or unit-length. It can be converted to an identical unit-length vector by dividing each component by sqrt(A^2 + B^2 + C^2) = F:

(A/F, B/F, C/F) is guaranteed to be unit-length (within roundoff precision).

If we replace A/F with An, B/F with Bn, and C/F with Cn (to represent 'normalized') we get the equation:

An * X + Bn * Y + Cn * Z + D = 0.

This vector represents _ALL_ possible parallel hyperplanes in 3D. To determine a specific plane, you take one of your points (P0, P1, P2), plug it into the equation and solve for D. The final combination of (An, Bn, Cn, D) is a unique plane in 3D.

Because the ABC vector has been normalized, EVERY point in 3-space will give you a distance in the units of the original point coordinates. Some of those points will have distance 0, and lie on the plane. About half of the points will have positive distance and lie in the 'positive' half-space defined by the plane. The remaining points will have negative distance and lie in the 'negative' half-space defined by the plane.

If you do not pre-normalize (A, B, C), then each point you test will return a value which is proportional to distance, but which must be normalized by dividing by the square-root F defined above.

kch

unread,
Sep 18, 2019, 9:20:16 PM9/18/19
to
Wikipedia has a good article on cross-products [https://en.wikipedia.org/wiki/Cross_product] with a good graphic [https://en.wikipedia.org/wiki/File:Cross_product_vector.svg] showing how a X b = - b X a. It does not, however, provide any information on why the result is useful in 3D.

1. Compute distance from a plane => directly use the result of plugging in a point into the Ax + By + Cz + D = Dist equation as described in my previous post.

2. Determine which half-space contains a point => Given any point, the result of Ax + By + Cz + D will be positive, zero, or negative. If Positive, point is in 'positive' half-space. If zero, point is on the plane, which can be considered in neither half-space or adopted by definition into one of the half spaces. If negative, the point is in 'negative' half-space.

The second technique is used a ton in 3D rendering to determine what objects are 'behind' other objects, to determine when a ray-tracing vector strikes a surface, to clip a vector that transits a plane at the surface of the plane and much more.

kch

unread,
Sep 18, 2019, 10:07:43 PM9/18/19
to
To use the above in TCL:
#################################################
#
# This code presumes all parameters are pre-validated.
#
proc defPoint {x y z} {
return [list $x $y $z]
}; # defPoint {}

proc defVector {Pa Pb} {
set dx [expr {[lindex $Pb 0] - [lindex $Pa 0]}]
set dy [expr {[lindex $Pb 1] - [lindex $Pa 1]}]
set dz [expr {[lindex $Pb 2] - [lindex $Pa 2]}]

return [list $dx $dy $dz]
}; # defVector {}

proc crossProduct {Va Vb} {
set A [expr { [lindex $Va 1] * [lindex $Vb 2]
- [lindex $Va 2] * [lindex $Vb 1]
}]
set B [expr { [lindex $Va 2] * [lindex $Vb 0]
- [lindex $Va 0] * [lindex $Vb 2]
}]
set C [expr { [lindex $Va 0] * [lindex $Vb 1]
- [lindex $Va 1] * [lindex $Vb 0]
}]
return [list $A $B $C]
}; # crossProduct {}

proc vecLen {V} {
set accum 0
foreach element $V {
incr accum [expr {$element * $element}]
}
return [expr {sqrt($accum)}]
}; # vecLen {}

proc normalize {V} {
set len [vecLen $V]
set normVec {}
foreach element $V {
lappend normVec [expr {$element / $len}]
}
return $normVec
}; # normalize {}

proc defPlane {NormVec P0} {
set D 0
foreach vElement $NormVec pElement $P0 {
set D [expr {$D - $vElement * $pElement}]
}
return [list {*}$NormVec $D]
}; # defPlane {}

proc distToPlane {plane point} {
set D [lindex $plane 3]
foreach vElement [lrange $plane 0 2] pElement $point {
set D [expr {$D + $vElement * $pElement}]
}
return $D
}; # distToPlane {}

#################################################
set P0 [defPoint 1 0 0]
1 0 0
set P1 [defPoint 0 1 0]
0 1 0
set P2 [defPoint 0 0 1]
0 0 1

set Va [defVector $P0 $P1]
-1 1 0
set Vb [defVector $P0 $P2]
-1 0 1

set NormalA [crossProduct $Va $Vb]
1 1 1
set NormalB [crossProduct $Vb $Va]
-1 -1 -1

# Note that NormalA is negative of NormalB....
# Also, 'NormalA' is normal to the plane, i.e. PERPENDICULAR to the plane,
# but NOT 'normalized', i.e. 'unit length'.

vecLen $NormalA
1.7320508075688772
vecLen $NormalB
1.7320508075688772

# As expected, both vectors are the same length and NOT unit-length.

set nVecA [normalize $NormalA]
0.5773502691896258 0.5773502691896258 0.5773502691896258
set nVecB [normalize $NormalB]
-0.5773502691896258 -0.5773502691896258 -0.5773502691896258

set planeA [defPlane $nVecA $P0]
0.5773502691896258 0.5773502691896258 0.5773502691896258 -0.5773502691896258

distToPlane $planeA $P0
0.0
distToPlane $planeA {1 1 1}
1.1547005383792517
distToPlane $planeA {0 0 0}
-0.5773502691896258

#################################################

The two vectors nVecA and nVecB are both unit length and point in opposite directions. We 'build' planeA by using nVecA and P0 to solve for 'D' in Ax + By + Cz + D = 0.

After building the plane we can test any point in 3D against planeA.

Rich

unread,
Sep 19, 2019, 6:46:09 AM9/19/19
to
kch <karlhan...@gmail.com> wrote:
> To use the above in TCL:

There is no "above" here. Your posting begins with "To use the above
in TCL" with nothing 'above'.

Please quote a proper amount of context before replying.

kch

unread,
Sep 19, 2019, 10:49:07 AM9/19/19
to
...actually Rich, if you had looked at _ALL_ of the thread, you would have seen that I posted three replies in quick succession and this was the third one. "above" does exist, because the prior two responses are indeed immediately "above" this reply.

Please consider the entire thread before dinging a response.

kch

unread,
Sep 19, 2019, 11:16:29 AM9/19/19
to
On Friday, September 6, 2019 at 1:34:25 AM UTC-6, Roderick wrote:
>
> It seems, python is much more advanced in this sense.
>

If you dig into the core of most python libraries which use compiled code you find they are generated using a tool named 'swig' (swig.org). Wrapping those same libraries for use in TCL is trivial.

Also, FWIW, python uses Tcl/Tk in its core (https://wiki.tcl-lang.org/page/Python). If you browse through the python source you will discover it is either using Tcl/Tk dynamic libraries, or embeds the language.

From the latest Python 3.7.4 source: https://www.python.org/ftp/python/3.7.4/Python-3.7.4.tgz

In the Python-3.7.4/PCbuild folder we find:

tcl.vxproj
tcltk.props
tix.vcxproj
tk.vcxproj

and in the Python-3.7.4 root folder configure.ac contains a block for finding and using the Tcl and Tk libraries starting at line 3024:

# Check for --with-tcltk-includes=path and --with-tcltk-libs=path
AC_SUBST(TCLTK_INCLUDES)
AC_SUBST(TCLTK_LIBS)
AC_MSG_CHECKING(for --with-tcltk-includes)
AC_ARG_WITH(tcltk-includes,
AS_HELP_STRING([--with-tcltk-includes='-I...'], [override search for Tcl and Tk include files]),
[],
[with_tcltk_includes="default"])
AC_MSG_RESULT($with_tcltk_includes)
AC_MSG_CHECKING(for --with-tcltk-libs)
AC_ARG_WITH(tcltk-libs,
AS_HELP_STRING([--with-tcltk-libs='-L...'], [override search for Tcl and Tk libs]),
[],
[with_tcltk_libs="default"])
AC_MSG_RESULT($with_tcltk_libs)
if test "x$with_tcltk_includes" = xdefault || test "x$with_tcltk_libs" = xdefault
then
if test "x$with_tcltk_includes" != "x$with_tcltk_libs"
then
AC_MSG_ERROR([use both --with-tcltk-includes='...' and --with-tcltk-libs='...' or neither])
fi
TCLTK_INCLUDES=""
TCLTK_LIBS=""
else
TCLTK_INCLUDES="$with_tcltk_includes"
TCLTK_LIBS="$with_tcltk_libs"
fi

Rich

unread,
Sep 19, 2019, 12:22:21 PM9/19/19
to
No, there is nothing "above" your posting (even this one). The reason
is you are posting to a Usenet news group using the awful google groups
interface, and for anyone not using that awful interface (those of us
on Usenet proper) there is no "above". Each post stands alone. So
when I opened the post I replied to, the first line visible was:

To use the above in TCL:

With nothing else above it.

> Please consider the entire thread before dinging a response.

Please consider not using the awful google groups interface, and/or
please don't assume everyone else is also using it.

kch

unread,
Sep 19, 2019, 12:30:11 PM9/19/19
to
^^^^troll??^^^^

...apparently you don't have a _threaded_ newsgroup viewer. I've been using newsgroups since the 80s, and have used threaded news readers for nearly that long.

Ignoring further diatribes from you.

Christian Gollwitzer

unread,
Sep 19, 2019, 3:18:47 PM9/19/19
to
Am 19.09.19 um 18:30 schrieb kch:
I'm using a threaded viewer (thunderbird) and still the "above" is
confusing. You cannot know the order at which the "sibling" messages
appear. Therefore, if you want to add something to a post that you
forgot, /reply/ to your own message - then it is clear from the threaded
view. Still, quoting a sensible amount of context is always recommended.

Christian

Rich

unread,
Sep 19, 2019, 7:50:52 PM9/19/19
to
kch <karlhan...@gmail.com> wrote:
> On Thursday, September 19, 2019 at 10:22:21 AM UTC-6, Rich wrote:
>> kch <karlhan...@gmail.com> wrote:
>> > Please consider the entire thread before dinging a response.
>>
>> Please consider not using the awful google groups interface, and/or
>> please don't assume everyone else is also using it.
>
> ^^^^troll??^^^^

Nope.

>
> ...apparently you don't have a _threaded_ newsgroup viewer. I've been
> using newsgroups since the 80s, and have used threaded news readers
> for nearly that long.

I do, but your 'above' when reading the message provides no context,
unless I exit from viewing the message into the thread view, then drop
back down to the above.

And, why in this world would someone claiming to have been using usenet
since the 80s, ever use that awful google groups interface to post.
Anyone who used any real newsreader should recognize how awful the
google groups interface is.

> Ignoring further diatribes from you.

Makes no difference to me. And since you can't killfile via the awful
google groups interface anyway you will have to ignore manually.


Bertrand Sindri

unread,
Sep 20, 2019, 12:07:05 AM9/20/19
to
kch <karlhan...@gmail.com> wrote:
> I've been using newsgroups since the 80s

The evidence presented here before us does not support that assertion.

Someone who has been using newsgroups since the 80s would be fully
aware of the customs and would not have made such a newbie mistake.

The fact that you have made such a newbie mistake heavily indicates that you
have in fact *not* been using newsgroups since the 80s.

kch

unread,
Sep 21, 2019, 9:41:14 AM9/21/19
to


Wow! Such an interesting discussion about Tcl/Tk....

Rather than parse and dissect code, some posters spend time parsing and dissecting others.

As for 'losing the context' by exiting the post in order to view the thread, every threaded reader I have used allows configuring a message pane which allows viewing both the thread and a selected message.

Complaining about "failure to include sufficient prior content" simply wastes bandwidth & space while simultaneously requesting the target to similarly waste bandwidth and space.

Does the code respond to the original thread topic?

Is the code correct?

Is the post understandable regardless of whether one interprets "above" as referring to the topic, a prior post, or the vastness of the universe?

Regardless of who you are, responding to posters with statements using words like "newbie", "...have in fact *not* ..." will only serve to drive off people who might otherwise learn a great deal about the eminently interesting language which is Tcl.

NB - I embedded Tcl into Acrobat PDFs in 1994, leading to Adobe purchasing the company at which I worked: http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PALL&p=1&u=%2Fnetahtml%2FPTO%2Fsrchnum.htm&r=1&f=G&l=50&s1=5832263.PN.&OS=PN/5832263&RS=PN/5832263

Ricardo kozmate.net

unread,
Sep 22, 2019, 12:11:17 PM9/22/19
to
Em 21/09/19 14:41, kch escreveu:
> Rather than parse and dissect code, some posters spend time parsing and dissecting others.

Including you...


> Complaining about "failure to include sufficient prior content" simply wastes bandwidth & space while simultaneously requesting the target to similarly waste bandwidth and space.

Having to read ALL the thread also wastes time. Having to keep all the
thread in ones mind when reading a post is probably impossible, so to
save ONE "writer" the trouble of adding a couple of lines of context,
will waste SEVERAL "readers"' time finding the context.

> Is the post understandable regardless of whether one interprets "above" as referring to the topic, a prior post, or the vastness of the universe?

Maybe, but it would be more understandable with some context.


> Regardless of who you are, responding to posters with statements using words like "newbie", "...have in fact *not* ..." will only serve to drive off people who might otherwise learn a great deal about the eminently interesting language which is Tcl.

Agreed. I'd include "troll" (or "^^^^troll??^^^^") in the words that are
not useful.



But please, let's assume we all can do better (as we do), and get back
to talking code and math, which is much more interesting, indeed.


--
{ricardo from kozmate.net}

Arjen Markus

unread,
Sep 23, 2019, 4:21:11 AM9/23/19
to
On Sunday, September 22, 2019 at 6:11:17 PM UTC+2, Ricardo kozmate.net wrote:

>
> But please, let's assume we all can do better (as we do), and get back
> to talking code and math, which is much more interesting, indeed.
>

I fully agree :).

Regards,

Arjen
0 new messages