Filtering a stream of lists
I have a stream of two-item lists. I'm trying to devise a way to only pass the list on if the first item in the list (an integer) does NOT fall within one of two ranges. I've tried [gate]ing the list, looked over [match], [zl], and anything else I can think of, but I'm not getting the result I'm looking for.
I'm posting my [gate]ed example. I know that the unpacking/repacking seems odd, and tried combining the comparison in between only one [unpack]/[pack], but this has proven to be more consistent. This does "almost" work, but just doesn't respond well to dumping several hundred of these two-item lists in at a time. Any ideas?
unpack/pack is definetly bullshit bcause it requires you to know how long the lists are and is ineffective with long lists.
but you might want to use it when you work with lists of 2 ints.
otherwise take into account that (and how) for example
route
select
or
split
work with lists.
zl is often the solution to all this, but sometimes it needs a while until one sees it. :)
the only object i can think of which can filter elements on a list of ints is
zl union
or
zl sect.
but even with those you wil run into the problem that it cant distriguish between the first and second element and might compare against and filter out the wrong one.
i would say zl ecils is better t han unpack simply because you wil learn how to do the same thing with litst of unknown lenght.
-110
Quote: Roman Thilenius wrote on Mon, 19 January 2009 14:14
----------------------------------------------------
>
> unpack/pack is definetly bullshit bcause it requires you to know how long the lists are and is ineffective with long lists.
>
> but you might want to use it when you work with lists of 2 ints.
I do know how long the lists are...1 integer and 1 float.
>
> otherwise take into account that (and how) for example
> route
> select
> or
> split
> work with lists.
Yes, but these all drop one item of the list...
> but even with those you wil run into the problem that it cant distriguish between the first and second element and might compare against and filter out the wrong one.
I'm not trying to filter out an individual element.
> i would say zl ecils is better t han unpack simply because you wil learn how to do the same thing with litst of unknown lenght.
Let me restate/rephrase my question. I'm getting a stream of lists--not on long list of unknown length. These are all two-item lists. If the first member of the list falls within one of two different ranges, I don't want to pass any part of the list on. If the first member of the list does not fall within either of these ranges, I want to keep the two-item list intact and pass the whole thing on.
Thanks!
ah you want to the whole "list"/stream of lists to be stopped when some condit6ions are met? in this case stick to starting with
gate
!
Try using [if] with some logical operators. This example will block lists where the first item is between 10 and 20 or 50 and 60. Is that what you were trying to achieve?
lh
Quote: thereishopeforus@hotmail.com wrote on Mon, 19 January 2009 15:03
----------------------------------------------------
> Try using [if] with some logical operators. This example will block lists where the first item is between 10 and 20 or 50 and 60. Is that what you were trying to achieve?
Well, that is what I was going for...
I figured it out in the meantime though using a different approach.
Thanks!
Can someone please tell me how to use these attachments?
I think it's been many years, since I often used USENET groups that I
recall these and don't recall what tool to use to unpack them.
Someone else sent an attachment to the list and it was appropriately
attached as a .zip, there's been a lot of these that I can't recall
how to upack ????
Thanks.
-r
On Jan 19, 2009, at 8:59 AM, Brennon Bortz wrote:
>
> I have a stream of two-item lists. I'm trying to devise a way to
> only pass the list on if the first item in the list (an integer)
> does NOT fall within one of two ranges. I've tried [gate]ing the
> list, looked over [match], [zl], and anything else I can think of,
> but I'm not getting the result I'm looking for.
>
> I'm posting my [gate]ed example. I know that the unpacking/
> repacking seems odd, and tried combining the comparison in between
> only one [unpack]/[pack], but this has proven to be more
> consistent. This does "almost" work, but just doesn't respond well
> to dumping several hundred of these two-item lists in at a time.
> Any ideas?
>
>
>
> --
> Brennon Bortz
> Composer / Engraver / Career Student
Not a problem, the less objects you have to worry about when patching the clearer and quicker things become! You can use those logical operators in [expr] as well, not really relevant here but it might be something to keep in mind for the future.
lh
On 19 janv. 09, at 16:23, Brennon Bortz wrote:
> Well, that is what I was going for...
>
> I figured it out in the meantime though using a different approach.
Something like that?
ej
On 19 janv. 09, at 16:29, Robert Thompson wrote:
> Can someone please tell me how to use these attachments?
>
> I think it's been many years, since I often used USENET groups that
> I recall these and don't recall what tool to use to unpack them.
>
> Someone else sent an attachment to the list and it was appropriately
> attached as a .zip, there's been a lot of these that I can't recall
> how to upack ????
In max, select a bunch of object and select the "Copy compressed"
function in the Edit menu. Then paste it on the forum/mail.
To open it, select all the text (including ----------
begin_max5_patcher---------- and -----------
end_max5_patcher-----------) then go to max and choose "New from
Clipboard" or Paste.
HTH,
ej
Quote: Emmanuel Jourdan wrote on Mon, 19 January 2009 15:35
----------------------------------------------------
> Something like that?
Sorry? I don't follow...
Often you have to dive deep like a Pearl Diver and go into deep
realms, but you come to the surface with one simple thing.
Chaos Theory of course has that in mind versus traditional science:
What are the complications that arise for discovery, and part of that
is aggregation and simplification after detailing many things; pick
and choose, box-em-pup, etc.
On Jan 19, 2009, at 10:30 AM, Luke wrote:
>
> Not a problem, the less objects you have to worry about when
> patching the clearer and quicker things become! You can use those
> logical operators in [expr] as well, not really relevant here but it
> might be something to keep in mind for the future.
>
> lh
On 19 janv. 09, at 16:38, Brennon Bortz wrote:
>> Something like that?
>
> Sorry? I don't follow...
Sorry forgot to paste ;-)
ej
