TypeError : abs(): Argument #1 ($num) must be of type int|float, string given

[ma-gnesium]

This is:

- [x] a bug report
- [ ] a feature request
- [ ] **not** a usage question (ask them on https://stackoverflow.com/questions/tagged/phpspreadsheet or https://gitter.im/PHPOffice/PhpSpreadsheet)

What is the expected behavior?

Formatting a number with no run-time error

What is the current behavior?

TypeError : abs(): Argument #1 ($num) must be of type int|float, string given
in PhpSpreadsheet/Style/NumberFormat/NumberFormatter.php:74

What are the steps to reproduce?

Please provide a [Minimal, Complete, and Verifiable example]

As a unit test :

<?php

use PhpOffice\PhpSpreadsheet\Style\NumberFormat;
use PHPUnit\Framework\TestCase;

class NumberFormatTest extends TestCase
{
    public function testSmallValueWithComplexFormat(): void
    {
        $result = NumberFormat::toFormattedString(1E-17, '0 000.0');

        self::assertEquals('0 000.0', $result);
    }
}

What features do you think are causing the issue

• Reader
• Writer
• Styles
• Data Validations
• Formula Calculations
• Charts
• AutoFilter
• Form Elements

Does an issue affect all spreadsheet file formats? If not, which formats are affected?

This issue is independent of the spreadsheet file format used

Which versions of PhpSpreadsheet and PHP are affected?

Don't know exactly.
I'm currently using PHPSpreadsheet version 1.25.2 and PHP 8.1.9

[ma-gnesium]

I'm reconsidering this bug report.
The original intention was to format numbers using a thousands separator.

However, I've found that the correct syntax for this is to use the comma (,) character as a thousands separator, whatever the locale you're dealing with.

So the fix is simply to use the correct syntax: the TypeError is then not encountered and the result is correct.
This test passes:

    public function testSmallValueWithComplexFormat(): void
    {
        $result = NumberFormat::toFormattedString(1E-17, '0,000.0');

        self::assertEquals('0 000.0', $result);
    }

I will not be digging this issue further, but I'm wondering if we should we keep this issue open.
Indeed, if the format 0 000.0 is allowed, I wonder what the outcome of using it should be, while it certainly shouldn't produce a run-time TypeError with specific values.

[MarkBaker]

As a mask, '0 000.0' is valid, and should be treated as a complexNumberFormatMask; it's saying that there should always be a space character in that position if there are more than 3 non-decimal digits, regardless of the locale, and if there are less than 3 non-decimal digits, then the value should be padded with 0 characters in those positions.

So 123.45 is displayed as 0 123.45; 12345.6 is displayed as 12 345.6, 12 is displayed as 0 012.0

[ma-gnesium]

Thanks.

I would like to clarify the report:

Expected behavior:
Using the '0 000.0' mask, the expected display of 1e-17 should be 0 000.00000000000000001, and 1e17 should be displayed as 100000000000000 000.0.

Current behavior:
As soon as the conversion of a value to a string involves scientific notation, using a complexNumberFormatMask produces a TypeError.

Correct?