replace list elements with sequential $ args

    Sep 21 2013 | 11:54 pm
    I need to replace all the 1's in an input bit list with sequenced changeable arguments that maintain the position of the 1's in the original list.
    in: 1 0 1 0 1 1
    out: $1 0 $2 0 $3 $4
    in: 0 0 1
    out: 0 0 $1
    [regexp "1" @substitute $] gives me the $ in the right places, but of course they aren't numbered. How do I modify that expression or use sprintf to generate the desired output?
    The purpose of the changeable arg output messages is to generate weighted higher-order binary sequences based on lower-order binary sequences. In other words, if I input all 2^4 bit lists (0 0 0 0 to 1 1 1 1) into [$1 $2 0 0 $3 $4], it will output all possible changes between 0 0 0 0 0 0 and 1 1 0 0 1 1 because 1 1 0 0 1 1 has a weight of 4.
    in: 1 0 1 0
    out: 1 0 0 0 1 0
    in: 0 0 1 1
    out: 0 0 0 0 1 1
    I need to do this with lists of variable lengths and weights. If there is an easier way to do this sort of thing, I'm all ears...

    • Sep 22 2013 | 3:20 am
      Man.. this is making my freakin' brain melt and my entire project has come to a grinding halt because of it.
      Does anyone know if it's even possible to create dynamic lists of changeable arguments? Max just isn't having it.
    • Sep 22 2013 | 4:56 am
      Here's one way, I'm sure there are others...
    • Sep 22 2013 | 5:59 am
      THANK YOU. Very slick. I have been working on this problem for an obscene amount of time.. and simply unable to get it working. You totally saved my ass.
      btw, I was able to modify the patch to make it significantly more efficient - 5 or 6 times faster - so I thought I'd post it. It's still your brainchild.
      If anyone else has any other approaches for formatting multiple changing args in a message box, please post them. It's a surprisingly challenging problem.
    • Sep 22 2013 | 9:44 am
      This is just a minor tweak really, but if you reset the counter on each run, you don't have to bother with calculating the number of 1's in the original list.
    • Sep 22 2013 | 10:23 am
      You dropped another 4 objects and made it even faster.. more than 8 times faster than the original. It's pretty amazing what a few tweaks can do for speed and efficiency.
    • Sep 22 2013 | 5:54 pm
      One alternate way: instead of figuring out what you need to generate (e.g. Substitution), you just brute force and filter.
      Will post an example later, but it probably is a lot simpler. It's basically comparing the sums
    • Sep 22 2013 | 6:19 pm
      tosymbol... never knew that existed, thanks!
    • Sep 22 2013 | 6:46 pm
      without going into the details of the given problem, but, when working with 2-bit style lists, dont forget the two wonderful objects [pak] and [zl nth].
    • Sep 23 2013 | 4:49 am
      @peter- post it!
      @Roman - It wasn't so much the bits as the args that were messing with me. I couldn't get a message box to take $ input in list form. Obviously the $ character is read as a changeable arg by Max, but I thought if a character was formatted as a symbol Max didn't treat it as a meta character.. yet no matter how I packaged it - preceded by a slash, in quotes, passing it through [tosymbol], etc. Max wouldn't play nice. I'm still not entirely clear why the above patches work while some of my attempts did not.
      This is the kind of stuff I was doing:
    • Sep 23 2013 | 2:08 pm
    • Sep 23 2013 | 8:39 pm
      One potential issue with using substitution is that your $1 $2 $3 values only go up to 9. Don't know if that matters for your use, but it might.
      What about storing matches into coll?
    • Sep 25 2013 | 10:35 am
      Ahh.. another working example. Nice.
      Peter, yes I need to do this for long lists. I already created a working patch utilizing the substitution method which slices long lists and then rejoins them. Maybe not ideal, but it works and I don't know how else to approach it.
      I'm not sure how I would implement colls to derive the same output. There are many, many permutations for the lists I'm processing. It's not possible to store them all.
      Without going into too much detail, I'm treating each list as a vertex in a higher dimensional lattice and I want to calculate the various lower dimensional structures of that space. For example, a 6-bit list encodes a single 0d vertex of a 6-cube (just as 3-bit lists encode the corners of a cube), 1d edges encode a single bit change between two lists, 2d faces (4 lists) encode 2-bits of difference, 3d cells (eight lists) encode 3-bits of difference, and so on.
      So I need to freely map and scale between short and long lists of different lengths on the fly. I'm using coll to store the output, but I don't see how I would use coll to generate it...
    • Sep 25 2013 | 12:57 pm
      One possible way of using coll
    • Sep 26 2013 | 9:59 am
      Hey thanks Rick.. though I think that Peter was talking about a method that doesn't involve substitution with $ - to make it easier to handle long lists. Either way, I got it worked out. Thanks for all the input everyone.
    • Sep 26 2013 | 3:29 pm
      Yeah, instead of doing substitution with $1 etc. store the pairs into a coll and do a per instance lookup. The filter way would be to generate and then use vexpr to compare, then see if the sum of the list matched the desired result.
      All this said, this sounds like a really great place for some imperative programming in Java, C++, Javascript...Clojure would be particularly fun since it can handle infinite sequences.
      Looking forward to seeing the results!
    • Sep 28 2013 | 5:04 am
      maybe the patch from richard works, because zl is not working with "real" lists? in your attempt there is a [join] and a [t l] after the [sprintf].
    • Sep 28 2013 | 10:25 am
      That's interesting, Peter. I have friends telling me that I'm a Lisp guy only I don't know it. Seemed like a complement, but I couldn't tell for sure. ha!
      Roman, very curious... I need take a closer looking at join and the zl objects because I have no idea what you mean by "real lists".