10454 - Trexpression

[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.

[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.

[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

[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.

[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?

[ChristopherH]

That should have read: problems for people using cin.eof().
You're right, getline works okay if you test it that way.

[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]

[..]

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) {
.............
}

[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.

[..]

Thanks Austrin!
I found the stupid bug in my code~~

[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:

Code: Select all

83980
1
1430
70
1848

Any advice anyone?I cant find any other thread about this problem .

[..]

I get the same output.

[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?

[..]

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.

[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...