Eval of '! + 1' returns an empty string, so we'll make it less likely
for that to happen (by not initializing tmp_result to an empty string)
and guard against it if it still does.
Of course, this shouldn't trigger on '! + 1', so that still needs to be
resolved.
This is a port of the previous tests for these functions, updated for
its new status as a role. I can be convinced that this is not the best
way to do this, but it seems well-enough to me.
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.
This uses Bit::Vector rather than presuming anything about the perl
support for 64-bit ints. This seems safer, even if it's a smidge slower.
This fixes issue #564 with test demonstrating such.
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.
The major change is matching the exponentials more carefully. They only
count if they have <number>E<integer> otherwise they won't work.
Also include a suggested change from @mintsoft to better handle the
spacing of numbers and units in Conversions, by separating them using
our defined regexes.
All-in-all, much more resilient!
This may (or may not) give a nicer look and more clear understanding of
how the input was interpreted.
Looking for feedback from @mintsoft on whether or not this is actually
better. (Take a look at the test changes in particular to see the
effects.)
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.
Rob Emery
Dani
Matt Miller
Caine Tighe
Jag Talon
jagtalon
Zaahir Moolla
David Wilkins