|
|
For those who have WA on test 7, please try following one: 4/2*3+ Since you're able to download it, you can actually decompile it and submit the code to get accepted. There's a Thread.Sleep(3000) in there that you'll need to comment out. Test ;; +* ;+*; Sample module returns: Expression 1 evaluates to: 111 Expression 2 evaluates to: 1 Expression 3 evaluates to: 11 My AC program returns different result for 3rd string: 111 It's very weird that more complex expression returns smaller result, it fully contradicts the problem statement "It may be assumed that logic of expression evaluation does not depend on context. It means, that each subexpression is always evaluated in the same way with no dependency on it's entrance into the whole expression." Well, I guess my test can be incorrect though, but it doesn't follow from the problem description. Maybe, it should be updated a little to specify what kind of expressions is acceptable? x/0==0 re many times, there is nothing in problem description... 1) /(3;4)(2;0);2 Output: 1710 :) (not 34/20/2) 2) *3 ===> *3;1 /3 ===> /3;1 +3 ===> +3;0 3) () ==> (1) ==> 1 4) all brackets are balanced, and right. good luck! ...Выяснилось, то данный модуль был написан 8 лет назад, к первому Чемпионату Урала, и его исходные коды за это время успели потерятся... нужен мягкий знак в слове "потерятЬся" Edited by author 03.08.2009 23:55 I agree with you. I accept it with first attempt. 8 test like this +(2;((2)(2));(1)1);*(3(3;4)1) Expression 1 evaluates to: 25552 Edited by author 11.06.2007 05:04 is it module error? Edited by author 21.05.2006 23:43 Edited by author 21.05.2006 23:41 Calculator said: () Expression 1 evaluates to: 1 It is strange! PS: I have WA 2 and all tests I tried (except this) are passed. Edited by author 11.05.2006 23:44 Thank you. PS: По-русски, конечно, говорю... А как иначе по-твоему мог появиться ник Бурундук? ;) Note: "It means, that each subexpression is always evaluated in the same way with no dependency on it's entrance into the whole expression." CURRENT VERSION of Calculator: Input: (0) (0)1 (0)1(0)1 (0)1(0)1(0) (0)1(0)1(0)1 (0)1(0)1(0)1(0) Output: Expression 1 evaluates to: 0 Expression 2 evaluates to: 1 Expression 3 evaluates to: 101 Expression 4 evaluates to: 1010 Expression 5 evaluates to: 10101 Expression 6 evaluates to: 101010 comment : "Leading zeroes excluded" PREVIOUS VERSION of Calculator: Input: (0) (0)1 (0)1(0)1 (0)1(0)1(0) (0)1(0)1(0)1 (0)1(0)1(0)1(0) Output: Expression 1 evaluates to: 0 Expression 2 evaluates to: 1 Expression 3 evaluates to: 11 Expression 4 evaluates to: 110 Expression 5 evaluates to: 111 Expression 6 evaluates to: 1110 According to the output of the CURRENT VERSION of calculator !!! evaluation of subexpression depends on context Am I right ??? The so called CURRENT VERSION of calculator works correctly (where do you see dependency on context? just notice that calculator operates on numbers, not on strings!) In fact, calculator engine was updated a few days ago. An error was found there. :) That error was concerned with dependency on context (previous version, as it is mentioned above, evaluated 1(0)1 as 11 instead of 101) and it was fixed. Current logic of calculator is more predictable than the previous one. If I'm not mistaken last time you've said such output was absolutely correct and advised me to learn calculator logic carefully ;) Sorry !!! I made a foolish mistake !!! This may be caused by old version of Java Runtime Engine (JRE) used by your browser. Please, update your JRE to level 1.3 or higher. The latest JRE can be downloaded from http://java.sun.com |
|
|