Блог пользователя Quick_Coder

Автор Quick_Coder, 13 лет назад, По-английски

Hi Guys, Below I have given two links to my submissions source code for problem 159B. The two codes are exactly same. The only difference is that one of the submission is made in JAVA 6 and the other one in JAVA 7. And it is interesting to note that the submission in JAVA 6 got AC while in JAVA 7 got RE. I think this is probably due to different implementations of inbuilt sort in JAVA 6 and 7. Any of your suggestions are welcome on this topic here and yes, we should wait a bit before saying Good Bye to JAVA 6 because their can be even more bugs in JAVA 7 in addition to this one. Link to my submission under JAVA 6 1353158 and Link to my submission under JAVA 7 1353143

Thank You.

  • Проголосовать: нравится
  • 0
  • Проголосовать: не нравится

»
13 лет назад, # |
  Проголосовать: нравится +13 Проголосовать: не нравится

Your comparator is wrong. See the message:

java.lang.IllegalArgumentException: Comparison method violates its general contract!
	at java.util.ComparableTimSort.mergeHi(Unknown Source)
	at java.util.ComparableTimSort.mergeAt(Unknown Source)
	at java.util.ComparableTimSort.mergeCollapse(Unknown S...

If two objects are equal, comparator should return 0 but your comparator never returns 0.

  • »
    »
    13 лет назад, # ^ |
      Проголосовать: нравится 0 Проголосовать: не нравится

    But the submission in JAVA 6 ran successfully. The comparator definition is exactly same there.

  • »
    »
    13 лет назад, # ^ |
      Проголосовать: нравится +3 Проголосовать: не нравится

    Why Java can understand it? Without unnecessary comparasions it should be impossible. If a.compare(b) = -1, It should suppose a less than b, and never compare (b and a) or (a and b) or (something that greater than b and something less than a) etc.

    Yes, I understand that it's MAY do it, but why it spend our CPU time?

    What do you think about it?

    • »
      »
      »
      13 лет назад, # ^ |
        Проголосовать: нравится 0 Проголосовать: не нравится

      Yeah sure, I fully agree with you. For suppose I have Obj1=(1,2) and Obj2=(1,2). On calling Obj1.compareTo(Obj1), compareTo function as defined will return -1. Why java should check if it returns 0 in this case. It is none of it's matter. In the above case it should simply return -1 and go on and should not have given RE. And if it does, it should show a message during compilation if the comparator does not return 0. Doing that thing in runtime and giving runtime exception after passing 9 test cases is kind of wierd.

    • »
      »
      »
      13 лет назад, # ^ |
      Rev. 2   Проголосовать: нравится +5 Проголосовать: не нравится

      Java 7 assumes that Comparator.compare method is consistent. But if it is not, certain assertions about values of variables are wrong.

      Look at the source, line 868. You can see that if your comparator is "buggy", it may violate an assertion.

      So, Java 7 does not check your comparator on every pair of elements or so. If it did, it would fail (with the exception) on the first test. But it checks a small number of invariants. If it did not, you would receive a cryptic error, probably something like ArrayOutOfBoundsException, from inside the sort procedure, and you will never guess that it is your fault.

    • »
      »
      »
      13 лет назад, # ^ |
      Rev. 5   Проголосовать: нравится +5 Проголосовать: не нравится

      > It should suppose a less than b, and never compare (b and a) or (a and b)

      I think it's too expensive to cache all comparison results for general case. Oracle's implementation uses tricky in-place merge sort and it needs some duplicate comparison in different places of code. If your comparator is too expensive you can implement some cache technique inside of the comparator.

      • »
        »
        »
        »
        13 лет назад, # ^ |
          Проголосовать: нравится 0 Проголосовать: не нравится

        But if there is no cache, how can you understand, that comparator is icorrect?:)

        • »
          »
          »
          »
          »
          13 лет назад, # ^ |
          Rev. 3   Проголосовать: нравится +5 Проголосовать: не нравится

          It's depend on used algorithm — it may not directly use cache (like int cache[][]), but it can analyze some statistics info (you can see java's source — they check length variable after merging of two parts of array).

          • »
            »
            »
            »
            »
            »
            13 лет назад, # ^ |
            Rev. 3   Проголосовать: нравится 0 Проголосовать: не нравится

            Yes, i got now that it may depends on sorting algo. For example, some obvious errors may be catched without additional check. But I couldn't imagine it on easy algos that I know, though

            Thanks.