Why are features usually named automatically in Cleartk?

[Majid Laali]

Hi, 

I am wondering why all features' name are set automatically and there is no way to set a user's defined name to a feature in Cleartk. In my view, have a user's define name for features can add more semantic to the features. 

Thanks, 

Majid

/*******************************************

 *   Majid Laali, Ph.D. Candidate, 

 *   Computer Science & Software Engineering Department

 *   Concordia University

*******************************************/

[Steven Bethard]

You can always name a feature: `new Feature(name, value)` will work just fine.

If you're talking about feature extractors, you can add extra info to
the names they generate using something like NamingExtractor:

https://code.google.com/p/cleartk/source/browse/cleartk-ml/src/main/java/org/cleartk/ml/feature/extractor/NamingExtractor1.java

Steve

> --
> You received this message because you are subscribed to the Google Groups
> "cleartk-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to cleartk-user...@googlegroups.com.
> To post to this group, send email to cleart...@googlegroups.com.
> Visit this group at http://groups.google.com/group/cleartk-users.
> For more options, visit https://groups.google.com/d/optout.

[Majid Laali]

Thank you for your response. 

First, let me make it clear that I am talking about the feature extractors. Although NamingExtractor1 can rename a feature, there are some other extractors that can not benefit from NamingExtractor1. For example NamingExtractor1 cannot be used in both FeatureExtractor2 and FeatureFunctionExtractor. Absolutely, we can define two new classes for these two classes (e.g. NamingExtractor2 and NamingFeatureFunction). But I still have a question why beside the default constructor, we do not create a constructor that gets a user's defined name for the feature. In that case, I believe the code would be more readable without adding a overhead to current codes.

Thanks, 

Majid

[Steven Bethard]

We actually had it that way in some classes a few years ago, but that
means that you need to declare an alternate constructor in each
feature extractor class, and then make sure that the alternate
constructors for all the different feature extractor classes are alway
consistent and never get out of sync when bugs, etc. are fixed in some
of the feature extractors.

The advantage of the NamingExtractor1 approach is that it provides the
same functionality as adding an extra constructor to all
FeatureExtractor1s, and the code for it is all in one place and thus
trivially stays in sync.

I agree it would be a little more convenient to have the alternate
constructors, but the maintenance burden would be much higher. (And
we're already not doing a wonderful job of staying on top of the
ClearTK maintenance burden.)

Steve