Macro bug/feature request
cherokee
New Altair Community Member
Hi!
I don't know where to put this (in the forum or on the bug list) so I try it here.
I want to do some thing in RM5 which was without any problem possiblw in RM4. I have some setup (It is'n complete yet so I cannot post it), where I load same data, do something with the data (mainly feature selection) and store the results. I want to apply this setup to different data sets. In RM4 this was no problem: Define some macro "dataSet" and use it in the parameter for loading and for storing the results. In RM5 this is not possible using the repository. The repository load operator doesn't have an input port, thus the macro cannot be transfered to the operator --> it doesn't work.
I would say this is a bug. What do you think? Do you know any workaround?
Greetings,
Michael
I don't know where to put this (in the forum or on the bug list) so I try it here.
I want to do some thing in RM5 which was without any problem possiblw in RM4. I have some setup (It is'n complete yet so I cannot post it), where I load same data, do something with the data (mainly feature selection) and store the results. I want to apply this setup to different data sets. In RM4 this was no problem: Define some macro "dataSet" and use it in the parameter for loading and for storing the results. In RM5 this is not possible using the repository. The repository load operator doesn't have an input port, thus the macro cannot be transfered to the operator --> it doesn't work.
I would say this is a bug. What do you think? Do you know any workaround?
Greetings,
Michael
Tagged:
0
Answers
-
Hi,
first of all: There's no port connection needed for transferring the macro value. It's more like a variable set during a program flow: The macro will hold the value for all subsequent operators, regardless if there's a data flow in between. Hence the only thing that matters is the execution order.
We stumbled over this problem ourself a while ago and included a feature for intuitively show and reorder the execution order. In the beta version this is possible using the good old tree. The tree always reflects the current execution order and if you reorder the operator there, so that the macro definition is executed previously, everything should work again.
Greetings,
Sebastian0 -
Hi,
of course you are right ;D
Everything works fine when i order the operators in the tree view.
Greetings,
Michi
P.S.: I hope the annoing warnings will also vanish with your new feature0 -
Hi,
at least a few days on our schedule have been assigned to these annoying warnings
Greetings,
Sebastian0