Edit report at https://pear.php.net/bugs/bug.php?id=21072&edit=1

  ID: 21072
  Comment by: pear@0xdecafbad.com
  Reported By: pear@0xdecafbad.com
  Summary: Allow calculateTotalsFor() to parse formatted numbers
  Status: Open
  Type: Feature/Change Request
  Package: Console_Table
  Operating System: irrelevant
  Package Version: 1.3.0
  PHP Version: Irrelevant
  Roadmap Versions:
  New Comment:

I should have said "also incorporates the trivial fix ..." as both are
in there.

Previous Comments:

[2016-05-31 15:13:45] bmcdanel

Added #patch


[2016-05-31 15:11:57] bmcdanel

When a filter is applied it will be processed before
calculateTotalsFor() is processed. This can be a good thing as
numbers can be altered during
the format stage. If calculateTotalsFor() was processed first
then 2+2=5 could happen for large values of 2 and a formatting
stripping the
fractional part (eg float to int).

A simple method that requires you to specify or use a default
can be found at https://gist.github.com/msng/1504235
calculateTotalsFor() could take additional optional parameters
that would specify the additional data or it could be set
somewhere else.

Below I try to explain the challenge to unformatting a number
without knowing what the integral separator and decimal
separator are. I think
that it will largely push towards having the user just declare it
based on the data they presumably know the format for.

There are 3 main categories for numbers. Sign, integral part,
decimal part. Some examples of different formatting styles can
be found at

This can be a variety of things.
+123 = 123
123 = 123
-123 = -123
123- = -123
(123) = -123
%r123 = -123 (color formatting, red)

This is often one of two characters a comma or a full stop
(period). There is never more than one fractional separator
however with an integer it
may not be present.

This can be one of several characters. a comma, space, full
stop, ' (in a couple styles). There may be more I am unaware
of. It may or may not
be present, and groupings may be 2, 3 or 4 digits. It will
always be left of the fractional separator except when it is not
(eg right to left
languages like those in the Middle East).

You cannot programmatically parse all numbers.
1.000 could be 1000 or it could be 1 unless you know the
fractional separator and the integral separator ahead of time.
You cannot rely on the system locale as it may be serving data
intended for someone using a different locale

SCIENTIFIC NOTATION and other numerical schemes
outside the scope for this, although it could be added easily

My patch incorporates the trivial fix for


Search Discussions

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 1 of 1 | next ›
Discussion Overview
grouppear-bugs @
postedMay 31, '16 at 7:14p
activeMay 31, '16 at 7:14p

1 user in discussion

Pear: 1 post



site design / logo © 2022 Grokbase