-
-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
How to handle TPS/ComplexTPS copy constructors #91
Comments
I updated my comment to better capture the issue |
We should talk when I get back. There will probably be needed a stack of current descriptors that can be pushed and popped. |
Sounds good. There's a lot of nuance here, too. For example, |
Yes my thought at this point is |
I think I'd agree, doing anything else might open up a can of worms that's much more complicated than this slightly asymmetric behavior |
I'm going to close this, because it seems like the current implementation of letting TPS(t1) be a full copy-ctor including the Descriptor is the best, and it also makes development easier in the normal form package |
Currently, there is a bit of an asymmetry between TPS constructors when copying an existing TPS and promoting a number to a TPS. Consider the case:
If one would like
b
to have descriptord2
, they must intentionally writeb = TPS(a, use=d2)
. On one hand, this ensures there is no implicit changing of descriptors, but on the other hand, there is different behavior when the descriptor can be inferred (TPS copy ctor) vs when the descriptor cannot be inferred (promoting a number to a TPS)@DavidSagan Should we instead make the default behavior be that if
use
is not explicitly passed, thenGTPSA.desc_current
is always used regardless of whether or not a number or TPS is passed (and thus there will be some internal implicit descriptor changing)?The text was updated successfully, but these errors were encountered: