Page 1 of 2
10454 - Trexpression
Posted: Wed Feb 26, 2003 9:05 pm
by ChristopherH
Update Feb 27: Please disregard this message. I made an error in my data-checking program. I apologise. Original message follows:
A (hopefully helpful) note for those frustrated with Trexpressions:
Contrary to the problem spec, the judging data contains characters other than those specified in the problem, including whitespace.
Be conservative in your input routines (ie don't use cin >> string).
It's unfortunate that one has to have an AC solution in hand before one can test for these infelicities. Note Feb 27: of course this claim is incorrect too -- one gets RTE before WA.
Trexpression
Posted: Thu Feb 27, 2003 7:16 pm
by kzaman010
There is no WHITESPACE in the JUDGE data.
And there is also no other characters
except that specified in the problem statement.
JUDGE SOLUTION HAS ALSO USED " scanf() " which does not deal
with WHITE SPACE and also there is no
BLANK LINE in the input file.
So check carefully, what mistakes you have done.
Posted: Thu Feb 27, 2003 7:36 pm
by ChristopherH
I apologise. You are correct, there is no whitespace.
I wrote a RTE-on-bad-data checking program, but I made an error in doing so and it spuriously reported a problem. I was attempting to help a friend decipher a WA.
Regards,
Christopher
Posted: Thu Feb 27, 2003 11:59 pm
by ChristopherH
Update: I just performed another test, using the following program:
[cpp]
void rte() {
for (int *p = reinterpret_cast<int *>(1); ; p++) *p = 0xDEADBEEF;
}
int main(int argc, char *argv[]) {
char line[150], *p;
char c = '\n', nc;
int pl = 0;
while ((nc = getchar()) != EOF) {
c = nc;
}
if (c != '\n') rte();
return 0;
}
[/cpp]
And verified that the final line of the judging data does not end with a newline.
This will cause errors for people using getline(cin, string).
Such a text file may be considered valid in a Windows environment, but would not be considered canonical in a UNIX environment. I strongly suggest that UVA judging data include a final newline.
Posted: Fri Feb 28, 2003 5:20 pm
by cytse
i used the following to read input
[cpp]
string s;
while (getline(cin,s)) {
...
}
[/cpp]
and the program got AC. What is the problem?
Posted: Fri Feb 28, 2003 5:41 pm
by ChristopherH
That should have read: problems for people using cin.eof().
You're right, getline works okay if you test it that way.
Posted: Tue Sep 16, 2003 2:54 pm
by Shahriar Nirjon
<^7
I've got AC after changing the input taking style.
Most possibly the file does not contain a newline at the last
line of file. So I checked it like this_
[cpp]
int main()
{
unsigned long long r;
char t[256];
//freopen("del.txt", "r", stdin);
setF(

);
while(1)
{
scanf("%s", t);
if(feof(stdin) && t[0]==0)break;
r = eval(t);
printf("%llu\n", r);
t[0] = 0;
}
return 20;
}
[/cpp]
10454 - WA :(
Posted: Fri Apr 09, 2004 9:57 am
by ..
Could anyone kindly give me the output?
1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1
1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1*1+1+1+1+1+1+1+1+1+1*1+1+1+1+1+1+1+1+1+1
1+1+1+1+1+1+1*1+1+1+1+1+1*1+1+1+1+1+1*1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1
1+1+1+(1+1*1+1+1+1+1+1*1+1+1)+1+1+1*1+1+1+1+1+(1)+1+1+1+(1+1+1+1)+1+1+1+1
(1+(1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1))
(1+(1+(1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1)))
I checked the board and know that the input may miss a newline at the last line. Can anyone tell if reading input in this way is ok or not?? Thanks!
Code: Select all
while(scanf("%s", str) == 1) {
.............
}
Posted: Fri Apr 09, 2004 12:19 pm
by Per
My solution outputs:
Code: Select all
3116285494907301262
212336130412243110
55534064877048198
12635931808500
812944042149730764
212336130412243110
About input: it should be ok, since the input has no whitespace (other than newline), but I used cin+getline, so I can't promise.

Posted: Fri Apr 09, 2004 12:40 pm
by ..
Thanks Austrin!
I found the stupid bug in my code~~
10454 WA
Posted: Thu Oct 14, 2004 8:34 am
by helmet
I am getting WA for this problem and I think I am making a mistake in the base case/tricky cases.
I would appreciate some test cases plz.
Also could someone verify the input-output for these
Input:
Code: Select all
1+1+1+1+2*2+1*2*2*2+1+1+1+1*2+1
((((((1+2))))))
1*1*1*1*1*1*1*1*1
(1*1*1*1)*(1*1*1*1*1)
1+1+1*1+1+1*1+1+1*(1+1+1+1+1)
Output:
Any advice anyone?I cant find any other thread about this problem

.
Posted: Thu Oct 14, 2004 8:45 am
by ..
I get the same output.
Posted: Thu Oct 14, 2004 10:06 am
by helmet
So what could be a problem?
Without revealing much about my solution let me just say that my answer is the product of several subproblems all of which are somehow based on catalan numbers.
Any overflow problems?
Posted: Thu Oct 14, 2004 10:14 am
by ..
My program only use add and multiplcation, I use long long to store all the (intermediate) numbers.
If your program used division, then you need to be careful if any overflow of intermediate numbers.
Posted: Thu Oct 14, 2004 10:20 am
by helmet
I dont use division anywhere.
Could you gimme some good sample ip and op?(something which can hopefully find my bug...

)
Thanks in advance...