Please see Jianxiong Dong's solr learning_to_rank (normalizer) unmatched argument type issue email on the user mailing list for details on how this bug manifests.
Implementation choice background:
- If the number were to be saved as a number then 4.2 could be considered either as a float or as a double and hence the normalizer classes would need setters for both those possibilities. Equally, 42.0 could be saved as just 42 which then could be either an int or a long and so again setters for both possibilities would be needed. All this complexity is avoided by saving the number as a string. The class has convenience float setters which can be handy for use in tests.