Open JohnGoertz opened 4 years ago
I think that it's desired behaviour, as far as sympy is concerned. The good news is that we subclass Symbol fairly transparently: could you try b = symfit.Parameter(name='b', cls=sympy.Dummy)
and see where it breaks?
This was also discussed a while ago in #124
@pckroon this breaks directly on TypeError: __new__() got multiple values for argument 'cls'
Its possible to change the parameter creation from
params = symbols(names, cls=Parameter, seq=True, **kwargs)
cls = kwargs.pop('cls', Parameter)
params = symbols(names, cls=cls, seq=True, **kwargs)
To then get Dummy
instances back, however they won't work because they don't have the required Parameter
functionality (eg assign value/min/max)
Making Parameter
a subclass of Dummy
instead of Symbol
does do the trick, seems to pass all tests also.
Is there a reason to want Symbol
behaviour over Dummy
behaviour?
Is there a reason to want
Symbol
behaviour overDummy
behaviour?
This is a very good question. I believe that if we coded everything correctly, there shouldn't be any difference since we never really do thing like Symbol('x') == Symbol('x')
in symfits core. But changing that globally is a pretty big API change which could change some behavior. Although like you notice, all the test still work and the current Arguments
can also be initiated without a name which is meant to achieve the same thing but does so in a worse way.
So thinking about it now, there is actually a lot to be said for this. My biggest concern is actually not the impact on symfit functions, but how these objects would interact with sympy itself.
One way I can think of this going wrong is the user defining a parameter once with a certain name and then doing the same thing again later with the expectation that this gives the same sympy symbol. But I find it very unlikely that a user would expect this behavior or would do something like that.
I also think that is bad practice, and it is much easier when coding to reuse the same symbol then to type Symbol('x')
again. But I think introducing a DummyParameter
is a fine solution, and then we could also get rid of the Parameter()
syntax and replace it by DummyParameter()
where needed.
I'm not sure if this would break everything, but it would be very useful to be able to construct parameters/variables that inherit sympy's
Dummy
class instead of theSymbol
class. The reason being that if multiple variables are created with the same string input, they are the same object and changing one changes the other.This is even true if these variables are containerized into class instances.
Sympy solves this through the Dummy variable class, so if there was an alternative constructor for symfit's
Argument
class to extend Dummy, that (should) fix the issue.Now, I'm not sure if this is more properly a sympy bug or if this is actually desirable behavior, or if it would be a nightmare to implement, but... it would be nice.