expose lr scheduler fields

[yueyinqiu]

#1314 (comment)

[asieradzk]

Seconding this, I would like to keep scheduler and swap out optimizer without having to instantiate a new one. This sucks for model loading.

[yueyinqiu]

As mentioned here #1314 (comment), although the fields would be exposed, they may not be modifiable. Actually if I were the one to decide, I'd prefer to make them read only.

Hmm... so what do you mean by "sucks for model loading", or what's the exact problem have you met?

[asieradzk]

As mentioned here #1314 (comment), although the fields would be exposed, they may not be modifiable. Actually if I were the one to decide, I'd prefer to make them read only.

Hmm... so what do you mean by "sucks for model loading", or what's the exact problem have you met?

When user of RLMatrix creates customised deep reinforcement learning agent with their own lrscheduler I have to ask them to make new one every time they load a model... since loading model involves creating new optimizer to continue training... and I can't just swap out optimizer inside previous scheduler, I need to make new one, replace cache, all that.

Additionally it sucks that lrscheduler needs to be created AFTER optimizer making it necessary for me to capture a delegate if I want to set everything up with a single method call..

[NiklasGustafsson]

Python can't prevent you from using fields outside of the class, but .NET can. That gives us the opportunity to be more careful about what is exposed and not. If there's a scenario where keeping the scheduler and its state, but swapping out the optimizer is useful, we can support that, but it's not as simple as making the optimizer field/property public.

There is scheduler state that depends on (at least) the number of parameter groups in the optimizer, so the scheduler state has to be reset when swapping out the optimizer. This has to be designed carefully.