ML
ML copied to clipboard
Typed property Rubix\ML\NeuralNet\Layers\Multiclass::$softmax must not be accessed before initialization
Hi all,
Thanks for you awesome project.
I have got this error after upgrading from version 1.2.2 to 1.23 and trying to infer with a Multilayer Perceptron model built before upgrading :
- Typed property Rubix\ML\NeuralNet\Layers\Multiclass::$softmax must not be accessed before initialization at ...\vendor\rubix\ml\src\NeuralNet\Layers\Multiclass.php:143
Shoulnd't minor version upgrades avoid breaking changes ?
Version 1.2.3 contains no breaking changes to the public API of the library as far as I know. There was a renaming of the private variable that references the Softmax activation function instance, however, this does not affect the public API. It does, however, affect models that were persisted using a different version of the library. Unfortunately, the persistence mechanism leaks all the internal implementation details. This is a known issue and there are solutions but unfortunately, we currently do not have the resources to move forward with implementing them.
https://docs.rubixml.com/1.0/model-persistence.html#caveats
Please see this section of the documentation that describes the issues you may run into when running a model trained on a different version of the library than is used for inference (or partial training even). I had the idea of adding a "translation layer" that would maintain backward compatibility even for internal properties. ONNX is an example of this type of layer, but since I had to take a day job, I simply do not have the time or resources anymore to dedicate that amount of time and energy to implementing that feature in Rubix ML.
See https://github.com/RubixML/ML/issues/58
Having that said, if you're using the RBX model serialization format, this type of scenario should be detected. Are you using RBX or a different serialization format?
https://docs.rubixml.com/1.0/serializers/rbx.html
HI,
Okay no worries I'll stick to the 1.2.2 version for the moment, thanks for your detailed explanation.
These models were created quite a long time ago indeed (nearly 1 year), and they have been persisted using the Native format.
Ok, I apologize for the inconvenience. While we are waiting for a complete solution, I will try to be mindful of renaming of private properties in a bugfix release. I think that would be a happy medium between maintaining development velocity while not requiring too much retraining for models that were trained on an older incompatible version.