When providing a NumProperty property type to a PropertyDefinition the mapped value must be exclusively of type double, respectively Double. Anything different results in a failure to parse and blank fields being displayed. I have tested it with Integer, Long and Float. Although this might be so by design, it is definitely not the straightforward behaviour, judging by the name.
This also brings some side-effects - integer values must be (and have been) represented as floating point numbers in order to be displayed in the table and let be analyzed. Such examples are atom counts and molecular weights among others.
A nice alternative could be to either provide functionality for the remaining numerical types and their recognition under a combined NumProperty type or to just separate it. At the very least, an integer recognition/property should be implemented.
The reason for one specific type is that we need to map the properties to some database column. It is already cumberson to distiguish between string and numerical properties since you need a special treadment in each class actually using that property.
We have chosen double as type, since it is the most general one for storing numerical values. It can store Integers up 2^53 exactly and much larger numbers with precision loss. Float is also just less precision.