Find more posts tagged with
Sort by:
1 - 6 of
61
Mmm, the last time I used this was under 4.6, and it looks as though the documentation is not in step with the code ( 5.006 does not have this as an option in the code and just delivers the model ). Actually given the 'ports' feature of 5.00N this makes sense.
I should ignore this, it can hardly be material, it would not be the first request for co-ordinated dox, but let it join the queue >:(
Ciao
I should ignore this, it can hardly be material, it would not be the first request for co-ordinated dox, but let it join the queue >:(
Ciao
Hi,
haddock is right (as so often): The preprocessing model is now returned if the "pre" port is connected to another operator or a process sink. You might recognize that an additional parameter is simply unnecessary: If you connect the port to use it, it is generate, otherwise you cannot use it at all...
And in near future the documentation will be maintained as a wiki: So maintaining it will become much easier. The most intriguing aspect of this solution is: I can always point you to the documentation and write: "So, now you can go ahead, go ahead and correct it yourself" :P
Greetings,
Sebastian
haddock is right (as so often): The preprocessing model is now returned if the "pre" port is connected to another operator or a process sink. You might recognize that an additional parameter is simply unnecessary: If you connect the port to use it, it is generate, otherwise you cannot use it at all...
And in near future the documentation will be maintained as a wiki: So maintaining it will become much easier. The most intriguing aspect of this solution is: I can always point you to the documentation and write: "So, now you can go ahead, go ahead and correct it yourself" :P
Greetings,
Sebastian
In short, it is not a parameter - it is boolean that you select if you want the normalisation model to be returned, You would use such a model to normalise other examplesets in a compatible way. Hope that is comprehensible