Thanks Everybody

kzaman010 · Post by **kzaman010** » Thu Jul 11, 2002 5:09 pm

Hello Everybody

Many many thanks for participating in the "Real programmers' Contest-1".
This was my first attempt. So there might be some mistakes.
The least solved problem was 'K' "The Ray inside Polygon". In geometric
problems it is better use less computation because that increases
precision error. It's also important to think the way Judge can solve
this problem. THe problem was solved by both Me and Sajjad Hossain.
So there is no problem with input output.

If you enjoy the contest, I will consider myself sucessful.
-Md. Kamruzzaman

Stefan Pochmann · Post by **Stefan Pochmann** » Fri Jul 12, 2002 7:36 pm

It's also important to think the way Judge can solve this problem.

Yeah right. Since when can I look into your head?!?

So there is no problem with input output.

1 out of 84 submissions was accepted. And the person who got it needed three attempts. I consider this a major problem. Don't you think you could've added a special judge program or could've made the task more precision-error-friendly or could've made sure that the input is friendly? When I see a floating point problem and a 1/84 success rate, I claim that the problem setter was careless...

gvcormac · Post by **gvcormac** » Fri Jul 12, 2002 10:36 pm

I agree with Stefan. 1/84 sounds more like chance agreement on some random variable than the one correct submission.

As a problem setter, I am very concerned when the success rate is less than 10%. For example, "Return of the Jedi" was 5.6% or so last time I looked. This causes me ongoing concern but I don't see anything wrong with it.

In general, with floating point problems, you have to prepare the data so as to avoid singularities by a sensible margin. The problem statement "within two decimal places" does not avoid the singularity - rather it changes it from a point to a circle about the point. It isn't entirely clear to me what is the exact radius of the circle.

Adrian Kuegel · Post by **Adrian Kuegel** » Sat Jul 13, 2002 12:50 pm

I don't think there is a precision problem, it is only a bit difficult to solve the problem and not to forget something. The ray is lost forever if its coordinates differ from the coordinates of an polygon vertex by at most 0.005. I got Accepted (not in Contest, but now) after 3 submissions (the first two were obviously wrong).

gvcormac · Post by **gvcormac** » Sat Jul 13, 2002 3:35 pm

So the ray is not lost if the difference is 0.0050001 and is
lost if the difference is 0.0049999?

(a) Sounds like a decision problem to me.

(b) It is not obvious to me that the appropriate constant is 0.005 rather than, say 0.01.

(c) I have no idea whether or not the data are set up so that it matters whether you us 0.005 or 0.01, but it might be.

(d) It is possible to solve the problem with exact arithmetic, but that still wouldn't answer (b) or (c).

kzaman010 · Post by **kzaman010** » Sat Jul 13, 2002 5:15 pm

Well, the input data is not complex here. In fact almost
each co-ordinate is integer. I think, the way you are thinking
for the error is not the case here. As the number of reflections may
be large, the coeffecients may gradually increase(10^15) and round
to zero after some most significant digits (which occur for floating point number).
I have faced this problem during writing judge solution. Every output has been verified.
Moreover there could be also that CLASSICAL "-0.00" problem.
In terms of submission, same solution may be submitted several times
due to Judging problem.

Moreover the check has been done after rounding to two decimal
places. So diffrence 4.001 and 3.999 is same

kzaman010 · Post by **kzaman010** » Sat Jul 13, 2002 5:16 pm

I don't know whats the problem of Stephan. I have searched
your name in the Real Time Ranklist and not found.
And there must be some constant terms in a line eqn or
a vector . You are trying to create complex about the
rounding. THere is 2 or 3 test cases with negative answer.
And there is no problem with rounding. I dont know whether
you use your own rounding program instead of using already
available one.

In case of "-0.00", that may be a library bug but you should
be aware of that. You cannot expect that you will get
infinity when division by zero will occur. Moreover my solution
does not produce -0.00.

I think you want each possible situation should be specified
in the problem statement. THen each such problem turns into
a simulation problem and nothing else.

Above all, the problem is solved during contest time and
also getting solved now.

Stefan Pochmann · Post by **Stefan Pochmann** » Sat Jul 13, 2002 5:48 pm

What do you mean with "coefficient"?

Moreover the check has been done after rounding to two decimal places. So diffrence 4.001 and 3.999 is same

That specification should've definitely been in the problem statement. And is -3.005 rounded to -3.00 or -3.01?

Moreover there could be also that CLASSICAL "-0.00" problem.

That's a stupid library bug, not my fault, and one more good reason to write a special judge program.

Btw, you wrote two almost similar posts. Which one do you want us to read? You can also edit and delete posts you've written.