"[Solved] Retrieve Unix timestamps"

BartN
BartN New Altair Community Member
edited November 2024 in Community Q&A
The Retrieve operator does not seem to correctly retrieve stored unix timestamps (as read from a database for example). The timestamps are long values and in the example below valid values upon storage are for example 1348646704669. The value after retrieval is like 2147483647. The last three digits seem to be missing and  corrupt the data. The following reproduces this problem. Does anyone has an idea how to correctly store and retrieve these long values?
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<process version="5.2.008">
 <context>
   <input/>
   <output/>
   <macros/>
 </context>
 <operator activated="true" class="process" compatibility="5.2.008" expanded="true" name="Process">
   <process expanded="true" height="141" width="634">
     <operator activated="true" class="generate_data" compatibility="5.2.008" expanded="true" height="60" name="Generate Data" width="90" x="92" y="51">
       <parameter key="number_examples" value="10"/>
       <parameter key="number_of_attributes" value="1"/>
       <parameter key="attributes_lower_bound" value="1.348646704669E12"/>
       <parameter key="attributes_upper_bound" value="1.348646704689E12"/>
     </operator>
     <operator activated="true" class="real_to_integer" compatibility="5.2.008" expanded="true" height="76" name="Real to Integer" width="90" x="214" y="51">
       <parameter key="attribute_filter_type" value="single"/>
       <parameter key="attribute" value="att1"/>
     </operator>
     <operator activated="true" breakpoints="after" class="store" compatibility="5.2.008" expanded="true" height="60" name="Store" width="90" x="354" y="52">
       <parameter key="repository_entry" value="//LocalRepository/timestamps"/>
     </operator>
     <operator activated="true" class="retrieve" compatibility="5.2.008" expanded="true" height="60" name="Retrieve" width="90" x="532" y="44">
       <parameter key="repository_entry" value="//LocalRepository/timestamps"/>
     </operator>
     <connect from_op="Generate Data" from_port="output" to_op="Real to Integer" to_port="example set input"/>
     <connect from_op="Real to Integer" from_port="example set output" to_op="Store" to_port="input"/>
     <connect from_op="Retrieve" from_port="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"/>
   </process>
 </operator>
</process>
[/ code]

Answers

  • MariusHelf
    MariusHelf New Altair Community Member
    Hi,

    the integer data type in RapidMiner can only handle values up to 2^31. You can work around that by converting the round values after Real to Integer back to Real before storing them.

    However, I created an internal bug report from your process, since the behaviour is at best unexpected.

    Best, Marius
  • BartN
    BartN New Altair Community Member
    Hi Marius,

    Thanks for the solution, It worked.
    Presumably the Store format in the repository does not support long ints.
    The Result View in Rapid shows the complete value for the Integer type.
    Unexpected indeed.

    Kind regards,
    Bart
  • BartN
    BartN New Altair Community Member

    Hi Marius,

     

    Was the bug ever solved? When passing unix time values back and forth to a Groovy script, it still seems to overflow to a large integer.