A programming challenge all up in your face.

[H_TeXMeX_H]

Well you used float for all your numbers (not recommended), might wanna use double for better precision.

[cymon]

If I understood this math, I would probably get the challenge.

[worker201]

Could be.  acos, sqrt, and pow all return doubles, so the program is probably running some internal float>>double conversions in a few places.

[H_TeXMeX_H]

Yeah, something like that ... I always use double for any non-integer.

[mobrien_12]

It would be interesting to see if it gets more decimal places correct using double precision.

As it is, there's only 0.1% error.

[mobrien_12]

Wow, this thread has taken off.

Re: vertical lines, since we have this:

[(y2 - y1)/(x2 - x1)]x + k = y

We could multiply both sides by (x2 - x1) and see what that gets us (there won't be division by 0).

Been thinking about this.  You could do this but for a vertical line you are multiplying both sides by zero then, which gets you down to the fundamental problem:  a vertical line segment is not a function of x.  The entire coordinate-type algorithm is based around y being a function of x so it falls apart at this case.

The vector-analysis algorithm that I used doesn't need y to be a function of x.  

This doesn't mean that the coordinate-type algorithm can't do it.

Just test to see if it is a vertical line.  If so, then simply rotate the coordinate system by 90 degrees and you have a horizontal line.  Then the algorithm will work.

[worker201]

Would it be ghetto to write a whole other routine just for dealing with verticals?  It's a much easier task.  Say our vertical line was x=5.  You could just plug that into the circle equation and solve for y.  If you get 2 different real y values, then the circle intersects the line, and you can continue from there.  It would probably be more elegant to write the routine in a way that didn't depend on the slope of the line (or distinct functions of variables), but I think for something as simple and specific as this, maybe a case solution might be better.

WWAD?
(what would Adobe do?)

[mobrien_12]

Would it be ghetto to write a whole other routine just for dealing with verticals?  It's a much easier task.  Say our vertical line was x=5.  You could just plug that into the circle equation and solve for y.  If you get 2 different real y values, then the circle intersects the line, and you can continue from there.  It would probably be more elegant to write the routine in a way that didn't depend on the slope of the line (or distinct functions of variables), but I think for something as simple and specific as this, maybe a case solution might be better.

WWAD?
(what would Adobe do?)

Eh, simplest solution is the best I guess. I was just trying to think of how to make the existing code work for the one special case... I thought that would be the easiest.  If a second routine to handle it would be easier, it's probably better to go that way...

[TheQuirk]

Been thinking about this.  You could do this but for a vertical line you are multiplying both sides by zero then, which gets you down to the fundamental problem:  a vertical line segment is not a function of x.  The entire coordinate-type algorithm is based around y being a function of x so it falls apart at this case.

The vector-analysis algorithm that I used doesn't need y to be a function of x.  

This doesn't mean that the coordinate-type algorithm can't do it.

Just test to see if it is a vertical line.  If so, then simply rotate the coordinate system by 90 degrees and you have a horizontal line.  Then the algorithm will work.

Aye, the point is that you would get (y2-y1) + k(x2-x1) = y(x2-x1) => y2-y1 = 0 which is obviously false, thus pointing out that it's a vertical line. This is how we generally solved problems which involved coordinates.

(For what it's worth, however, I think your method is a lot nicer.)

[mobrien_12]

But I really like the idea that we have two completely different solutions which give the same answers!!!  And the code base is about the same length for each!

And you notice how that the challenge was put down a few months ago, but when we all worked together we knocked it out in a week or so? This has really been FUN!

I was able to fix the special cases in my approach that messed it up, maybe this weekend we can fix the vertical line case in the coordinates!

[worker201]

Just started my new job, so I haven't had much spare time to mess with this yet.  But I have a plan to deal with vertical lines and tangents that I think will be cool.  I also want to recast everything as doubles, just to see what the change is.

[mobrien_12]

#include
#include
#include
#define TRUE 1
#define FALSE 0

int main()
{
  /* variable declarations */
 
  /* file read/write variables */
 
  typedef int bool;
  bool transpose;
  /* temporary "shuffle" variable used to transpose coordinates */
  float tempcoord;
  /* variables declared from input */
  float x1, y1, x2, y2;
  int i, numcirc;
  float circlex[15], circley[15], radius[15];
  /* variables for internal use */
  float slope, yint, rsquare, discrim, theta;
  float aterm, bterm, cterm;
  float u, j, v, w, high, low;
  float total, chord, arc;
  float intx1[15], intx2[15], inty1[15], inty2[15];

[mobrien_12]

Modified worker's program to take care of vertical lines... the tangent's still need to be done.  Don't think I can do that...

It works

Tested with this data

Code: [Select]


5
0
5
10
2
5 5 1
20 20 2


CAN'T POST THE CODE..... CAN'T FIGURE OUT WHAT'S MAKING IT BARF.... there's no f  open in there.

GAH

I left some troubleshooting printf statements in there.... sorry it's getting late.  I also commented out the scanfs becasue I didn't want to type in the file names while troubleshooting... easy enought to uncomment them.

[verwijderd door de beheerder]

[Lead Head]

Wow

[worker201]

What an exciting Friday night, programming in C.  :cool:

Here's my latest version:
http://www.triple-bypass.net/download/circleline2.txt

It deals with vertical lines and tangents, and even has a function!

Too bad it doesn't work.

For some reason, my logically flawless method of catching tangents doesn't seem to work.  Here's the data I tested with:
0
5
10
5
1
5 6 1

Overall, the whole program doesn't work.  It ends up writing "nan" to the output file.  Which makes me think that there is something really screwy going on.  Notice that all the floats are now doubles - could that be to blame?  Or maybe it's the function not returning properly.  Honestly, the thing I find most difficult about programming, by far, is understanding variable scope.  It seems like it would be so much easier to just have the function use the same variables the program does.  Any suggestions?