I will try to explain that through multimap block:
They work identical, multimap works as it should, but if we try to add second input (which is index for maps):
Is there any way to fix that, to make it work as index?
Oh, i see it now, multimap uses call inside it, and call understands 1st input as value, but does not understand 2nd input as index and so on.
I wonder, if that could be actually feature request category?
multimap is a user editable reporter so you can modify it yourself and then submit the modification for consideration as a replacement
The trouble isn't in implementation, but in the logic.
In MAP, since we know in advance that there's exactly one input list, we also know that any second input to the mapped function can't be an input value. So we can assign it some different meaning, such as the index, and similarly for the third input. Note that MAP won't let you provide a fourth formal parameter, because we haven't assigned it a meaning.
In MULTIMAP, by contrast, there can be any number of input lists, so if you have 12 input lists, your function has to have 12 inputs, and they all have the same meaning. The second formal parameter of the lambda has to be an item from the second input list. I suppose it would be possible to check for a case in which there are N input lists and N+1 formal parameters to the lambda, and then provide the index number as the last input to the lambda. (It's the same number for all the input lists, so you'd just need N+1 inputs to the lambda, not 2N of them.) (Actually, even though it would be a little incompatible, I'd prefer to use the index as the first input, so that ALL BUT FIRST OF the inputs will be the values.)
But I think a much cleaner solution would be to use an upvar, like this block in the List Utilities library:
You can use the # in the script inside the C-slot (which is an implicit lambda of course). That library used to have
and similarly for KEEP. We took those out when we made MAP a primitive, I think, but I'm no longer sure why.
Interesting, i like the idea of having first input as index, it would be easier to use,
Pity that you removed it, i remember not even knowing about map ring's default inputs, because i did not know they existed..
By the way, as i did 1 block before, what do you think of it?
I know it can be done through multimap block, but this one is simpler, works faster, and repeats, i wonder if block like that (not exactly my implementation) could be potentially added to list utilities lib?
Making a one-item list and then mapping over it is rarely the right thing. Instead you should use CALL:
where INPUT VALUE is provided by an outer MAP.
EDIT: No, that would apply every function to every value, which is what I'd want to begin with. To get what you want, you'd
and you only need one level of mapping.
Note that the ITEM block in this expression is unringified!
Yup, that looks way better!
Block made on your implementation
So, maybe it could be added to list utilities?
I think you have a better case for reviving the # versions of MAP and KEEP. I'm not entirely convinced that there's that much use for a MAP that applies different functions to different input positions. Maybe I need to see some real examples instead of this ( )+1 vs. ( )-1 stuff.
Not the best example, but it could be used to work with rgb arrays
I would use a multimap with (65536, 256, 1) as the second list.
huh?
Encoding RGB to 24-bit integer can be done with hyperblocks
Hmm, I'd try to debug my code except that when I drag your script pic into Snap! I don't get the variable RGB ARRAY, just the code. :~(
Good night master, that's the rgb array that you need? 
I recreated that in this screenshot, look 
:
Or inspect it in this url 
:
https://jmoenig.github.io/Snap/snap.html#present:Username=alessandrito123&ProjectName=Just%20the%20truth
Umm I have no idea where that array came from -- I mean, why would that be a target of computation? Not how did you compute it.
when i was doing it, i was sure someone would make it easier lol, but i am sure not everyone knows the easiest way, as i mostly dont
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.