Conversation
It is much easier to reason about multivector objects if they are are not mutated unexpectedly. This changes the following functions to not mutate their arguments. Any code relying solely on the return value will be unaffected: * `Metric.applymv` * `Mv.diff` * `Mv.simplify` * `Mv.expand` * `Mv.collect` This also changes `Mv.Mv_str` and `Mv.Mv_latex_str` to not mutate their multivectors when they are printed - this is super surprising behavior
This was a bad workaround to pass variables to a closure in the printer
6ce004b to
588c016
Compare
|
This pull request introduces 1 alert when merging 588c016 into 159cc2a - view on LGTM.com new alerts:
|
|
@utensil, CI seems to be producing unhelpful output in https://travis-ci.com/pygae/galgebra/jobs/264351319. Any idea how to debug? (edit: found the bug, but working out how to make CI more useful might still be worth it) |
|
This pull request introduces 1 alert when merging 094e06f into 159cc2a - view on LGTM.com new alerts:
|
This pattern of output log suggests that:
1 is not outputing useful info due to the mechanism in The easiest way to debug it is to run 1 by ourselves and see what it outputs. Expecting more requires contributing to
|
|
I'll take a look at nbval at some point, thanks for the summary. |
|
Guess I'll fix the LGTM warning in a follow-up - I supposed the cost of the warning is outweighed by the reduced surprise for @meuns :) |
Introduced in pygaegh-141, which removed all uses of this variable but forgot to remove it.
Introduced in gh-141, which removed all uses of this variable but forgot to remove it.
It is much easier to reason about multivector objects if they are are not mutated unexpectedly.
This changes the following functions to not mutate their arguments. Any code relying solely on the return value will be unaffected:
Metric.applymvMv.diffMv.simplifyMv.expandMv.collectThis also changes
Mv.Mv_strandMv.Mv_latex_strto not mutate their multivectors when they are printed - this is super surprising behaviorcc @meuns