🎉Community Raffle - Win $25

An exclusive raffle opportunity for active members like you! Complete your profile, answer questions and get your first accepted badge to enter the raffle.

Join and Win

Set Role used to allow any value as the target role

Andrew

Now it constrains to a defined list which doesn't include "horizon".

If you have a complex process that needs to set roles for horizons produced after a Windowing operation, it's not possible to use the "Multi Horizon Forecast" operator because this expects roles of type "horizon".

Ideally, Set Role should allow arbitrary target roles or at least should allow "horizon".

Find more posts tagged with

AI Studio

Accepted answers

MartinLiebig

It would be nice if Set Role would allow the advanced usage like it used to since old processes using it will break otherwise. Here's one I prepared earlier (in 2011 - so somewhat old).

Old processes don't break, since the old set role operator is still there and does what it did before.

The whole thing of being able to use custom roles as one of the features basically no beginner found by himself. With the changes in the role system we allow users to find it easier. Also it was always confusing why roles needed to be unique. This is now also changed.

But yeah, Multi-Label and Multi-Horizon forecast operators may have challenges now.

Dirty work around is by the way to just copy the old set role from an old process and use it in the new one.

All comments

David_A

Hi @Andrew ,

the new role type for arbitrary additional information is "Metadata" and the windowing operator already sets this role newly created horizon columns.

The multi horizon forecast operators is looking for the naming pattern of the columns not their roles. You can even define a custom schema with a regular expression for the horizon attributes.

Best,
David

Andrew

Hello David

I copied this from the help of the Multi Horizon Forecast operator

The horizon attributes are selected using a regular expression on the attribute roles

It's not looking at the names of the attributes and I have seen this for myself.

I have a process that needs to filter out null horizon values so a later model doesn't blow up. I initially went down the route of converting them to regular and then filtering out all nulls (I was hoping for simplicity). Once I converted back to what I thought was the required role, the multi horizon failed. I suppose I could have tried looking for

Metadata&nbsp; \+ (\d+).<br><p></p>

which is what I think the role types get set to but I did the filtering another way so it doesn't matter for me now.

It would be nice if Set Role would allow the advanced usage like it used to since old processes using it will break otherwise. Here's one I prepared earlier (in 2011 - so somewhat old).

https://rapidminernotes.blogspot.com/2011/07/ignoring-many-attributes.html

and it would also be nice if Set Role could allow horizon as an attribute type since there's every chance an example set will contain metadata already and this will mess up the numbering.

cheers

Andrew

MartinLiebig

It would be nice if Set Role would allow the advanced usage like it used to since old processes using it will break otherwise. Here's one I prepared earlier (in 2011 - so somewhat old).

Old processes don't break, since the old set role operator is still there and does what it did before.

But yeah, Multi-Label and Multi-Horizon forecast operators may have challenges now.

Dirty work around is by the way to just copy the old set role from an old process and use it in the new one.

David_A

We're looking into it.