This adds the ability for numbers to contian spaces or underscores. It
also makes me recognize once more how brittle all of these
inter-relationships are.
With the addition of the number styling role, we've improved the output
for very small floats. We don't need to round them any longer, since
they produce comprehensible display values and don't break anything.
This one is much harder to hit, because the dotted quads must have 3
digits in each of the last 3 positions and they tend to start zero-ing
the mask earlier, but might as well cover this better, too.
Thanks to @mintsoft for the heads-up.
If we get a dotted quad, slash and a number in the range of 0-32, it
seems more likely this is talking about network addresses, than trying
to do a calculation.
I, personally, think it's unlikely we ever should be dealing with dotted
quads, but I want to leave in the possiblity of a pasted-in euro-style
value.
Fixes#541.
This regex overreaches a bit, because query_nowhitespace doesn't
guarantee we'll see word-breaks exactly where we might expect. This is
sufficient for now, but this triggering needs a general rethink.
Addresses some concerns in issue #517.
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.
This would be better with some proper parsing, but this resolves some
issues with the current HTML output, making it raise things to
arbitrarily high superscripting levels based on what it seems to look
like.
There should never be a thousands separator in that place, so don't
allow one. This was a bit masked by taking all of the numbers in
combination which gave them more context.
Testing a number individually exposed the error.
This includes multiplication and division in things which should not be
rounded to our determined precision. While this doesn't break any
current tests, it might lead to some surprising floating-point issues.
On the other hand, the other way led to some surprising results where
418.10 / 2 != 418.1 / 2
Hopefully there exists a better long-term solution which we'll find soon
enough.
Addresses issue #509.
This is an attempt to add the requested "squared" operation without all
of the nasty trigger changes I introduced last time I tried.
Also added a constant for 'score' as both an attempt to better
understand that trigger regex and an historical oddity.
It's clear that if I want to continue with this I should make a lexer.
This mostly just adds style to the HTML answers to be more in line with
other IAs.
The test changes are because, in general, the HTML answer is exactly the
same as the text answer, just wrapped up in some HTML. We're mostly
concerned with if we get correct answers, not how they happen to be
wrapped for HTML display.
In cases where that's different (the <sup> regression) we do more
thorough testing on the contents.
Also, removed one repeated test.
I'm starting to think this "apply_css" and maybe even "wrap_html" should
be in a role somewhere.
Total run time may well exceed 1 second with the pre- and post-
processing, but this makes it significantly less annoying to try things
out with `duckpan query`.
Also adds a test which shows the `duckpan query` parameters I was
trying, showing how `squared` is applied (and may result in confusion)
This fixes the problem of the simple case, but handling, say, expressions
in parens would require a lot more thought (a lexer would help!) I'll
leave that problem for another day.
Fixes#483.
Some of the problems inherent in the old trigger regex made themselves
obvious once the 'squared' operation was added. This simplification
should make maintenance a smidge easier.
Resolves#482.
Because of floating-point issues, sin(pi) does not come out to exactly
0. It looks like something we try to guard against a couple lines down.
So, if we don't have a defined precision (such that we can let sprintf
worry about the correct answer), we will set these very small values to
0.
This worked fine with things like '1 + sin(pi)' which made the whole thing
more confusing at the start. Thus, this commit also includes a passel of
new tests for things I considered as possible faults, plus one other thing
I wanted to demonstrate working [cos(2pi)].
- Make ln alias more like others.
- Put named constants in a hash and generate the substitution list
therefrom.
- Update test and comment text slightly for accuracy.
I had fixed a number of different problems iteratively and didn't
recognize that these changes were viable until now.
Also, to get the value of pi.
In service of this change, also add some additional available functions.
Not so much because I think people were clamoring for secants, but as a
way of expanding expectations for the nascent parser: fix replacement
issues with 'e', better description of what a "function" might look
like, etc.
We want the precision to be just like our input, except when there are
hidden factors in the functions which will cause us to want much more.
Because of how we do this (via `eval`) the func list is almost certainly
wrong. Precisely defining our input is (still) yet to come.
Added some tests to show how we handle very small floats and other
related issues, plus a recommended test from an early issue comment
which I somehow missed.
This is mostly an attempt to make it easier (for me) to read and
identify everything which needs to be covered in any further
refactoring.
There is one funcational difference: 'c' is no longer an acceptable
constant. I was vaguely bothered that it was the only one with units,
anyway and once it made the parsing of 'cos' turn ugly, I just ripped
it out.
Also added a test for an identifiable regression from a former code
comment.
We want to make sure that we catch all of the numbers, even if they are
inside parens, so we add some extra spacing (on request) in `spacing` to
make sure we can find them. I think there may still be a problem with
1E2-style numbers, but that's always been there. :(
As part of this, also switched the "sub" versions back to strings so I
can concatenate for the "numbery" regex. This is not a big deal
since all the functions are getting built early anyway.
And added some more tests to make sure this works as intended.
It passes all of the tests, but it's still wrong.. for example, parens
will not be "numbery" and so can help numbers evade format detection.
On the upside, it's now much simpler to read and understand. Plus,
rejects queries which have been marked bad in the issues this is intended
to address.
Also includes some minor comment and layout fixups.
Once we have decided on a style which seems to fit all of the input
numbers, we proceed to confirm that all of the numbers (even the
ambiguous ones) make sense in this format.
So far, this means:
- Doesn't have any characters we don't understand.
- All supposed thousands breaks are followed by exactly three numbers
- If there's a decimal mark, there is only one and it never precedes a
thousands break.
This is starting to look like something which should be in a library
somewhere.
Even better, it isn't even actually used yet, since the style-checker
happens on a whole expression instead of a term. Someday.
Fixes#207.
- Add a check to try to determine if they entered more European-looking
numbers.
- Adjust the output, if so, to make the output imply what happened and
probably appear more familiar.
- Otherwise, treat any commas as noise to be ignored.
The euro-style check is pretty weak, by design. It only looks to see if
they used . before , thus implying an order for the separators.
Also adds an abstract to reduce `dzil test` scroll-spam
Fixes#270.
Scientific notation was not supported in all places. This should fix
that. I admit the regex is a bit much for me to hold in my head, so I am
not sure if there are now incidentally misparsed queries.
All tests pass, including new ones to cover the broken cases mentioned
in the issue.
Chris Wilson
Pattarawat Chormai
Matt Miller
Jag Talon
Rob Emery
jagtalon
Eric Johnson
Gabriel Weinberg
Michael Smith
Dylan Lloyd
Eskatrem