A program to recognize and reward our most engaged community members
But are we really training on future examples, and testing on past examples?
with what you have you can easily be training on examples that occur after the examples you are testing!
<operator name="Root" class="Process" expanded="yes"> <operator name="ArffExampleSource" class="ArffExampleSource"> <parameter key="data_file" value="../data/iris.arff"/> <parameter key="label_attribute" value="class"/> </operator> <operator name="IdTagging" class="IdTagging"> </operator> <operator name="FixedSplitValidation" class="FixedSplitValidation" expanded="yes"> <operator name="NearestNeighbors" class="NearestNeighbors" breakpoints="before"> </operator> <operator name="ApplierChain" class="OperatorChain" expanded="yes"> <operator name="Test" class="ModelApplier" breakpoints="after"> <list key="application_parameters"> </list> </operator> <operator name="Performance" class="Performance"> </operator> </operator> </operator></operator>
Hmm I think what you are trying to say is:
Please be very careful about the validation operator you use, with what you have you can easily be training on examples that occur after the examples you are testing! It makes more sense to train on the past, or am I missing something? I think I brought this up quite recently, http://rapid-i.com/rapidforum/index.php/topic,908.msg3395.html#msg3395 ; , and amazingly here as well http://rapid-i.com/rapidforum/index.php/topic,954.msg3593.html#msg3593 so I'm probably wasting my time bringing it up again.
If it makes generates testing examples the same way as "MultivariateSeries2WindowExamples" then it should be the same?
<operator name="Root" class="Process" expanded="yes"> <operator name="ExampleSetGenerator" class="ExampleSetGenerator"> <parameter key="target_function" value="random"/> <parameter key="number_examples" value="1200"/> </operator> <operator name="IdTagging" class="IdTagging"> </operator> <operator name="SlidingWindowValidation" class="SlidingWindowValidation" expanded="yes"> <operator name="NearestNeighbors" class="NearestNeighbors"> </operator> <operator name="OperatorChain" class="OperatorChain" expanded="yes"> <operator name="ModelApplier" class="ModelApplier" breakpoints="before"> <list key="application_parameters"> </list> </operator> <operator name="RegressionPerformance" class="RegressionPerformance"> <parameter key="root_mean_squared_error" value="true"/> </operator> </operator> </operator></operator>
would it then do this?|--------------------------------------------------------------------------------------------------------------|||----------||----------||----------||----------||----------||----------||----------||----------||----------||----------||And how do is split the inner windows into?|-------...|train, test
haddock wrote:Hi WesselI think my point was different ...So let me try again. Here is an example of what I meant, it is simply the Fixed Split Sample with ID's and breakpoints inserted, so you can see the numbers of the examples that are being used for both training and test. Just check the highest training ID against the lowest test ID. If the highest trainer exceeds the lowest tester then training is taking place on examples that occur after a test case. With fixed split validation, such as you presented, this is inevitable, by definition.[...]Anyways, here's the demo.[...]
1. How do I interpret these results?
- why isn't the correlation of Zero-R, 0?
- why isn't the relative_error of Zero-R, 100%?
2. How do I output my found models in the final result?
- so when I hit play, without setting break points
3. Is this finally a fair time-series comparison?