DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25818>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25818 BinaryHeap.remove(Object) seems to break heap order ------- Additional Comments From [EMAIL PROTECTED] 2003-12-31 18:22 ------- Ouch! Yes, looks "obviously wrong" to always percolate down. Interestingly, the pop() operations in checkOrder() usually repair the tree before an element pops off out of sequence, which explains the low incidence of failures. For example, the following test (using checkOrder() above) succeeds, but produces output showing what looks to me to be bad heap state after the remove. The pop()s in checkOrder() repair the damage (when 0 is popped). public void testAddRemove() { BinaryHeap h = new BinaryHeap(); h.add(new Integer(0)); h.add(new Integer(2)); h.add(new Integer(4)); h.add(new Integer(3)); h.add(new Integer(8)); h.add(new Integer(10)); h.add(new Integer(12)); h.add(new Integer(3)); System.out.println(h); h.remove(new Integer(12)); System.out.println(h); checkOrder(h); } Output: [ 0, 2, 4, 3, 8, 10, 12, 3 ] [ 0, 2, 4, 3, 8, 10, 3 ] <-- 3 should have percolated up after taking 12's spot. A small test case like above showing API failure would be nice. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
