@adonnini No need to worry. I was operating under the assumption you’ve experimented with these apis already. I remember us briefly discussing this on the forums once before which is why I just mentioned what I did.
Regarding the rest of your frustration with SDVariables…it’s because your’e fighting the framework.
A samediff instance provides all the necessary apis you need. If it’s not there then it’s probably for a reason.
I already mentioned why it’s like that. It’s because we have internal state. SDVariables need to be registered with the samediff instance, otherwise they aren’t useful for anything.
If you need to create a variable use sd.var(…). We handle creating the variable.
set andgetArr(…) are mainly internal apis. Those should probably be better encapsulated. Unfortunately, the package definitions prevent that.
I’ve asked you multiple times not to invent new solutions to problems. If you don’t see an example for it, there’s probably a reason and you are welcome to ask how to do something.
Now please accept that samediff has internal state, it works like that for a reason. That reason being, arrays get updated, variables can have multiple values. The reason for that is because each samediff .output creates a new “session” internally. That session does a feed forward for each op in the graph at the time of definition. This is to prevent values from being overridden.
Samediff being declarative means you can randomly call .output(…) and then if you want add another variable to the graph. That means that the graph for execution is recreated each time.
If you’re randomly changing things then you’re breaking the expected behavior of the framework.
Variables for the most part are meant to be immutable.
If you absolutely need to (despite having placeholders as well as a fit method which are meant to provide this behavior in the first place) then yes you use associateArrayWithVariable.
Please try to understand here that when I assume you know something I just try to point you in the right direction. If you need more information, ask. That’s what you did. Thus, I’m replying.
Beyond that, please accept this advice from one programmer to another. If you have to fight a library to get something done it’s probably because it’s not the intention of the library to be used like that. There might be reasons for that that are obvious to the end user.
With that out there, whether its’ correct or not is a separate discussion I’m more than willing to have.