Using `sprintf` was causing rounding to ~ 5 dp, definitely not what
we want!
Using Math::BigFloat should be fine, as styling numbers should not occur
en masse - only during conversions to/from user input.
In some cases, we have numbers which are _already_ in the appropriate
style. Most notably, when considering the user input values from which we
made the style determinations in the first place.
This fixes the bug, but is still unsatisfying because we would need
to convert both in and out in order to do better input styling.
Reducing scroll spam from dzil by:
- Providing ABSTRACTs for all packages.
- Leaving VERSION vertical space where necessary.
Addresses #600 plus other annoyances in the process.
Basically, we're only going to recognize negative numbers when they
appear at the beginning of an expression. Otherwise we assume we don't
needs to deal with them.
I'm sure this causes other problems, but resovles the testing issues for
now.
This allows for us to continue to style negative numbers, but to assume
that "embedded" `-` characters are atually operations.
It's quite an ugly hack.. and this whole quasi-state machine needs
revisited, but this gets everything working for now.
By extension, this also permits negative exponents.
Also breaks a calculator test with a crazy expression where we can't
differentiate between subtrction and negative numbers. Leaving it
broken for now, since the tokenizing is known broken, anyway.
This also required some additional changes to how number_regex is
computed. That was sort of overdue, anyway.
HTML styling is simply display styling plus super-scripted exponents, at
thispoint.
Also, minor updates to Conversions to make it work there.
NB: This is clearly not properly factored, yet! This is the first step
to get feedback and improvements from @mintsoft.
- Make number style stuff aware of how to deal with case-insensitive
expoentials.
- Produce consistent output of such strings.
The display format was chosen to be consistent with the output for
Calculator. Also, the parsing is not quite correct as you can't have a
mantissa in the exponent, but this won't catch that.
Should we also do "for_display" on the factors for consistency?
Any and all feedback or improvements are appreciated.
This also breaks the Calculator tests, but I will worry about fixing
those once everything stabilizes.
Based primarily on feedback from @moollaza:
- Straighten up the English a bit to make it more comprehensible.
- Move comments before the code they describe.
I am not claiming this is entirely the correct way to do this in this
package, just that it works fairly easily to expand the scope of the
Conversions goodie, as well.
Gonna need feedback from @moollaza and @mintsoft.
On the upside, I found a bug in the styler code by writing a test here!
Considering how all of this works, I'm not sure roles are quite the
right fit. It seems like we might just want a shared "Utility" package
or namespace to let us have access to some common library functions.
DDG::GoodieRole::NumberStyle is a particularly horrible name because
it's not even a role!
Also, the comments suck.
But such is the nature of a proof-of-concept.
Ben Moon
Matt Miller
Rob Emery