W
Wanja Gayk
Raymond Martineau said...
The problem is, that parallel lines cannot form a triangle.
Greets,
-Wanja-
The problem is, that parallel lines cannot form a triangle.
Greets,
-Wanja-
W
Wanja Gayk
Jim Newton said...
Nope, it intersects in an unlimited number of points, which harms the
definition of a triangle, because there are more than 3 intersections.
If you bring the area of a triangle down to zero, it stops being a
triangle: you get either a point or a line.
Say you would shorten each side of a triamgle to a length of 0, you
would get a single point, which is less than 3, which allows no angle,
no intersections and thus is no triangle at all. Same problem,
basically.
Greets,
-Wanja-
Nope, it intersects in an unlimited number of points, which harms the
definition of a triangle, because there are more than 3 intersections.
If you bring the area of a triangle down to zero, it stops being a
triangle: you get either a point or a line.
Say you would shorten each side of a triamgle to a length of 0, you
would get a single point, which is less than 3, which allows no angle,
no intersections and thus is no triangle at all. Same problem,
basically.
Greets,
-Wanja-
R
Raymond Martineau
They can if they overlap - which is the exact problem one of the posters
was pointing out.
There's also the case with non-euclidian geometry, where a 2D drawing
surface forms a sphere (and nothing is allowed to pass through.) With
something like this, you can draw three individual lines to surround the
equator, and attempt to call it a triangle.
That's why you need definitions on what constitutes as a triangle and what
doesn't. If you don't define things clearly, then you will end up with
confusion and arguments on what really counts as a triangle and what
doesn't.
?
=?ISO-8859-15?Q?Juli=E1n?= Albo
Hello.
The problem is that the C++ Ansi/Iso standard has not definition of
"trinagle". Then the definition is implementation dependant or undefined
behaviour and seems that you are using different implementatios
The problem is that the C++ Ansi/Iso standard has not definition of
"trinagle". Then the definition is implementation dependant or undefined
behaviour and seems that you are using different implementatios
M
Markus Malkusch
Jim Newton:
I don't know why you are discussing about it. You're talking about a line. A
triangle is an area. If you decide that a triangle may be a line, then a
rectancle can also be a line. A box can be a rectangle and this can be a
line. And a line could be a point.
So a point is a triangle, rectangle, pyramid, and every other geometrical
structure? I think it's wrong if you decide that an area may be a line.
Volume, area, line and point are different worlds. And you can't decide that
a line has an exact area of 0, otherwise the sum of lines would be 0, but
it is an area > 0.
I don't know why you are discussing about it. You're talking about a line. A
triangle is an area. If you decide that a triangle may be a line, then a
rectancle can also be a line. A box can be a rectangle and this can be a
line. And a line could be a point.
So a point is a triangle, rectangle, pyramid, and every other geometrical
structure? I think it's wrong if you decide that an area may be a line.
Volume, area, line and point are different worlds. And you can't decide that
a line has an exact area of 0, otherwise the sum of lines would be 0, but
it is an area > 0.
J
John McGrath
That depends on the programming, doesn't it?
Check the dictionary:
tri·an·gle n.
1. a. The plane figure formed by connecting three points
not in a straight line by straight line segments;
a three-sided polygon.
http://dictionary.reference.com/search?q=triangle
T
Tayssir John Gabbour
Frank Buss said:
Thanks. It was interesting to see the differences in thought process.
Since I didn't do a good job of commenting (I just kicked it out),
I've sent you a commentary version that you might put next to my real
submission. It critiques my rough code a little, and gave some of my
background so readers know where I'm at.
MfG,
Tayssir
P
Paul Lutus
Mikael said:
Actually, it is "equals or exceeds". A three-sided polygon with sides 3, 4
and 7 is a degenerate triangle, but it is a triangle.
http://www.fact-index.com/t/tr/triangle_inequality.html
"In mathematics, the triangle inequality is a statement which states roughly
that the distance from A to B to C is never shorter than going directly
from A to C. "
Note that it says "never shorter than ...". Not "always longer than ...".
True, but not the present issue. The problem appears to be the case of
angles of 0,0,180 and nonzero sides a + b = c.
P
Philip Haddad
Frank Buss said:
I'm still working on my solution. I have been pondering it for a few
hours on and off, and now I think I've figured it out so I can
actaully write the code. I really had to brush up on geometry.
F
Frank Buss
Frank Buss said:
the challenge is over, thanks to all participants. I've submitted the link
at Slashdot, too, there are always so objective discussions
C
Chris Dams
Dear Frank,
Did you reach any interesting (or uninteresting) conclusions from the
solutions?
Best,
Chris
the challenge is over, thanks to all participants. I've submitted the link
at Slashdot, too, there are always so objective discussions
Did you reach any interesting (or uninteresting) conclusions from the
solutions?
Best,
Chris
F
Frank Buss
yes, but it is not a new conclusion: The language doesn't matter, if you
have a good idea.
But I don't know, why there are so many Lisp solutions, but this is good,
because I'm still learning Lisp, and now I have many good examples, which I
can compare to see the advantage and disadvantages for this problem.
T
Tayssir John Gabbour
Frank said:
The useful thing was though, that I didn't have any conscious idea of
what I was doing. Usually with my previous languages, I always made my
thoughts explicit (for example, on things like paper). Being in
control. After being inspired by the video, I am now experimenting with
trying other extreme, which is like falling backwards in the
expectation that I can actually levitate. Maybe I'm just weakly and
slowly groping around, but I liked the moment when I thought, "Hmm, so
that's what I'm doing."
For example, if there were something tricky about it, I might have
signalled a warning and left restarts for later. Meat & potatoes stuff
which has nothing to do with what Lisp is hyped for (and didn't appear
in the code), but quietly takes away intellectual issues so you can do
as you wish.
I certainly don't want my code to be any representative example of
Lisp, in the eyes of the public, but I thought it was fun and
edumacational. I kind of hope no one tries drawing any lessons from
what I did.
On the other hand, I liked that Literate Haskell answer. Sort of the
opposite approach.
MfG,
Tayssir
G
Gareth McCaughan
Frank Buss said:the challenge is over, thanks to all participants. I've submitted the link
at Slashdot, too, there are always so objective discussions
I've put a little plot of the results at
http://homepage.ntlworld.com/g.mccaughan/software/tri-times.ps
http://homepage.ntlworld.com/g.mccaughan/software/tri-times.pdf
which should be reasonably self-explanatory. The letters above and
to the right of the main plot show the marginal distributions.
The ones below the main plot are those with no time specified in
Frank's table.
All the numbers depicted should be taken with a grain of salt;
in particular, I haven't made a very serious attempt to correct
for the fact that some people will have reported non-blank non-comment
line counts and others will have included everything. (Where the
distinction was made, I chose the non-blank non-comment figure,
or the nearest thing thereto.) Likewise, those who gave times
may have meant different things by them.
There may be interesting conclusions to draw, but I am not going
to draw them.
M
M Jared Finder
Gareth said:I've put a little plot of the results at
http://homepage.ntlworld.com/g.mccaughan/software/tri-times.ps
http://homepage.ntlworld.com/g.mccaughan/software/tri-times.pdf
which should be reasonably self-explanatory. The letters above and
to the right of the main plot show the marginal distributions.
The ones below the main plot are those with no time specified in
Frank's table.
All the numbers depicted should be taken with a grain of salt;
in particular, I haven't made a very serious attempt to correct
for the fact that some people will have reported non-blank non-comment
line counts and others will have included everything. (Where the
distinction was made, I chose the non-blank non-comment figure,
or the nearest thing thereto.) Likewise, those who gave times
may have meant different things by them.
There may be interesting conclusions to draw, but I am not going
to draw them.
What do the Python, Java, Lisp, and Ruby entries with times less than 0
mean? Has time travel already been invented?
-- MJF
D
Dirk Thierbach
There may be interesting conclusions to draw, but I am not going
to draw them.
One thing that was interesting for me in the graph: If you just look
at the Lisp entries alone (which are numerous enough), you can see on
the one hand a linear relationship between lines of code/time needed
(a diagonal line), and on the other hand and vertical line (a nearly
constant relationship) on the left hand side. Both effects are not so
surprising: It takes longer to write more lines of code on the other
hand, and to get a short and simple solution, you have to invest some
time thinking about it, but no matter how it long takes you, the
"simplest" solution will have roughly the same number of lines.
I didn't expect those effects to be so visible so prominently, however.
(And I agree with Frank: In the end, what counts is the idea behind
the algorithm, no matter what language you use to describe it in.)
- Dirk
M
Mark McConnell
Gareth McCaughan said:
Also, people chose different definitions of the problem--of what it
means to input points and lines.
G
Gareth McCaughan
M Jared Finder wrote:
[I said:]
As I said ...
[I said:]
As I said ...
G
Gareth McCaughan
Yes. In particular, the *very* short solutions all (1) used
assignments within the program as input (though they didn't
count those assignments as part of the code), thus requiring
0 lines for handling input, and (2) used numbers to represent
points, which enables various minor algorithmic simplifications.
Whether you think of that as cheating or as intelligent use
of the language's facilities is up to you.
D
Dirk Thierbach
Gareth McCaughan said:
No, at least one short solution did count those assignments (3 lines
of assignments out of 6 total lines of code).
You could replace those 3 lines by 1 line to read the contents of a file,
1 line to parse it and to call the algorithm, 1 line to calculate the
missing part of the input definition, and 1 line to print the result.
Maybe an additional line to get the filename from the commandline arguments.
So instead of 3, you have 4-5 lines. I didn't bother, because then you have
to edit 2 files instead of 1 for testing.
Nope. Anything that's comparable will do for the simple solution,
and with two additional lines, you can use anything that only admits equality.
If you just want the number of solutions, and not the solutions themselves
without "duplicates" by permutation, then you can do even without that
(just divide the length of the list of solutions by 6).
BTW, one more important difference is that some algorithms just counted,
while some actually computed all solutions. Some algorithms restricted
themselves to two "fans" of lines, while some allowed an arbitrary
geometry. And so on, and so on.
- Dirk