duckduckgo
/
zeroclickinfo-goodies
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
zeroclickinfo-goodies/t/Calculator.t

388 lines
11 KiB
Perl
Raw Normal View History

Added tests to the Calculator plugin.
2013-03-11 12:48:29 -07:00
#!/usr/bin/env perl
use strict;
use warnings;
use Test::More;
use DDG::Test::Goodie;
Add code and tests for number disambiguation. This is still not properly factored, but progressing.
2014-03-24 06:29:52 -07:00
use DDG::Goodie::Calculator; # For function subtests.
Added tests to the Calculator plugin.
2013-03-11 12:48:29 -07:00
zci answer_type => 'calc';
Apply tidy.
2014-03-24 06:28:54 -07:00
zci is_cached => 1;
Added tests to the Calculator plugin.
2013-03-11 12:48:29 -07:00
ddg_goodie_test(
Apply tidy.
2014-03-24 06:28:54 -07:00
[qw( DDG::Goodie::Calculator )],
'what is 2-2' => test_zci(
"2 - 2 = 0",
heading => 'Calculator',
Calculator: style up the answer a bit. 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.
2014-06-10 04:58:32 -07:00
html => qr/./,
Apply tidy.
2014-03-24 06:28:54 -07:00
),
'solve 2+2' => test_zci(
"2 + 2 = 4",
heading => 'Calculator',
Calculator: style up the answer a bit. 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.
2014-06-10 04:58:32 -07:00
html => qr/./,
Apply tidy.
2014-03-24 06:28:54 -07:00
),
'2^8' => test_zci(
"2 ^ 8 = 256",
heading => 'Calculator',
Calculator: style up the answer a bit. 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.
2014-06-10 04:58:32 -07:00
html => qr/./,
Apply tidy.
2014-03-24 06:28:54 -07:00
),
'2 *7' => test_zci(
"2 * 7 = 14",
heading => 'Calculator',
Calculator: style up the answer a bit. 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.
2014-06-10 04:58:32 -07:00
html => qr/./,
Apply tidy.
2014-03-24 06:28:54 -07:00
),
'1 dozen * 2' => test_zci(
"1 dozen * 2 = 24",
heading => 'Calculator',
Calculator: style up the answer a bit. 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.
2014-06-10 04:58:32 -07:00
html => qr/./,
Apply tidy.
2014-03-24 06:28:54 -07:00
),
'dozen + dozen' => test_zci(
"dozen + dozen = 24",
heading => 'Calculator',
Calculator: style up the answer a bit. 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.
2014-06-10 04:58:32 -07:00
html => qr/./,
Apply tidy.
2014-03-24 06:28:54 -07:00
),
'2divided by 4' => test_zci(
"2 divided by 4 = 0.5",
heading => 'Calculator',
Calculator: style up the answer a bit. 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.
2014-06-10 04:58:32 -07:00
html => qr/./,
Apply tidy.
2014-03-24 06:28:54 -07:00
),
'2^dozen' => test_zci(
"2 ^ dozen = 4,096",
heading => 'Calculator',
Calculator: style up the answer a bit. 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.
2014-06-10 04:58:32 -07:00
html => qr/./,
Apply tidy.
2014-03-24 06:28:54 -07:00
),
'2^2' => test_zci(
"2 ^ 2 = 4",
heading => 'Calculator',
Calculator: style up the answer a bit. 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.
2014-06-10 04:58:32 -07:00
html => qr/./,
Apply tidy.
2014-03-24 06:28:54 -07:00
),
'2^0.2' => test_zci(
"2 ^ 0.2 = 1.14869835499704",
heading => 'Calculator',
Calculator: style up the answer a bit. 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.
2014-06-10 04:58:32 -07:00
html => qr/./,
Apply tidy.
2014-03-24 06:28:54 -07:00
),
'cos(0)' => test_zci(
"cos(0) = 1",
heading => 'Calculator',
Calculator: style up the answer a bit. 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.
2014-06-10 04:58:32 -07:00
html => qr/./,
Apply tidy.
2014-03-24 06:28:54 -07:00
),
'tan(1)' => test_zci(
"tan(1) = 1.5574077246549",
heading => 'Calculator',
Calculator: style up the answer a bit. 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.
2014-06-10 04:58:32 -07:00
html => qr/./,
Apply tidy.
2014-03-24 06:28:54 -07:00
),
Calculator: use Math::Trig for trig functions. 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.
2014-04-05 21:04:26 -07:00
'tanh(1)' => test_zci(
"tanh(1) = 0.761594155955765",
heading => 'Calculator',
Calculator: style up the answer a bit. 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.
2014-06-10 04:58:32 -07:00
html => qr/./,
Calculator: use Math::Trig for trig functions. 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.
2014-04-05 21:04:26 -07:00
),
'cotan(1)' => test_zci(
"cotan(1) = 0.642092615934331",
heading => 'Calculator',
Calculator: style up the answer a bit. 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.
2014-06-10 04:58:32 -07:00
html => qr/./,
Calculator: use Math::Trig for trig functions. 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.
2014-04-05 21:04:26 -07:00
),
Apply tidy.
2014-03-24 06:28:54 -07:00
'sin(1)' => test_zci(
"sin(1) = 0.841470984807897",
heading => 'Calculator',
Calculator: style up the answer a bit. 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.
2014-06-10 04:58:32 -07:00
html => qr/./,
Apply tidy.
2014-03-24 06:28:54 -07:00
),
Calculator: use Math::Trig for trig functions. 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.
2014-04-05 21:04:26 -07:00
'csc(1)' => test_zci(
"csc(1) = 1.18839510577812",
heading => 'Calculator',
Calculator: style up the answer a bit. 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.
2014-06-10 04:58:32 -07:00
html => qr/./,
Calculator: use Math::Trig for trig functions. 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.
2014-04-05 21:04:26 -07:00
),
'sec(1)' => test_zci(
"sec(1) = 1.85081571768093",
heading => 'Calculator',
Calculator: style up the answer a bit. 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.
2014-06-10 04:58:32 -07:00
html => qr/./,
Calculator: use Math::Trig for trig functions. 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.
2014-04-05 21:04:26 -07:00
),
Calculator: add support for ln and (mostly) arbitrary base logs We're only actually doing logs up to base 999.. but I think anything else is probably people goofing. I can be convinced otherwise, though.
2014-05-22 09:50:28 -07:00
'log(3)' => test_zci(
"log(3) = 1.09861228866811",
heading => 'Calculator',
Calculator: style up the answer a bit. 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.
2014-06-10 04:58:32 -07:00
html => qr/./,
Calculator: add support for ln and (mostly) arbitrary base logs We're only actually doing logs up to base 999.. but I think anything else is probably people goofing. I can be convinced otherwise, though.
2014-05-22 09:50:28 -07:00
),
'ln(3)' => test_zci(
"ln(3) = 1.09861228866811",
heading => 'Calculator',
Calculator: style up the answer a bit. 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.
2014-06-10 04:58:32 -07:00
html => qr/./,
Calculator: add support for ln and (mostly) arbitrary base logs We're only actually doing logs up to base 999.. but I think anything else is probably people goofing. I can be convinced otherwise, though.
2014-05-22 09:50:28 -07:00
),
Calculator: use Math::Trig for trig functions. 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.
2014-04-05 21:04:26 -07:00
'log10(100.00)' => test_zci(
"log10(100.00) = 2",
heading => 'Calculator',
Calculator: style up the answer a bit. 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.
2014-06-10 04:58:32 -07:00
html => qr/./,
Calculator: use Math::Trig for trig functions. 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.
2014-04-05 21:04:26 -07:00
),
Calculator: add support for ln and (mostly) arbitrary base logs We're only actually doing logs up to base 999.. but I think anything else is probably people goofing. I can be convinced otherwise, though.
2014-05-22 09:50:28 -07:00
'log_10(100.00)' => test_zci(
"log_10(100.00) = 2",
heading => 'Calculator',
Calculator: style up the answer a bit. 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.
2014-06-10 04:58:32 -07:00
html => qr/./,
Calculator: add support for ln and (mostly) arbitrary base logs We're only actually doing logs up to base 999.. but I think anything else is probably people goofing. I can be convinced otherwise, though.
2014-05-22 09:50:28 -07:00
),
'log_2(16)' => test_zci(
"log_2(16) = 4",
heading => 'Calculator',
Calculator: style up the answer a bit. 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.
2014-06-10 04:58:32 -07:00
html => qr/./,
Calculator: add support for ln and (mostly) arbitrary base logs We're only actually doing logs up to base 999.. but I think anything else is probably people goofing. I can be convinced otherwise, though.
2014-05-22 09:50:28 -07:00
),
'log_23(25)' => test_zci(
"log_23(25) = 1.0265928122321",
heading => 'Calculator',
Calculator: style up the answer a bit. 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.
2014-06-10 04:58:32 -07:00
html => qr/./,
Calculator: add support for ln and (mostly) arbitrary base logs We're only actually doing logs up to base 999.. but I think anything else is probably people goofing. I can be convinced otherwise, though.
2014-05-22 09:50:28 -07:00
),
'log23(25)' => test_zci(
"log23(25) = 1.0265928122321",
heading => 'Calculator',
Calculator: style up the answer a bit. 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.
2014-06-10 04:58:32 -07:00
html => qr/./,
Calculator: add support for ln and (mostly) arbitrary base logs We're only actually doing logs up to base 999.. but I think anything else is probably people goofing. I can be convinced otherwise, though.
2014-05-22 09:50:28 -07:00
),
Apply tidy.
2014-03-24 06:28:54 -07:00
'$3.43+$34.45' => test_zci(
'$3.43 + $34.45 = $37.88',
heading => 'Calculator',
Calculator: style up the answer a bit. 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.
2014-06-10 04:58:32 -07:00
html => qr/./,
Apply tidy.
2014-03-24 06:28:54 -07:00
),
Reconsider how precision is done. 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.
2014-03-29 19:27:18 -07:00
'$3.45+$34.45' => test_zci(
'$3.45 + $34.45 = $37.90',
heading => 'Calculator',
Calculator: style up the answer a bit. 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.
2014-06-10 04:58:32 -07:00
html => qr/./,
Reconsider how precision is done. 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.
2014-03-29 19:27:18 -07:00
),
'$3+$34' => test_zci(
'$3 + $34 = $37',
heading => 'Calculator',
Calculator: style up the answer a bit. 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.
2014-06-10 04:58:32 -07:00
html => qr/./,
Reconsider how precision is done. 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.
2014-03-29 19:27:18 -07:00
),
'$3,4+$34,4' => test_zci(
'$3,4 + $34,4 = $37,8',
heading => 'Calculator',
Calculator: style up the answer a bit. 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.
2014-06-10 04:58:32 -07:00
html => qr/./,
Reconsider how precision is done. 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.
2014-03-29 19:27:18 -07:00
),
Apply tidy.
2014-03-24 06:28:54 -07:00
'64*343' => test_zci(
'64 * 343 = 21,952',
heading => 'Calculator',
Calculator: style up the answer a bit. 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.
2014-06-10 04:58:32 -07:00
html => qr/./,
Apply tidy.
2014-03-24 06:28:54 -07:00
),
'1E2 + 1' => test_zci(
'(1 * 10 ^ 2) + 1 = 101',
heading => 'Calculator',
Calculator: style up the answer a bit. 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.
2014-06-10 04:58:32 -07:00
html => qr/./,
Apply tidy.
2014-03-24 06:28:54 -07:00
),
'1 + 1E2' => test_zci(
'1 + (1 * 10 ^ 2) = 101',
heading => 'Calculator',
Calculator: style up the answer a bit. 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.
2014-06-10 04:58:32 -07:00
html => qr/./,
Apply tidy.
2014-03-24 06:28:54 -07:00
),
'2 * 3 + 1E2' => test_zci(
'2 * 3 + (1 * 10 ^ 2) = 106',
heading => 'Calculator',
Calculator: style up the answer a bit. 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.
2014-06-10 04:58:32 -07:00
html => qr/./,
Apply tidy.
2014-03-24 06:28:54 -07:00
),
'1E2 + 2 * 3' => test_zci(
'(1 * 10 ^ 2) + 2 * 3 = 106',
heading => 'Calculator',
Calculator: style up the answer a bit. 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.
2014-06-10 04:58:32 -07:00
html => qr/./,
Apply tidy.
2014-03-24 06:28:54 -07:00
),
'1E2 / 2' => test_zci(
'(1 * 10 ^ 2) / 2 = 50',
heading => 'Calculator',
Calculator: style up the answer a bit. 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.
2014-06-10 04:58:32 -07:00
html => qr/./,
Apply tidy.
2014-03-24 06:28:54 -07:00
),
'2 / 1E2' => test_zci(
'2 / (1 * 10 ^ 2) = 0.02',
heading => 'Calculator',
Calculator: style up the answer a bit. 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.
2014-06-10 04:58:32 -07:00
html => qr/./,
Apply tidy.
2014-03-24 06:28:54 -07:00
),
'424334+2253828' => test_zci(
'424334 + 2253828 = 2,678,162',
heading => 'Calculator',
Calculator: style up the answer a bit. 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.
2014-06-10 04:58:32 -07:00
html => qr/./,
Apply tidy.
2014-03-24 06:28:54 -07:00
),
'4.243,34+22.538,28' => test_zci(
'4.243,34 + 22.538,28 = 26.781,62',
heading => 'Calculator',
Calculator: style up the answer a bit. 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.
2014-06-10 04:58:32 -07:00
html => qr/./,
Apply tidy.
2014-03-24 06:28:54 -07:00
),
Calculator: deal with parenthesized query strings. 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.
2014-03-28 22:51:59 -07:00
'sin(1,0) + 1,05' => test_zci(
'sin(1,0) + 1,05 = 1,8914709848079',
heading => 'Calculator',
Calculator: style up the answer a bit. 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.
2014-06-10 04:58:32 -07:00
html => qr/./,
Calculator: deal with parenthesized query strings. 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.
2014-03-28 22:51:59 -07:00
),
Reconsider how precision is done. 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.
2014-03-29 19:27:18 -07:00
'21 + 15 x 0 + 5' => test_zci(
Iterate toward more formal query parsing. 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.
2014-03-29 17:07:02 -07:00
'21 + 15 x 0 + 5 = 26',
heading => 'Calculator',
Calculator: style up the answer a bit. 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.
2014-06-10 04:58:32 -07:00
html => qr/./,
Iterate toward more formal query parsing. 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.
2014-03-29 17:07:02 -07:00
),
Reconsider how precision is done. 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.
2014-03-29 19:27:18 -07:00
'0.8158 - 0.8157' => test_zci(
'0.8158 - 0.8157 = 0.0001',
heading => 'Calculator',
Calculator: style up the answer a bit. 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.
2014-06-10 04:58:32 -07:00
html => qr/./,
Reconsider how precision is done. 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.
2014-03-29 19:27:18 -07:00
),
'2,90 + 4,6' => test_zci(
'2,90 + 4,6 = 7,50',
heading => 'Calculator',
Calculator: style up the answer a bit. 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.
2014-06-10 04:58:32 -07:00
html => qr/./,
Reconsider how precision is done. 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.
2014-03-29 19:27:18 -07:00
),
Calculator: use Math::Trig for trig functions. 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.
2014-04-05 21:04:26 -07:00
'2,90 + sec(4,6)' => test_zci(
'2,90 + sec(4,6) = -6,01642861135959',
heading => 'Calculator',
Calculator: style up the answer a bit. 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.
2014-06-10 04:58:32 -07:00
html => qr/./,
Calculator: use Math::Trig for trig functions. 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.
2014-04-05 21:04:26 -07:00
),
Calculator: add another FP-related regression test. In response to a known-bad production result.
2014-04-30 10:10:39 -07:00
'100 - 96.54' => test_zci(
'100 - 96.54 = 3.46',
heading => 'Calculator',
Calculator: style up the answer a bit. 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.
2014-06-10 04:58:32 -07:00
html => qr/./,
Calculator: add another FP-related regression test. In response to a known-bad production result.
2014-04-30 10:10:39 -07:00
),
Calculator: add support for ln and (mostly) arbitrary base logs We're only actually doing logs up to base 999.. but I think anything else is probably people goofing. I can be convinced otherwise, though.
2014-05-22 09:50:28 -07:00
'1. + 1.' => test_zci(
'1. + 1. = 2',
heading => 'Calculator',
Calculator: style up the answer a bit. 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.
2014-06-10 04:58:32 -07:00
html => qr/./,
Calculator: add support for ln and (mostly) arbitrary base logs We're only actually doing logs up to base 999.. but I think anything else is probably people goofing. I can be convinced otherwise, though.
2014-05-22 09:50:28 -07:00
),
Calculator: give result for sin(pi) 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)].
2014-06-04 07:52:36 -07:00
'1 + sin(pi)' => test_zci(
'1 + sin(pi) = 1',
heading => 'Calculator',
Calculator: style up the answer a bit. 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.
2014-06-10 04:58:32 -07:00
html => qr/./,
Calculator: give result for sin(pi) 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)].
2014-06-04 07:52:36 -07:00
),
'1 - 1' => test_zci(
'1 - 1 = 0',
heading => 'Calculator',
Calculator: style up the answer a bit. 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.
2014-06-10 04:58:32 -07:00
html => qr/./,
Calculator: give result for sin(pi) 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)].
2014-06-04 07:52:36 -07:00
),
'sin(pi/2)' => test_zci(
'sin(pi / 2) = 1',
heading => 'Calculator',
Calculator: style up the answer a bit. 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.
2014-06-10 04:58:32 -07:00
html => qr/./,
Calculator: give result for sin(pi) 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)].
2014-06-04 07:52:36 -07:00
),
'sin(pi)' => test_zci(
'sin(pi) = 0',
heading => 'Calculator',
Calculator: style up the answer a bit. 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.
2014-06-10 04:58:32 -07:00
html => qr/./,
Calculator: give result for sin(pi) 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)].
2014-06-04 07:52:36 -07:00
),
'cos(2pi)' => test_zci(
'cos(2 pi) = 1',
heading => 'Calculator',
Calculator: style up the answer a bit. 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.
2014-06-10 04:58:32 -07:00
html => qr/./,
Calculator: give result for sin(pi) 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)].
2014-06-04 07:52:36 -07:00
),
Calculator: add 'squared' and 'score'. 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.
2014-06-14 13:37:25 -07:00
'5 squared' => test_zci(
'5 squared = 25',
heading => 'Calculator',
html => qr/./,
),
'1.0 + 5 squared' => test_zci(
'1.0 + 5 squared = 26.0',
heading => 'Calculator',
html => qr/./,
),
'3 squared + 4 squared' => test_zci(
'3 squared + 4 squared = 25',
heading => 'Calculator',
html => qr/./,
),
'2,2 squared' => test_zci(
'2,2 squared = 4,8',
heading => 'Calculator',
html => qr/./,
),
'0.8^2 + 0.6^2' => test_zci(
'0.8 ^ 2 + 0.6 ^ 2 = 1',
heading => 'Calculator',
Calculator: uses the correct classes
2014-07-30 11:43:54 -07:00
html => qr#0.8<sup>2</sup> \+ 0.6<sup>2</sup><span class='text--secondary'> = #,
Calculator: add 'squared' and 'score'. 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.
2014-06-14 13:37:25 -07:00
),
'2 squared ^ 3' => test_zci(
'2 squared ^ 3 = 256',
heading => 'Calculator',
Calculator: uses the correct classes
2014-07-30 11:43:54 -07:00
html => qr#2 squared<sup>3</sup><span class='text--secondary'> = #,
Calculator: add 'squared' and 'score'. 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.
2014-06-14 13:37:25 -07:00
),
Calculator: superscripting for arbitrary terms. 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.
2014-06-20 17:32:50 -07:00
'2 squared ^ 3.06' => test_zci(
'2 squared ^ 3.06 = 323.972172143725',
heading => 'Calculator',
Calculator: uses the correct classes
2014-07-30 11:43:54 -07:00
html => qr#2 squared<sup>3\.06</sup><span class='text--secondary'> = #,
Calculator: superscripting for arbitrary terms. 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.
2014-06-20 17:32:50 -07:00
),
Calculator: add 'squared' and 'score'. 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.
2014-06-14 13:37:25 -07:00
'2^3 squared' => test_zci(
'2 ^ 3 squared = 512',
heading => 'Calculator',
Calculator: uses the correct classes
2014-07-30 11:43:54 -07:00
html => qr#2<sup>3</sup>squared<span class='text--secondary'> = #,
Calculator: add 'squared' and 'score'. 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.
2014-06-14 13:37:25 -07:00
),
'4 score + 7' => test_zci(
'4 score + 7 = 87',
heading => 'Calculator',
html => qr/./,
),
Calculator: improve precision/accuracy trade-off. 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.
2014-06-23 22:18:36 -07:00
'418.1 / 2' => test_zci(
'418.1 / 2 = 209.05',
heading => 'Calculator',
html => qr/./,
),
'418.005 / 8' => test_zci(
'418.005 / 8 = 52.250625',
heading => 'Calculator',
html => qr/./,
),
Calculator: superscripting for arbitrary terms. 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.
2014-06-20 17:32:50 -07:00
'(pi^4+pi^5)^(1/6)' => test_zci(
'(pi ^ 4 + pi ^ 5) ^ (1 / 6) = 2.71828180861191',
heading => 'Calculator',
Calculator: uses the correct classes
2014-07-30 11:43:54 -07:00
html => qr#\(pi<sup>4</sup> \+ pi<sup>5</sup>\)<sup>\(1 / 6\)</sup><span class='text--secondary'> =#,
Calculator: superscripting for arbitrary terms. 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.
2014-06-20 17:32:50 -07:00
),
'(pi^4+pi^5)^(1/6)+1' => test_zci(
'(pi ^ 4 + pi ^ 5) ^ (1 / 6) + 1 = 3.71828180861191',
heading => 'Calculator',
Calculator: uses the correct classes
2014-07-30 11:43:54 -07:00
html => qr#\(pi<sup>4</sup> \+ pi<sup>5</sup>\)<sup>\(1 / 6\)</sup> \+ 1<span class='text--secondary'> =#,
Calculator: superscripting for arbitrary terms. 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.
2014-06-20 17:32:50 -07:00
),
'(pi^4.1^(5-4)+pi^(5-(4^2 -8)))^(1/6)+1' => test_zci(
'(pi ^ 4.1 ^ (5 - 4) + pi ^ (5 - (4 ^ 2 - 8))) ^ (1 / 6) + 1 = 3.18645452799383',
heading => 'Calculator',
Calculator: uses the correct classes
2014-07-30 11:43:54 -07:00
html => qr#\(pi<sup>4.1<sup>\(5 - 4\)</sup></sup> \+ pi<sup>\(5 - \(4<sup>2</sup> - 8\)\)</sup>\)<sup>\(1 / 6\)</sup> \+ 1<span class='text--secondary'> =#,
Calculator: superscripting for arbitrary terms. 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.
2014-06-20 17:32:50 -07:00
),
'5^4^(3-2)^1' => test_zci(
'5 ^ 4 ^ (3 - 2) ^ 1 = 625',
heading => 'Calculator',
Calculator: uses the correct classes
2014-07-30 11:43:54 -07:00
html => qr#5<sup>4<sup>\(3 - 2\)<sup>1</sup></sup></sup><span class='text--secondary'> =#,
Calculator: superscripting for arbitrary terms. 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.
2014-06-20 17:32:50 -07:00
),
'(5-4)^(3-2)^1' => test_zci(
'(5 - 4) ^ (3 - 2) ^ 1 = 1',
heading => 'Calculator',
Calculator: uses the correct classes
2014-07-30 11:43:54 -07:00
html => qr#\(5 - 4\)<sup>\(3 - 2\)<sup>1</sup></sup><span class='text--secondary'> =#,
Calculator: superscripting for arbitrary terms. 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.
2014-06-20 17:32:50 -07:00
),
'(5+4-3)^(2-1)' => test_zci(
'(5 + 4 - 3) ^ (2 - 1) = 6',
heading => 'Calculator',
Calculator: uses the correct classes
2014-07-30 11:43:54 -07:00
html => qr#\(5 \+ 4 - 3\)<sup>\(2 - 1\)</sup><span class='text--secondary'> =#,
Calculator: superscripting for arbitrary terms. 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.
2014-06-20 17:32:50 -07:00
),
'5^((4-3)*(2+1))+6' => test_zci(
'5 ^ ((4 - 3) * (2 + 1)) + 6 = 131',
heading => 'Calculator',
Calculator: uses the correct classes
2014-07-30 11:43:54 -07:00
html => qr#5<sup>\(\(4 - 3\) \* \(2 \+ 1\)\)</sup> \+ 6<span class='text--secondary'> =#,
Calculator: superscripting for arbitrary terms. 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.
2014-06-20 17:32:50 -07:00
),
Calculator: ignore probable attempts at hex notation. 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.
2014-07-09 13:32:04 -07:00
'20x07' => test_zci(
'20 x 07 = 140',
heading => 'Calculator',
html => qr/./,
),
Calculator: ignore probable attempts at CIDR notation. 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.
2014-07-09 14:02:24 -07:00
'83.166.167.160/33' => test_zci(
'83.166.167.160 / 33 = 2.520.186.883,63636',
heading => 'Calculator',
html => qr/./,
),
Calculator: ignore attempts at subnet notation. 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.
2014-07-09 14:33:43 -07:00
'123.123.123.123/255.255.255.256' => test_zci(
'123.123.123.123 / 255.255.255.256 = 0,482352941174581',
heading => 'Calculator',
html => qr/./,
),
NumberStyle: tighten up check for exponentials. Also, some adjustments to Calculator to allow its tests to pass. Still clearly not properly factored, but at least everything "works" for the moment.
2014-07-27 06:58:25 -07:00
'4E5 +1 ' => test_zci(
'(4 * 10 ^ 5) + 1 = 400,001',
heading => 'Calculator',
html => qr/./,
),
'4e5 +1 ' => test_zci(
'(4 * 10 ^ 5) + 1 = 400,001',
heading => 'Calculator',
html => qr/./,
),
Calculator: ignore attempts at subnet notation. 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.
2014-07-09 14:33:43 -07:00
'123.123.123.123/255.255.255.255' => undef,
'83.166.167.160/27' => undef,
'9 + 0 x 07' => undef,
'0x07' => undef,
'sin(1.0) + 1,05' => undef,
'4,24,334+22,53,828' => undef,
'5234534.34.54+1' => undef,
'//' => undef,
dividedbydividedby => undef,
time => undef, # We eval perl directly, only do whitelisted stuff!
'four squared' => undef,
Added tests to the Calculator plugin.
2013-03-11 12:48:29 -07:00
);
done_testing;