Missing id attribute after pivot operator

Sabrine

Hi everyone,

I am having the problem that I can no longer access the Id-attribute after using the pivot operator. Although the ID-attribute is shown under the pivot operator info, trying to get hold of it, for example using the set role or select attribute operator would result in an "Attribute not found " type of error. It should be noted that the ID attribute was used as the group attribute for pivoting.

I have searched the forum and found a similar post from 2012 but about another operator, the "windowing operator". The problem seems to be identical. The contributor noticed that the problem can be avoided by changing the role of the ID-attribute before applying the operator and this has also worked for me! The problem can be avoided this way but I wanted to clarify it properly by posting it on this forum .

The type of the Id-attribute in my case is integer, in the range [ 66612-75613]  (not continuously). In the tutorial data example for the pivot operator as well as in the case of other Id-attributes examples the problem did not occur!

would be thankful for your help,

Sabrine

 

 

land

Hi Sabrine,

 

that's funny. I didn't know that...From a glance of that it seems there's a glitch in RapidMiner handling the numerical id attribute used as group.

@mschmitz Is there a way to mark posts here as bug? So that you can resolve them?

 

The solution in this case is simple: Use Set Role before pivoting to set it back to regular. Then after pivoting you can set it again on role id. Should solve your isse. 

The below process hows the issue and the solution:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<process version="7.1.001">
  <context>
    <input/>
    <output/>
    <macros/>
  </context>
  <operator activated="true" class="process" compatibility="7.1.001" expanded="true" name="Process">
    <process expanded="true">
      <operator activated="true" class="generate_data" compatibility="7.1.001" expanded="true" height="68" name="Generate Data" width="90" x="45" y="34">
        <parameter key="target_function" value="random classification"/>
      </operator>
      <operator activated="true" class="generate_id" compatibility="7.1.001" expanded="true" height="82" name="Generate ID" width="90" x="179" y="34"/>
      <operator activated="true" class="set_role" compatibility="7.1.001" expanded="true" height="82" name="Set Role" width="90" x="313" y="34">
        <parameter key="attribute_name" value="id"/>
        <list key="set_additional_roles"/>
      </operator>
      <operator activated="true" class="pivot" compatibility="7.1.001" expanded="true" height="82" name="Pivot (2)" width="90" x="447" y="136">
        <parameter key="group_attribute" value="id"/>
        <parameter key="index_attribute" value="label"/>
      </operator>
      <operator activated="true" class="pivot" compatibility="7.1.001" expanded="true" height="82" name="Pivot" width="90" x="447" y="34">
        <parameter key="group_attribute" value="id"/>
        <parameter key="index_attribute" value="label"/>
      </operator>
      <connect from_op="Generate Data" from_port="output" to_op="Generate ID" to_port="example set input"/>
      <connect from_op="Generate ID" from_port="example set output" to_op="Set Role" to_port="example set input"/>
      <connect from_op="Set Role" from_port="example set output" to_op="Pivot" to_port="example set input"/>
      <connect from_op="Set Role" from_port="original" to_op="Pivot (2)" to_port="example set input"/>
      <connect from_op="Pivot (2)" from_port="example set output" to_port="result 2"/>
      <connect from_op="Pivot" from_port="example set output" to_port="result 1"/>
      <portSpacing port="source_input 1" spacing="0"/>
      <portSpacing port="sink_result 1" spacing="0"/>
      <portSpacing port="sink_result 2" spacing="0"/>
      <portSpacing port="sink_result 3" spacing="0"/>
    </process>
  </operator>
</process>

land

Hi Sabrine,

 

that's funny. I didn't know that...From a glance of that it seems there's a glitch in RapidMiner handling the numerical id attribute used as group.

@mschmitz Is there a way to mark posts here as bug? So that you can resolve them?

 

The solution in this case is simple: Use Set Role before pivoting to set it back to regular. Then after pivoting you can set it again on role id. Should solve your isse. 

The below process hows the issue and the solution:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<process version="7.1.001">
  <context>
    <input/>
    <output/>
    <macros/>
  </context>
  <operator activated="true" class="process" compatibility="7.1.001" expanded="true" name="Process">
    <process expanded="true">
      <operator activated="true" class="generate_data" compatibility="7.1.001" expanded="true" height="68" name="Generate Data" width="90" x="45" y="34">
        <parameter key="target_function" value="random classification"/>
      </operator>
      <operator activated="true" class="generate_id" compatibility="7.1.001" expanded="true" height="82" name="Generate ID" width="90" x="179" y="34"/>
      <operator activated="true" class="set_role" compatibility="7.1.001" expanded="true" height="82" name="Set Role" width="90" x="313" y="34">
        <parameter key="attribute_name" value="id"/>
        <list key="set_additional_roles"/>
      </operator>
      <operator activated="true" class="pivot" compatibility="7.1.001" expanded="true" height="82" name="Pivot (2)" width="90" x="447" y="136">
        <parameter key="group_attribute" value="id"/>
        <parameter key="index_attribute" value="label"/>
      </operator>
      <operator activated="true" class="pivot" compatibility="7.1.001" expanded="true" height="82" name="Pivot" width="90" x="447" y="34">
        <parameter key="group_attribute" value="id"/>
        <parameter key="index_attribute" value="label"/>
      </operator>
      <connect from_op="Generate Data" from_port="output" to_op="Generate ID" to_port="example set input"/>
      <connect from_op="Generate ID" from_port="example set output" to_op="Set Role" to_port="example set input"/>
      <connect from_op="Set Role" from_port="example set output" to_op="Pivot" to_port="example set input"/>
      <connect from_op="Set Role" from_port="original" to_op="Pivot (2)" to_port="example set input"/>
      <connect from_op="Pivot (2)" from_port="example set output" to_port="result 2"/>
      <connect from_op="Pivot" from_port="example set output" to_port="result 1"/>
      <portSpacing port="source_input 1" spacing="0"/>
      <portSpacing port="sink_result 1" spacing="0"/>
      <portSpacing port="sink_result 2" spacing="0"/>
      <portSpacing port="sink_result 3" spacing="0"/>
    </process>
  </operator>
</process>

MartinLiebig

Sebastian,

 

thanks for providing this solution. I am not sure about the forums and bug tracker. @stevefarr can you help please?

 

~martin

Sabrine

Hi Sebastian,

Thank you for your reply. The issue is solved this way, this is also what the contributor who had a similar problem (with the windowing operator) did and it works perfect! I already had the feeling that this might be a bug since it seemed so strange to see the id-attribute in the operator-output but not to be able to get hold of it afterwards.

Sabrine,