Help with comparing two lists of two numbers

    Mar 14 2013 | 9:56 am
    Hi, it must be pretty basic, but i don't know which way to go...
    1. how can i output a bang when a list is '0 0' ?
    2. Then i need to output a bang in these particular cases (x is non-zero) : - when '0 -x' occurs after '0 x' - when '-x x' occurs after 'x -x' - when '-x -x' occurs after 'x x' - when '-x 0' occurs after 'x 0'
    Thank you so much... i wanna use it in this patch. Look at the 'p chemin', it draws a vectorial random path into the lcd. But i want to avoid succession of value pairs that make it go 'backwards'.

    • Mar 14 2013 | 10:02 am
      for 1. zl compare 0 0 Sorry, slow brain...
    • Mar 14 2013 | 12:37 pm
      yeah, zl compare in conjunction with [abs] should allow you to test for all these cases.
    • Mar 14 2013 | 12:55 pm
      Thanks, i forgot to mention that x can be positive or negative.
    • Mar 14 2013 | 12:59 pm
      Hum, i guess i just need to multiply both numbers by -1, pack the results, and compare the two lists...
    • Mar 14 2013 | 1:03 pm
      This is pretty brute force, but it works. Best, Jeremy
    • Mar 14 2013 | 1:52 pm
      Thank you very much Jeremy. Unfortunately it doesn't really work. Maybe because you're assuming that x is a positive number ? I've made this with only zl compare, it behaves as expected (never go backwards, never stays unmoved) but from time to time, it draws a double segment. Can't figure out why... need a rest i guess.
    • Mar 14 2013 | 2:45 pm
      Well, a few minutes clicking showed me that my method is also buggy. i guess i just need to leave it until tomorrow. Feel free to take a look though !
    • Mar 14 2013 | 5:37 pm
      how about this one:
    • Mar 14 2013 | 6:10 pm
      Thank you. It does work indeed. As this one (even with 0 0)
      So this is not a problem with spotting the unwanted lists. It's a patching problem... So if anyone could look at what's wrong in the 'p chemin' ?
    • Mar 14 2013 | 7:48 pm
      @Andrzej : for some reason, using your approach in my patch leads to even more 'double' (or even triple and quadruple) segments... i'm lost.
    • Mar 14 2013 | 8:17 pm
      my advice: clean up your patches. It's hard to tell what's going on looking at messy patchers. I did some cleanup for you, and look at blue [pack] – you don't filter out wrong coordinates, everything goes to (line) message. If your algorithm detects wrong data it draws next values (X/Yoffset), and they also can be wrong... but everything is drawn on LCD. Forth and back.
    • Mar 14 2013 | 8:45 pm
      Thank you very much... I've come to a totally different approach. This is much clearer. No double segment anymore, but still goes a step backwards from time to time. I now need to find a way to fix it in the 'p segment' : on the random output, i need to avoid 2 when previous was 1, 1 when previous was 2, 4 when previous was 3, 3 when previous was 4.
    • Mar 15 2013 | 12:47 am
      yet another way [p segment]:
    • Mar 15 2013 | 1:13 am
      and regarding your last question
    • Mar 15 2013 | 8:21 am
      Wow, thank you very much ! i really need to learn these logical expressions. It's getting much better. Although my algorithm is not perfect : it still goes backwards from time to time, when after a bang to re-pick a random number, it choses the same again. I think i can live with it, it adds a 'mistake' factor in the maze. Thank you again. louis
    • Mar 15 2013 | 9:26 am
      When it is the case that the limitations are larger then the (random) possibilities, it might be much easier to describe those possibilities (requiring much less programming). The problem can basically be reduced to: given the previous step, there are either four or five choices for the next step. There is not much required to put this in a probability table. You might want to take a look at the prob object.
    • Mar 15 2013 | 11:45 am
      for sure i will! thanks for the advice. Amazing how an apparently 'simple' thing can require a lot of knowledge and wisdom. Developing programming skills is a very long process i think.