The Altair Community is migrating to a new platform to provide a better experience for you. In preparation for the migration, the Altair Community is on read-only mode from October 28 - November 6, 2024. Technical support via cases will continue to work as is. For any urgent requests from Students/Faculty members, please submit the form linked here
"[Solved] Retrieve Unix timestamps"
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]
Tagged:
0
Answers
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
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
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.