Add support for transforming numeric predictions that were normalized

[jimthompson5802]

Code Pull Requests

Proposed solution for the following situation: If a numerical output feature is 'normalized', e.g., 'zscore' or 'minmax', predictions are returned in the 'normalized' value space instead of the output feature's value space. This PR adds functions to do the inverse transformation on output features that were normalized.

[jimthompson5802]

@w4nderlust just marked this ready for review. Summary of changes:

• added inverse transformations for zscore and minmax normalizations for output feature
• added new normalization log1p that performs ln(1 + x) and its inverse exp(x) - 1.
• Wrapped the above in an object structure with transform() and inverse_transform() methods
• Created registry for the transformation objects.

Let me know what you think. If this looks good, I'll add a unit test for the transformation/inverse transformations.

[jimthompson5802]

@w4nderlust your comments were perfect, code looks cleaner. Once I add the unit test, this should finish off the PR.

[w4nderlust]

@tgaddair we are almost done on this, but before merging I'd first merge your PRs, as this may need to be adapted acordingly. Do you agree?

[tgaddair]

@w4nderlust yeah that sounds good. It should be fine to merge #1014 followed by this PR. The other should not conflict.

[w4nderlust]

This looks good to me now. Let's hold a sec before merging as @tgaddair suggested. In the mean time we could add a test ;)

[jimthompson5802]

Added unit test for numeric transformers.
While not related to numeric transformers, I adjusted internal variable names in the cached checksum test.

[ifokeev]

Thanks for the feature. We use this code to postprocess numeric:

def postprocess_value(feature_name, value, train_set_metadata):
    # remove suffix
    norm_feature_name = feature_name.replace('_predictions', '')
    post_value = value

    if norm_feature_name in train_set_metadata:
        feature_data = train_set_metadata[norm_feature_name]

        idx2str = feature_data.get('idx2str')
        normalization = feature_data.get('preprocessing', {}).get('normalization')

        if idx2str:
            post_value = idx2str[value]
        elif normalization == 'zscore':
            mean = feature_data['mean']
            std = feature_data['std']
            post_value = float(post_value) * std + mean
        elif normalization == 'minmax':
            min_val = feature_data['min']
            max_val = feature_data['max']
            post_value = float(post_value) * (max_val - min_val) + min_val

    return post_value

and that's pretty awkward. Your solution is more robust

[jimthompson5802]

@ifokeev Thank you. Glad the feature is helpful.

[jimthompson5802]

@ifokeev I forgot to ask. In your postprocess_value() function, I noticed this code fragment:

        idx2str = feature_data.get('idx2str')
        normalization = feature_data.get('preprocessing', {}).get('normalization')

        if idx2str:
            post_value = idx2str[value]

This code implies an output feature type that is non-numeric. Would a similar capability be useful in that other feature type? What is the use case around that other feature type?

[ifokeev]

@jimthompson5802

Would a similar capability be useful in that other feature type?

Yeah. That's very useful.

What is the use case around that other feature type?

As I understand there are still no support for category postprocessing. And maybe some others.
I had to postprocess myself all the time.

https://github.com/uber/ludwig/blob/ecbcf334f762484b22cd171a666bea75921dc202/tests/integration_tests/test_savedmodel.py#L170

[w4nderlust]

The category postprocessing should alreadydo that:
https://github.com/uber/ludwig/blob/master/ludwig/features/category_feature.py#L407-L411