Skip to content
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

Ensure multiplication is performed on a non-array value #2964

Merged
merged 5 commits into from
Aug 7, 2022
Merged

Ensure multiplication is performed on a non-array value #2964

merged 5 commits into from
Aug 7, 2022

Conversation

u01jmg3
Copy link
Contributor

@u01jmg3 u01jmg3 commented Jul 28, 2022

This is:

- [x] a bugfix
- [ ] a new feature
- [ ] refactoring
- [ ] additional unit tests

Checklist:

Why this change is needed?

Provide an explanation of why this change is needed, with links to any Issues (if appropriate).
If this is a bugfix or a new feature, and there are no existing Issues, then please also create an issue that will make it easier to track progress with this PR.

Fixes #2953

@@ -742,6 +743,9 @@ public function arrayTimesEquals(...$args)
$value = trim($value, '"');
$validValues &= StringHelper::convertToNumberIfFraction($value);
}
if (is_array($value)) {
$value = Functions::flattenArray($value)[0];
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This could be more robust and changed to:

$flattened = Functions::flattenArray($value);
$firstKey = array_key_first($flattened);
$value = $flattened[$firstKey];

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The whole of the JAMA library should really be replaced completely; the code is awful and without tests, and it's no longer a supported library. Unfortunately, I've yet to find a matrix library that actually uses MS Excel matrix logic, so I've been building my own but that's still Work-in-Progress

Copy link
Contributor Author

@u01jmg3 u01jmg3 Jul 29, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would be curious to see your WIP when it's ready.

Can we still progress this fix? I've applied it here but that's not to say it couldn't be caught and rectified higher up in the code. This is just my assessment and what I've found to fix my problem.

@u01jmg3
Copy link
Contributor Author

u01jmg3 commented Aug 4, 2022

@oleibman, @MarkBaker: anything more I can do to get this merged? Thanks

@oleibman oleibman merged commit 7f0ca40 into PHPOffice:master Aug 7, 2022
MarkBaker added a commit that referenced this pull request Aug 7, 2022
…multiplication, and both left and right side values
MarkBaker added a commit that referenced this pull request Aug 7, 2022
Expand PR #2964 to cover all arithmetic operators, and both left and right side values
MarkBaker added a commit that referenced this pull request Aug 7, 2022
MarkBaker added a commit that referenced this pull request Aug 7, 2022
Additional for PR #2964; validate value after extracting from flattened array
oleibman added a commit to oleibman/PhpSpreadsheet that referenced this pull request Dec 23, 2022
The code under `Shared\JAMA` is called from exactly 3 places in Calculation, and exactly 1 other place (see next paragraph). These places are inadequately covered in the test suite, so it is not clear that the existing code works. In addition, see PR PHPOffice#2964 for commentary decrying the continued used of JAMA. I will also note that it has a pitiful 8.20% coverage in the test suite. There seems to already be a perfectly adequate equivalent in Calculation for those parts of JAMA which are used (e.g. we don't use any decompositions, so the fact that no decomposition code is present in Calculation is not a problem). This PR replaces the uses of JAMA within Calculation with `checkMatrixOperands`, and deletes Shared/JAMA entirely (which, among other thing, makes many Phpstan reported problems go away). The test suite is enhanced to ensure coverage of all the changed statements. A side benefit of deleting Shared/Jama is that the only function which PhpSpreadsheet has added to the global namespace (hypo in Maths.php) goes away.

There is one additional use in Shared/Trend/PolynomialBestFit. That use is best replaced with Matrix/Matrix, which is already a requirement for PhpSpreadsheet. PolynomialBestFit has zero test coverage, and I didn't add any for this change. There seem to be existing errors which both Phpstan and Scrutinizer complain about, and I am quite convinced that they are not false positives. Fixing those problems will be a project for another day.

Calculation has many calls to `Information\ErrorValue` and `Information\ExcelError`. It is inconsistent in how it does so - most invoke `Information\E...` but a small number take advantage of additional `use` statements to just invoke `E...`. I have made the usage consistent by changing the small number to act like the majority and eliminating the `use` statements.

Some of the test cases exposed the fact that MAX, MAXA, MIN, and MINA do not properly handle error strings in their input. For example, if cell A1 contains 2, and A2 contains `=5/0`, `=MAX(A1, A2)` should return `#DIV/0!`. They are changed to handle them properly.

`Shared\JAMA` was normally omitted from code coverage. Since it is being deleted, there is no longer a reason to explicitly exclude it. `Writer\PDF` was also on the exclude list, probably for historical reasons, but there is no reason to exclude it now (it is, in fact, 100% covered), so it will no longer be excluded.
@oleibman oleibman mentioned this pull request Dec 23, 2022
7 tasks
oleibman added a commit that referenced this pull request Dec 30, 2022
* Eliminate Shared\JAMA

The code under `Shared\JAMA` is called from exactly 3 places in Calculation, and exactly 1 other place (see next paragraph). These places are inadequately covered in the test suite, so it is not clear that the existing code works. In addition, see PR #2964 for commentary decrying the continued used of JAMA. I will also note that it has a pitiful 8.20% coverage in the test suite. There seems to already be a perfectly adequate equivalent in Calculation for those parts of JAMA which are used (e.g. we don't use any decompositions, so the fact that no decomposition code is present in Calculation is not a problem). This PR replaces the uses of JAMA within Calculation with `checkMatrixOperands`, and deletes Shared/JAMA entirely (which, among other thing, makes many Phpstan reported problems go away). The test suite is enhanced to ensure coverage of all the changed statements. A side benefit of deleting Shared/Jama is that the only function which PhpSpreadsheet has added to the global namespace (hypo in Maths.php) goes away.

There is one additional use in Shared/Trend/PolynomialBestFit. That use is best replaced with Matrix/Matrix, which is already a requirement for PhpSpreadsheet. PolynomialBestFit has zero test coverage, and I didn't add any for this change. There seem to be existing errors which both Phpstan and Scrutinizer complain about, and I am quite convinced that they are not false positives. Fixing those problems will be a project for another day.

Calculation has many calls to `Information\ErrorValue` and `Information\ExcelError`. It is inconsistent in how it does so - most invoke `Information\E...` but a small number take advantage of additional `use` statements to just invoke `E...`. I have made the usage consistent by changing the small number to act like the majority and eliminating the `use` statements.

Some of the test cases exposed the fact that MAX, MAXA, MIN, and MINA do not properly handle error strings in their input. For example, if cell A1 contains 2, and A2 contains `=5/0`, `=MAX(A1, A2)` should return `#DIV/0!`. They are changed to handle them properly.

`Shared\JAMA` was normally omitted from code coverage. Since it is being deleted, there is no longer a reason to explicitly exclude it. `Writer\PDF` was also on the exclude list, probably for historical reasons, but there is no reason to exclude it now (it is, in fact, 100% covered), so it will no longer be excluded.

* Scrutinizer

Eliminate some newly dead code.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

Unsupported operand types in Matrix.php:746
3 participants