in reply to Re: Summing up duplicate lines
in thread Summing up duplicate lines

I'm afraid that didn't work - your output (once I created a 'sub print_result', that is :) ) looked like this:

[ -1, 5, 1 ], [ 1, 5, 1 ], [ 3, 4, 1 ], [ 5, 1, 1 ], [ -23, -64, 0 ], [ -5, 1, 1 ], [ 30, 0, 1 ], [ -5, 0, 1 ], [ 0, -45, 1 ], [ 0, 10, 1 ]
which skipped some lines. For comparison, choroba's was
[-1 5 1] [0 10 1] [1 5 1] [3 4 1] [5 1 1] [30 0 1] [0 -45 1] [-23 -64 0] [-5 0 1] [-5 1 1]

which was correct.

-- 
I hate storms, but calms undermine my spirits.
 -- Bernard Moitessier, "The Long Way"

Replies are listed 'Best First'.
Re^3: Summing up duplicate lines
by GrandFather (Saint) on May 08, 2024 at 22:23 UTC

    Actually, in terms of output content both are identical. The difference is that the two solutions give a different line order.

    Optimising for fewest key strokes only makes sense transmitting to Pluto or beyond

      I can't imagine why the default assumption would be that order doesn't matter, but - yes, it does. It's a series of mouse positions for drawing a shape, in case that matters as well.

      -- 
      I hate storms, but calms undermine my spirits.
       -- Bernard Moitessier, "The Long Way"
        I can't imagine why the default assumption would be that order doesn't matter

        Nothing matters other than what is in the spec. If the spec doesn't mention the order then ipso facto the order doesn't matter.


        🦛