## list issue

Apr 04 2010 | 4:20 pm
How can I solve this issue?
I have a list of integers:
(min list elements is 8, and the list length is dynamic, but max is 8)
f.e.
"2 4 5 6"
so the result has to be:
"0 1 0 1 1 1 0 0"
(the list element is also the position in the resulting list. if the position exist, it has to be a 1, if not a 0.)
Hope this makes sense! Any help will be much appreciated!!

• Apr 04 2010 | 6:01 pm
I'm still on my first cup of coffee, so I'm sure there are more elegant ways to do this, particularly if you're willing to use 3rd party objects.
• Apr 04 2010 | 6:04 pm
Ltoset does the job!
thanks Peter
• Apr 04 2010 | 6:10 pm
Thanks Chris. Good alternative to do this with standart max objects.
• Apr 04 2010 | 6:16 pm
One more approach just for fun.
lh
• Apr 04 2010 | 7:10 pm
amazing luke, very simply and easy to expand. this is my favourite. thanks guys.
• Apr 04 2010 | 8:31 pm
also for fun, 2 ways in javascript. first, the more traditional approach:
``````function list() {
var l = 8;
var result = new Array(l);
var a = arguments.pop();
for(var i = l; i != 0; i--) {
if(i == a) {
result[i - 1] = 1;
a = arguments.pop();
} else {
result[i - 1] = 0;
}
}
outlet(0, result);
}``````
and the more functional:
``````function list() {
var args = Array.prototype.slice.call(arguments);
outlet(0, [1, 2, 3, 4, 5, 6, 7, 8].map(
function(i) {
return args.some(function(j) {return i == j;});
}));
}``````
• Apr 04 2010 | 10:18 pm
It's interesting to compare the efficiency of these approaches. Not surprisingly, the LObjects solution was fastest, although because the input list was 1-based, it took two Lobjects. The Uzi/zl method was second fastest, the table method was third, and the javascript was well back. I could only get the second JS version to work, fwiw.
• Apr 05 2010 | 3:02 am
yeah i neglected to do what i needed to do to arguments in my first version.
interestingly, i found that converting arguments to a real array with slice and then calling args.pop to be noticeably (about 7%) faster than repeatedly doing Array.prototype.pop.call(arguments). And then getting rid of pop and just indexing into arguments is a whole 30% faster, though it's still 5 times slower than the uzi version. Something that made no noticeable difference? Going forwards through the array and using pop versus going backwards and using shift. I would have thought that shift would be slower because it has to shift the keys for all of the remaining array elements; however, both shift and pop on a "real" javascript array are probably native code and the difference on such a small array turns out to be negligible. in any case, for reference:
``````function list() {
var l = 8;
var result = new Array(l);
for(var i = 0, j = 0; i != l; i++) {
if(i + 1 == arguments[j]) {
result[i] = 1;
j++;
} else {
result[i] = 0;
}
}
outlet(0, result);
}``````
I wonder if js is similar to mxj, in that much of the performance hit comes just from firing up the interpreter.
I'm always surprised that there's so much interest in the performance of max patches, but no real profiling tools that I'm aware of.
• Apr 05 2010 | 11:23 am
hey, it's funny that some time ago i had to do the same kind of stuff for a patch, but the difference here was that : -i needed to be able entering individual elements of input list ; ie for example a "5" then a "3" and, when entering the "3", not erasing the "1" which was matching the "5" (am i clear ? :s). In fact i needed to input things individually, not as a list. -i needed it to be able to behave such as, if i entered a second time a number, it would set its state in the resulting list as "0". So if i entered a "5" a first time, its state would be set to "1", and if i entered that "5" a second time its resulting value in the resulting list would be "0". It was for making some kind of scale. I know it's not exactly what you want, but it's very similar in some points, so i post it here, hoping it can be of any interest. It works the most basically with a table, which is the better choice here maybe :)
dunno if it's of any interest in that form. it made sense in its original context ;)