reduce incorrectly removes parenthesis in mathobject string.

[somiaj]

When using reduce (with a double negative) parenthesis are removed from the ->string. Here is my test case

DOCUMENT();
loadMacros(
  "PGstandard.pl",
  "PGML.pl",
);
TEXT(beginproblem());

$a = Formula("-4x^2")->reduce;
$test1 = Formula("e^(-$a)")->reduce;
$test2 = Formula("e^(-$a)");

BEGIN_PGML
**Test 1:**
+ String: [$test1->string]
+ TeX: [``[$test1]``]

**Test 2:**
+ String: [$test2->string]
+ TeX: [``[$test2]``]
END_PGML

ENDDOCUMENT();

This causes the ->string to loose the parenthesis , but ->TeX is fine.

I think this is related to a similar bug, but it wasn't fully fixed in issue #455 and the pull request #546.

[dpvc]

This turns out to be a bad interaction between two different reduction rules. I have made a pull request to fix it (linked above).

[somiaj]

Thanks, I can confirm this fixes the issue.

@dpvc I notice you only have a pull request for develop, this bugfix seems reasonable to fix in main as well (imo).

[dpvc]

I will let others make that call. I'm not up on the release process any more. If so, then the PR should be rebased to main and targeted there, and then targeted to develop as well. But that may not be how things are done any longer.

[drgrice1]

@dpvc: That is pretty much it. Rebase and retarget.

I am not sure if this should be a hotfix or not. I am not certain that is so pressing. It is really a display issue, and those are usually things that we defer to the next release.

What do others think?

[somiaj]

@drgrice1 The reason I think it should be put in main is because although the original mathobject is correct, the string is used to build future mathobjects, so any mathobject built using this mathobject, such as $test3 = Formula("5 + $test1") will be incorrect (which is how I ran across this issue in the first place). I can patch locally, I just thought this might be pressing enough due to this.

[dpvc]

The only time it would be a computation issue is if the reduced function is then inserted into another string (for Compute() for example), then the result would be wrong. But as it has been that way for 14 years (that is when the noParens section was added), I suspect it is not crucial. I see @somiaj pointed out the same issue with using it in alternative strings. Of course, his example could be done as $test3 = 5 + $test1 without causing error, other examples are harder to handle that way without a little more care.

[drgrice1]

As @dpvc pointed out, it has been that way for a long time. We can't just run to put in a hotfix every time a minor issue comes up.

It won't work in further computations, so work around it for now. There are other ways to do it.

[somiaj]

Thanks for the clarification.

[drgrice1]

Again, I am waiting on other opinions. So if the general consensus is that this is hotfix worthy, then we will put it in.

[pstaabp]

I think, also, we can wait for the next release. I'm not sure how many people pull in hot fixes to their servers anyway and it's not a security bug. @somiaj , maybe make a post on the forum discussing this so people are aware.

[somiaj]

Fixed with #635.