-
Notifications
You must be signed in to change notification settings - Fork 19
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Multiple instances of the same feature extractor with different configurations should be possible #39
Comments
Reported by |
Reported by
|
Reported by |
Reported by
|
Reported by
|
Reported by
|
Reported by |
Reported by |
Reported by
|
Reported by
|
Reported by |
Reported by |
Reported by |
Reported by |
Reported by |
how far is this issue? Is this usable yet? |
@daxenberger ping :) |
We have implemented a prototype of this, but not merged it into the trunk yet. |
@reckart I have some import resolution errors in a demo case that uses an ExternalResourceDescription as parameter for a feature extractor. Any idea for the origin of the exception?
|
@Horsmann try increasing the logging level so that lab prints the actual discriminator values that it compares and whether they match or not. |
The I think this line says it doesn't find the feature
|
Since all the features are now discriminable (right?) the discriminators should no longer contain the full specified text, no? |
Well, the discriminator uses also the parameters to have a full feature description and not just the name of the feature class e.g. |
Ok, that makes it verbose ;) Maybe you don't keep a strict ordering when writing out your discriminator values? Mind that discriminators are compared based on their string values. If you have any non-determinism (e.g. using Sets or HashMaps which don't guarantee an order) you can get such effects. |
ok. I capture the |
Originally reported on Google Code with ID 39
Reported by
torsten.zesch
on 2013-08-07 16:01:42The text was updated successfully, but these errors were encountered: