Page 1 of 5

10523 - Very Easy !!!

Posted: Mon Jul 28, 2003 9:49 pm
by medv
I got WA. Help me!
I think my WA because of output

My test input:
3 3
4 4
0 100
1 100
19 50
19 150

My test output:
1.020000E+02
1.252000E+03
0.000000E+00
5.050000E+03
4.567182E+65
1.029086E+194


Am I right?
Thank you.

Posted: Tue Jul 29, 2003 7:37 am
by Per
You have mixed up the order in which the parameters come. As it is, the input is illegal, but if you swap the numbers on each line, the output is correct.

Posted: Wed Aug 06, 2003 4:42 am
by Larry
Thanks.. this actually caught me too.. (thought I had a precision error somewhere..)

Can't people be more clear? geez..

Posted: Wed Aug 06, 2003 10:36 am
by little joey
[pascal]program p10523;

var
n,a:integer;
sum,power:array[0..19,1..150] of double;
begin
//precalculate
for a:=0 to 19 do begin
sum[a,1]:=a;
power[a,1]:=a;
for n:=2 to 150 do begin
power[a,n]:=a*power[a,n-1];
sum[a,n]:=sum[a,n-1]+n*power[a,n];
end;
end;
while not eof do begin
if eoln then begin readln; continue; end; //skip empty lines
readln(n,a);
writeln(sum[a,n]); //regular double format ?!?
end;
end.[/pascal]

What is wrong? I get WA whatever I try.
Is it the 'regular double format'? The problem has a special judge, so I suppose it accepts the 'regular' Pascal double format.
Is it precision?

Please anybody, help me...

Posted: Fri Aug 08, 2003 6:06 am
by Larry

Code: Select all

sum[a,n-1]+n*power[a,n]; 
I don't use Pascal, so I don't know if precision would be an issue because of that, but I used [I forgot name of the formula, Horner's, is it?]..
but basically:

for say,
3x^3 + 2x^2 + x,
I calculate it like this:
x ( 1 + x ( 2 + 3 ( x ) ) )

Posted: Fri Aug 08, 2003 8:46 am
by little joey
I tried that, but still WA.
I compared the output for both methods over the full range of possible input values, but they differ only in the 15th decimal or so...
Must be missing something :(

Posted: Fri Aug 08, 2003 9:43 am
by little joey
Translated the program to C and got accepted...

I wonder how the other Pascal programmers that got AC managed to get the same output as the standard C printf("%E\n",sum).

But I think the judges should accept the standard Pascal writeln(sum) (although it has a different output format) to make it a fair challenge for everybody.

To paraphrase Observer's tag line: "~~~ An ANGRY Pascal Programmer ~~~"

Posted: Fri Aug 08, 2003 10:22 am
by Observer
Yes I sometimes think that the online judge is somewhat unfair towards Pascal users. You see, in the judge input there are always trailing spaces, blank lines, leading blanks etc...

Moreover, I don't understand why the use of "seekeoln" and "seekeof" functions are restricted. It makes us difficult to handle the input spacing problems...... :cry:

Posted: Fri Aug 08, 2003 10:40 am
by Observer
little joey, if you really want to get ACC with your Pascal code, try this:

[pascal] while not eof do begin
readln(n,a);
str(sum[a,n], st);
val(copy(st,1,pos('.',st)+6),r,a); (** Rounding by hand :D **)
if st[pos('.',st)+7] > '4'
then r := r + 0.000001;
writeln(r:0:6,copy(st,pos('E',st),5))
end;[/pascal]
P.S. Yes I know it's very brute-force...... :D
P.S.2 I couldn't understand why I can't get ACC by [pascal]writeln(sum[a,n]:14);[/pascal]

Posted: Fri Aug 08, 2003 12:55 pm
by little joey
It's the way Free Pascal rounds and displays.
For n=13, a=3 the exact answer is 29893557,
but Free Pascal:[pascal]writeln(sum[3,13]:14);[/pascal]displays " 2.989355E+007" with a leading space and rounding down,

while GCC:[c]prinf("%E\n",sum[3][13]);[/c]displays "2.989356E+07".

As your clever little code snippet shows, the special judge accepts the extra leading zero in the exponent and the extra space, but refuses to accept the rounding down.

IMHO the judge _should_ accept the standard output from Free Pascal, because it's their choice to use it for their compiler. In an ideal world, getting accepted should be completely compiler independent, although I admit that that is virtualy impossible.

Last year they replaced the GPC compiler with Free Pascal, which made 80% of my submitted code uncompilable. Also we lost the runtime error reporting, which is a great asset while trying to get your code AC, and which is available in C and C++. I wrote about this several times in this board, but somehow the judges choose to ignore my complaints (I know they are very busy, but they could at least tell us that they are...).

On my sad days, I think that UVA only added Pascal and JAVA so that it looks good on the main page. The real focus is on C and C++, the languages for the elite.

On my happy days, I see getting accepted in Pascal as an extra challenge and like to beat them C-sissies, with their built in functions and easy i/o. After all, I'm in it for the fun, and I'm getting loads of it :wink:

Posted: Fri Aug 08, 2003 1:15 pm
by Observer
little joey wrote:It's the way Free Pascal rounds and displays.
Oic... I've never noticed that... But why is it so???

Pascal is great. It's the judge system which makes us feel bad... :(

10523 - WA after rejudgement

Posted: Fri Aug 22, 2003 11:45 am
by Dominik Michniewski
Could anyone tell me what should be wrong with this problem ?
I've got WA after rejudgement, so I have one question:

Is this true, that for input

Code: Select all

150 15
output is exactly

Code: Select all

41642470296774462562792725985031884205969838044105091368779920844033177704061607491770151984953636682503436650913970981305172726267418523206995220099298301053694354332223230478715
?????
I use simple DP to calculate answer, and I think that all values are correct ...

Best regards
DM

Posted: Fri Aug 22, 2003 11:55 am
by turuthok
Dominik, I got the same result as yours ... (and the same WA, I guess).

-turuthok-

Posted: Fri Aug 22, 2003 12:05 pm
by Dominik Michniewski
This is really strange ....
I think that this values which I compute are correct, but I see that something strange was happened with IO ...
Why only one person after rejudgement gave Accepted ??

Best regards
DM

Posted: Fri Aug 22, 2003 1:11 pm
by PdR
This is not the first time in the last week or so...

It's hapenning the same with problem 367: