Hi,
We’re experiencing strange behavior while using Weka Java implementation classifiers (say J48 for example).
We checked the Weka instances one against the other and they perfectly match. So does the classifier (before we write it to disc and after).
We suspect the classifier serialization (when writing and reading from the disk) but couldn’t point the specific error generator.
We also checked if maybe it’s a nominal String attributes issue, but using toLower().trim() on every possible String value didn’t solve it either.
Any suggestions how to solve it?
Thanks!
Ori
Thanks for your answers.
Turns out the problem was due to inconsistency in nominal values order.
Details:
Our flow basically have two parts –
-Learn:
-Classify:
Now turns out that Weka implementation is nominal values order sensitive –
Seems like the key reason is that on the low level Weka instance members are all of type double.
I would anticipate that Weka would be insert order agnostic, for example by re-sorting the nominal values after been declared. But this is a different story.
Our defect was due to the fact that we used HashSet to save the dictionaries values. Once reading the dictionaries – values order wasn’t the same as when we saved it.
The outcome was that we were now classifying wrong vectors (for example for the attribute [A,B], we were trying to set value A but due to the values order change our model thought its B).
That was the root cause of our defect.
The fix was quite simple – on the dictionaries, use SortedSet instead of HashSet, making sure order is consistent.
Resources for the Weka implementation –
- weka.core.Attribute#indexOfValue
- weka.core.Attribute#m_Hashtable
- weka.core.Instance#m_AttValues
- Badges
- Science topic
- Similar topics
- Filing