I think we could have more discussion of proposed patches on this list, if we like.
So here's a proposed patch for your consideration, with a real changelog entry ;-):
lib/_num#.scm: Add (macro-inexact-+pi/4) and (macro-inexact-+3pi/4).
lib/_num.scm: Add ##flsquare, ##square, and square. Add ##exact-int.negative? Use it in ##abs. Add functions from Kahan's paper: ##kahan.abs, ##kahan.arg, ##kahan.cssqs, ##kahan.csqrt, ##kahan.cacos, ##kahan.casin, ##kahan.casinh, ##kahan.catanh, ##kahan.ctanh, ##kahan.ctan; and constants ##kahan.omega, ##kahan.epsilon, ##kahan.lambda. Add functions ##conjugate and conjugate. In ##log, use ##fllog1p for arguments near 1. In ##sin and ##cos, use real trigonometric and hyperbolic functions for complex arguments. In ##tan, use ##tanh for complex arguments. In ##casin, use ##kahan.casin. In ##acos, use ##kahan.acos. In ##atan, use ##atanh. In ##atan2, use Kahan's conventions for infinite arguments. ##sinh, sinh, ##cosh, cosh, ##tanh, tanh, ##asinh, asinh, ##acosh, acosh, ##atanh, atanh: New functions. In ##sqrt: Use ##kahan.csqrt for complex arguments. In ##magnitude: use ##exact-int.negative? for ratnum arguments and ##kahan.abs for complex arguments.
lib:gambit#.scm: Add entries for acosh, asinh, atanh, conjugate, cosh, sinh, square, and atanh.
Marc: I'd like to have the compiler recognize ##flsquare.
I'll attach the patch. I would really appreciate any comments.
Brad
Afficher les réponses par date
On Dec 9, 2013, at 10:28 PM, Bradley Lucier lucier@math.purdue.edu wrote:
I think we could have more discussion of proposed patches on this list, if we like.
So here's a proposed patch for your consideration, with a real changelog entry ;-):
lib/_num#.scm: Add (macro-inexact-+pi/4) and (macro-inexact-+3pi/4).
Fine.
lib/_num.scm: Add ##flsquare, ##square, and square.
Is the naming consistent with other Schemes?
Add ##exact-int.negative?
Fine.
Use it in ##abs. Add functions from Kahan's paper: ##kahan.abs, ##kahan.arg, ##kahan.cssqs, ##kahan.csqrt, ##kahan.cacos, ##kahan.casin, ##kahan.casinh, ##kahan.catanh, ##kahan.ctanh, ##kahan.ctan; and constants ##kahan.omega, ##kahan.epsilon, ##kahan.lambda.
I dislike the naming. Is "kahan" the best prefix? In any case, for consistency with the rest, it should be "kahan-" not "kahan." because the prefix "T." is used to name functions related to type T. Kahan is not a type (or is it?).
Add functions ##conjugate and conjugate.
Is the naming consistent with other Schemes?
In ##log, use ##fllog1p for arguments near 1. In ##sin and ##cos, use real trigonometric and hyperbolic functions for complex arguments. In ##tan, use ##tanh for complex arguments. In ##casin, use ##kahan.casin. In ##acos, use ##kahan.acos. In ##atan, use ##atanh. In ##atan2, use Kahan's conventions for infinite arguments. ##sinh, sinh, ##cosh, cosh, ##tanh, tanh, ##asinh, asinh, ##acosh, acosh, ##atanh, atanh: New functions. In ##sqrt: Use ##kahan.csqrt for complex arguments. In ##magnitude: use ##exact-int.negative? for ratnum arguments and ##kahan.abs for complex arguments.
Fine.
lib:gambit#.scm: Add entries for acosh, asinh, atanh, conjugate, cosh, sinh, square, and atanh.
Fine.
Marc: I'd like to have the compiler recognize ##flsquare.
Easy.
I'll attach the patch. I would really appreciate any comments.
What is missing for this patch is a bunch of unit tests. Each of the new inlined primitives should be tested for precision (after all, that is why they were added, so unit tests should verify this).
For example:
;;; flsinh.scm
(include "~~unit-testing/inlined-primitive.scm")
(check-equal? (##flsinh +0.0) +0.0) (check-equal? (##flsinh -0.0) -0.0) (check-equal? (##flsinh +inf.0) +inf.0) (check-equal? (##flsinh -inf.0) -inf.0) (check-= (##flsinh 1.0) 1.1752011936438014 2e-16)
We need thousands of unit tests like this for Gambit.
Marc
Thanks for the comments.
On 12/10/2013 09:38 AM, Marc Feeley wrote:
On Dec 9, 2013, at 10:28 PM, Bradley Lucier lucier@math.purdue.edu wrote:
lib/_num.scm: Add ##flsquare, ##square, and square.
Is the naming consistent with other Schemes?
Yes.
Add ##exact-int.negative?
Fine.
Use it in ##abs. Add functions from Kahan's paper: ##kahan.abs, ##kahan.arg, ##kahan.cssqs, ##kahan.csqrt, ##kahan.cacos, ##kahan.casin, ##kahan.casinh, ##kahan.catanh, ##kahan.ctanh, ##kahan.ctan; and constants ##kahan.omega, ##kahan.epsilon, ##kahan.lambda.
I dislike the naming. Is "kahan" the best prefix? In any case, for consistency with the rest, it should be "kahan-" not "kahan." because the prefix "T." is used to name functions related to type T. Kahan is not a type (or is it?).
I renamed all the ##kahan. functions to just begin with "##c" (as in "c"omplex).
Add functions ##conjugate and conjugate.
Is the naming consistent with other Schemes?
Yes.
Marc: I'd like to have the compiler recognize ##flsquare.
Easy.
I'll attach the patch. I would really appreciate any comments.
What is missing for this patch is a bunch of unit tests. Each of the new inlined primitives should be tested for precision (after all, that is why they were added, so unit tests should verify this).
Later. I promise. :-)
New changelog and patch:
lib/_num#.scm: Add (macro-inexact-+pi/4), (macro-inexact-+3pi/4), (macro-inexact-epsilon), (macro-inexact-lambda), (macro-inexact-omega).
lib/_num.scm: Add ##flsquare, ##square, and square. Add ##exact-int.negative? Use it in ##abs. Add functions from Kahan's paper: ##cabs, ##carg, ##cssqs, ##csqrt, ##cacos, ##casin, ##casinh, ##catanh, ##ctanh, ##ctan. Add functions ##conjugate and conjugate. In ##log, use ##fllog1p for arguments near 1. In ##sin and ##cos, use real trigonometric and hyperbolic functions for complex arguments. In ##tan, use ##tanh for complex arguments. In ##asin, use ##casin. In ##acos, use ##cacos. In ##atan, use ##atanh. In ##atan2, use Kahan's conventions for infinite arguments. ##sinh, sinh, ##cosh, cosh, ##tanh, tanh, ##asinh, asinh, ##acosh, acosh, ##atanh, atanh: New functions. In ##sqrt: Use ##csqrt for complex arguments. In ##magnitude: use ##exact-int.negative? for ratnum arguments and ##cabs for complex arguments.
lib:gambit#.scm: Add entries for acosh, asinh, atanh, conjugate, cosh, sinh, square, and atanh.
On Dec 10, 2013, at 11:45 AM, Bradley Lucier lucier@math.purdue.edu wrote:
Thanks for the comments.
On 12/10/2013 09:38 AM, Marc Feeley wrote:
On Dec 9, 2013, at 10:28 PM, Bradley Lucier lucier@math.purdue.edu wrote:
lib/_num.scm: Add ##flsquare, ##square, and square.
Is the naming consistent with other Schemes?
Yes.
Add ##exact-int.negative?
Fine.
Use it in ##abs. Add functions from Kahan's paper: ##kahan.abs, ##kahan.arg, ##kahan.cssqs, ##kahan.csqrt, ##kahan.cacos, ##kahan.casin, ##kahan.casinh, ##kahan.catanh, ##kahan.ctanh, ##kahan.ctan; and constants ##kahan.omega, ##kahan.epsilon, ##kahan.lambda.
I dislike the naming. Is "kahan" the best prefix? In any case, for consistency with the rest, it should be "kahan-" not "kahan." because the prefix "T." is used to name functions related to type T. Kahan is not a type (or is it?).
I renamed all the ##kahan. functions to just begin with "##c" (as in "c"omplex).
Add functions ##conjugate and conjugate.
Is the naming consistent with other Schemes?
Yes.
Great.
Marc: I'd like to have the compiler recognize ##flsquare.
Easy.
I'll attach the patch. I would really appreciate any comments.
What is missing for this patch is a bunch of unit tests. Each of the new inlined primitives should be tested for precision (after all, that is why they were added, so unit tests should verify this).
Later. I promise. :-)
Not good enough! If I don't take a hard line on this one, things will slip. But I can help you!
From now on, patches for new functionality will have to come with appropriate unit tests. Unit tests for existing features will have to be added too.
Marc
On 12/10/2013 12:10 PM, Marc Feeley wrote:
On Dec 10, 2013, at 11:45 AM, Bradley Lucier lucier@math.purdue.edu wrote:
Thanks for the comments.
On 12/10/2013 09:38 AM, Marc Feeley wrote: What is missing for this patch is a bunch of unit tests. Each of the new inlined primitives should be tested for precision (after all, that is why they were added, so unit tests should verify this). Later. I promise. :-)
Not good enough! If I don't take a hard line on this one, things will slip. But I can help you!
From now on, patches for new functionality will have to come with appropriate unit tests. Unit tests for existing features will have to be added too.
Oh great and powerful Oz, I bring you the broom of the Wicked Witch of the East ... No, no, that can't be right, let's see ...
I offer you 63 unit tests (including all branch cuts and special values) in supplication that you might accept my good patch.
Brad
On Dec 10, 2013, at 4:10 PM, Bradley Lucier lucier@math.purdue.edu wrote:
Oh great and powerful Oz, I bring you the broom of the Wicked Witch of the East ... No, no, that can't be right, let's see ...
I offer you 63 unit tests (including all branch cuts and special values) in supplication that you might accept my good patch.
Brad
Since your previous message I've been writing a unit testing framework, and it is almost ready.
"Do not arouse the wrath of the great and powerful Oz... come back tomorrow."
Marc
OK, I have now added (and pushed to the repo) a unit testing framework in the tests subdirectory. It is mostly compatible with the unit testing framework of Racket. You can execute it with:
cd tests ./run-unit-tests.scm
The unit tests are in the unit-tests directory. I took your trigtests.scm file and chopped it up into smaller unit tests in the unit-tests/03-number directory. What I notice is that the functions are not tested to the same level of detail:
% wc tests/unit-tests/03-number/* 26 96 606 tests/unit-tests/03-number/#.scm 14 44 338 tests/unit-tests/03-number/acos.scm 11 29 212 tests/unit-tests/03-number/acosh.scm 18 54 415 tests/unit-tests/03-number/asin.scm 18 54 432 tests/unit-tests/03-number/asinh.scm 18 54 418 tests/unit-tests/03-number/atan.scm 18 54 429 tests/unit-tests/03-number/atanh.scm 5 10 67 tests/unit-tests/03-number/cos.scm 5 10 68 tests/unit-tests/03-number/cosh.scm 11 26 219 tests/unit-tests/03-number/log.scm 9 20 143 tests/unit-tests/03-number/sin.scm 9 20 145 tests/unit-tests/03-number/sinh.scm 13 35 232 tests/unit-tests/03-number/sqrt.scm 9 20 143 tests/unit-tests/03-number/tan.scm 9 20 145 tests/unit-tests/03-number/tanh.scm 193 546 4012 total
For example cos and cosh have a single test for the special value 0, whereas there are 8 tests for asin. That is not very thorough testing.
Moreover, it is important to check that the primitive functions raise exceptions correctly. To give you an idea I have added unit tests for fx+ and fl+. Here's the unit test for fx+:
(check-eqv? (fx+ 11 33) 44) (check-eqv? (fx+ 11 -11) 0) (check-eqv? (fx+ 11 -33) -22) (check-eqv? (fx+ -11 33) 22)
(check-eqv? (fx+) 0) (check-eqv? (fx+ 11) 11) (check-eqv? (fx+ 11 22) 33) (check-eqv? (fx+ 11 22 33) 66) (check-eqv? (fx+ 11 22 33 44) 110)
(check-exn type-exception? (lambda () (fx+ 1/2))) (check-exn type-exception? (lambda () (fx+ 1/2 9))) (check-exn type-exception? (lambda () (fx+ 9 1/2))) (check-exn type-exception? (lambda () (fx+ 1/2 3 9))) (check-exn type-exception? (lambda () (fx+ 3 1/2 9))) (check-exn type-exception? (lambda () (fx+ 3 9 1/2)))
(check-exn fixnum-overflow-exception? (lambda () (fx+ ##max-fixnum 1))) (check-exn fixnum-overflow-exception? (lambda () (fx+ ##min-fixnum -1)))
Do you think you could expand your unit tests to cover more cases?
Marc
On Dec 10, 2013, at 4:10 PM, Bradley Lucier lucier@math.purdue.edu wrote:
On 12/10/2013 12:10 PM, Marc Feeley wrote:
On Dec 10, 2013, at 11:45 AM, Bradley Lucier lucier@math.purdue.edu wrote:
Thanks for the comments.
On 12/10/2013 09:38 AM, Marc Feeley wrote: What is missing for this patch is a bunch of unit tests. Each of the new inlined primitives should be tested for precision (after all, that is why they were added, so unit tests should verify this). Later. I promise. :-)
Not good enough! If I don't take a hard line on this one, things will slip. But I can help you!
From now on, patches for new functionality will have to come with appropriate unit tests. Unit tests for existing features will have to be added too.
Oh great and powerful Oz, I bring you the broom of the Wicked Witch of the East ... No, no, that can't be right, let's see ...
I offer you 63 unit tests (including all branch cuts and special values) in supplication that you might accept my good patch.
Brad <trigtests.scm>
On 12/10/2013 10:27 PM, Marc Feeley wrote:
For example cos and cosh have a single test for the special value 0, whereas there are 8 tests for asin.
Counting number of tests is not a very perspicacious analysis technique.
asin acos cos/cosh
number of branch cuts 2 2 0 tests per branch cut 3 3
Number of special values 1 1 1
Does naive implementation suffer yes no no from catastrophic cancellation?
Total number of tests 8 7 1
That is not very thorough testing.
That comment doesn't deserve comment.
Brad
On Dec 11, 2013, at 10:02 AM, Bradley Lucier lucier@math.purdue.edu wrote:
On 12/10/2013 10:27 PM, Marc Feeley wrote:
For example cos and cosh have a single test for the special value 0, whereas there are 8 tests for asin.
Counting number of tests is not a very perspicacious analysis technique.
asin acos cos/cosh
number of branch cuts 2 2 0 tests per branch cut 3 3
Number of special values 1 1 1
Does naive implementation suffer yes no no from catastrophic cancellation?
Total number of tests 8 7 1
That is not very thorough testing.
That comment doesn't deserve comment.
I'm sorry if my comment came across badly. I didn't mean any disrespect.
You previously said that unit testing was new to you, so I'm trying to explain what would be better unit testing. When the only checks are (cos 0) = 1 and (cosh 0) = 1, not much is being verifying about their behavior. In fact, the implementor of those functions may have mistakenly switched their semantics (i.e. cos is really bound to the cosh function, and cosh is really bound to the cos function) and the unit tests would still have passed. Some properties of those functions should be checked also, such as -1 <= (cos x) <= 1 and (cosh x) >= 1 and (cos x) = (cos -x), and exactness propagation (cos[h] 0.0) = 1.0, and also specific normal (non special-case) values. Finally, the behavior of those functions also includes the exceptions they raise, so some tests are needed to make sure they work for all numbers including complex, but raise exceptions for other data types.
Marc
On 12/11/2013 11:39 AM, Marc Feeley wrote:
You previously said that unit testing was new to you, so I'm trying to explain what would be better unit testing. When the only checks are (cos 0) = 1 and (cosh 0) = 1, not much is being verifying about their behavior.
Marc: The only reason it seems to you that the testing is light is because you factored the test differently than I did in my mind. I tested all the branch cuts (which at one point you said were the "hardest part"); I tested all the special values; I tested all the implementations that are prone to catastrophic cancellation.
So if instead of dividing tests into function-specific files you had made three files branch-cuts.scm, special-values.scm, catastrophic-cancellation.scm, and put the various tests in the associated files, those files would have been complete.
And I think that that's a better way to organize the tests, anyway. It's easier to think of all the functions with branch cuts and set up tests for them at one time than to think about all the properties that cos should satisfy and be reasonably sure that you've tested them in a cos.scm file.
Brad
On 12/10/2013 10:27 PM, Marc Feeley wrote:
OK, I have now added (and pushed to the repo) a unit testing framework in the tests subdirectory. It is mostly compatible with the unit testing framework of Racket. You can execute it with:
cd tests ./run-unit-tests.scm
The unit tests are in the unit-tests directory.
Here's what the results look like now:
firefly:~/programs/gambit/marc/gambit/tests> gsi run-unit-tests.scm [ 3| 0| 0] 9% ###....................................... .0s *** ERROR IN "unit-tests/03-number/cosh.scm"@5.14 -- Unbound variable: cosh [ 3| 1| 0] 12% #####..................................... .0s *** ERROR IN "unit-tests/03-number/acosh.scm"@5.14 -- Unbound variable: acosh [ 3| 2| 0] 15% ######.................................... .0s "unit-tests/03-number/acos.scm"@5.1: FAILED (check-eqv? (acos 1) 0) GOT 0. [ 4| 3| 0] 21% #########................................. .0s *** ERROR IN "unit-tests/03-number/atanh.scm"@5.14 -- Unbound variable: atanh [ 4| 4| 0] 25% ##########................................ .0s "unit-tests/03-number/asin.scm"@18.1: FAILED (check-eqv? (asin 1e-30+1e-40i) 1e-30+1e-40i) GOT 1e-30+5.0000000000000005e-61i [ 4| 5| 0] 28% ###########............................... .1s "unit-tests/03-number/atan.scm"@18.1: FAILED (check-eqv? (atan 1e-30+1e-40i) 1e-30+1e-40i) GOT 1e-30-0.i [ 4| 6| 0] 31% #############............................. .1s *** ERROR IN "unit-tests/03-number/sinh.scm"@5.14 -- Unbound variable: sinh [ 6| 7| 0] 40% #################......................... .1s "unit-tests/03-number/tan.scm"@9.1: FAILED (check-eqv? (tan 1e-30+1e-40i) 1e-30+1e-40i) GOT 1e-30-0.i [ 6| 8| 0] 43% ##################........................ .1s *** ERROR IN "unit-tests/03-number/tanh.scm"@5.14 -- Unbound variable: tanh [ 7| 9| 0] 50% #####################..................... .1s "unit-tests/03-number/sin.scm"@9.1: FAILED (check-eqv? (sin 1e-30+1e-40i) 1e-30+1e-40i) GOT 1e-30-0.i [ 7| 10| 0] 53% ######################.................... .1s *** ERROR IN "unit-tests/03-number/asinh.scm"@5.14 -- Unbound variable: asinh [ 21| 11| 0] 100% ########################################## .2s FAILED 11 OUT OF 32 (34.4%)
Install my patch and these tests will pass, and I'll send you more to package as you like.
Brad
PS: After installing from git, run-unit-tests.scm is not executable.
On Dec 14, 2013, at 1:42 PM, Bradley Lucier lucier@math.purdue.edu wrote:
On 12/10/2013 10:27 PM, Marc Feeley wrote:
OK, I have now added (and pushed to the repo) a unit testing framework in the tests subdirectory. It is mostly compatible with the unit testing framework of Racket. You can execute it with:
cd tests ./run-unit-tests.scm
The unit tests are in the unit-tests directory.
Here's what the results look like now:
firefly:~/programs/gambit/marc/gambit/tests> gsi run-unit-tests.scm [ 3| 0| 0] 9% ###....................................... .0s *** ERROR IN "unit-tests/03-number/cosh.scm"@5.14 -- Unbound variable: cosh [ 3| 1| 0] 12% #####..................................... .0s *** ERROR IN "unit-tests/03-number/acosh.scm"@5.14 -- Unbound variable: acosh [ 3| 2| 0] 15% ######.................................... .0s "unit-tests/03-number/acos.scm"@5.1: FAILED (check-eqv? (acos 1) 0) GOT 0. [ 4| 3| 0] 21% #########................................. .0s *** ERROR IN "unit-tests/03-number/atanh.scm"@5.14 -- Unbound variable: atanh [ 4| 4| 0] 25% ##########................................ .0s "unit-tests/03-number/asin.scm"@18.1: FAILED (check-eqv? (asin 1e-30+1e-40i) 1e-30+1e-40i) GOT 1e-30+5.0000000000000005e-61i [ 4| 5| 0] 28% ###########............................... .1s "unit-tests/03-number/atan.scm"@18.1: FAILED (check-eqv? (atan 1e-30+1e-40i) 1e-30+1e-40i) GOT 1e-30-0.i [ 4| 6| 0] 31% #############............................. .1s *** ERROR IN "unit-tests/03-number/sinh.scm"@5.14 -- Unbound variable: sinh [ 6| 7| 0] 40% #################......................... .1s "unit-tests/03-number/tan.scm"@9.1: FAILED (check-eqv? (tan 1e-30+1e-40i) 1e-30+1e-40i) GOT 1e-30-0.i [ 6| 8| 0] 43% ##################........................ .1s *** ERROR IN "unit-tests/03-number/tanh.scm"@5.14 -- Unbound variable: tanh [ 7| 9| 0] 50% #####################..................... .1s "unit-tests/03-number/sin.scm"@9.1: FAILED (check-eqv? (sin 1e-30+1e-40i) 1e-30+1e-40i) GOT 1e-30-0.i [ 7| 10| 0] 53% ######################.................... .1s *** ERROR IN "unit-tests/03-number/asinh.scm"@5.14 -- Unbound variable: asinh [ 21| 11| 0] 100% ########################################## .2s FAILED 11 OUT OF 32 (34.4%)
Install my patch and these tests will pass, and I'll send you more to package as you like.
Brad
Your patch is now applied and on the repo. I have also added inlining of ##flsquare.
PS: After installing from git, run-unit-tests.scm is not executable.
I'm not sure how to solve this.
Marc
Marc:
I've added tests of the exceptions that should be raised for several of the trigonometric and hyperbolic functions, exp, log, and sqrt, and a few more.
I see now that if I want to add files to the git repository, then "git diff" will not be enough to show which files are added. I guess if I want to do more, I'll need to learn a bit of git.
Here is a file containing the unit-tests directory after my changes.
Brad
On Dec 16, 2013, at 12:50 PM, Bradley Lucier lucier@math.purdue.edu wrote:
Marc:
I've added tests of the exceptions that should be raised for several of the trigonometric and hyperbolic functions, exp, log, and sqrt, and a few more.
Great. I'll take a look soon.
I see now that if I want to add files to the git repository, then "git diff" will not be enough to show which files are added. I guess if I want to do more, I'll need to learn a bit of git.
After you create a unit test, you need to "git add" it. I.e.
git add tests/unit-tests/03-number/mynewtest.scm
You can check if you have forgotten to "git add" files by doing a
git status
You'll see which files were modified, which were added, and which are untracked (that you might consider "git add"ing).
Then, you should do a
git add -p
to review your changes to the modified files (you can individually accept/reject each patch hunk with y/n, or all in a file with a).
Then you should do a
make commit
To commit your changes and give a description.
Then you can do a
make push
to push your commit to the Gambit repo.
That's all there is to it!
Here is a file containing the unit-tests directory after my changes.
Brad <unit-tests.tgz>
Marc
On Sun, Dec 15, 2013 at 11:56:40AM -0500, Marc Feeley wrote:
PS: After installing from git, run-unit-tests.scm is not executable.
I'm not sure how to solve this.
It's pretty easy; here's a pull request that fixes:
https://github.com/feeley/gambit/pull/54
-Joe
On 12/10/2013 10:27 PM, Marc Feeley wrote:
Moreover, it is important to check that the primitive functions raise exceptions correctly. To give you an idea I have added unit tests for fx+ and fl+. Here's the unit test for fx+:
(check-exn type-exception? (lambda () (fx+ 1/2))) (check-exn type-exception? (lambda () (fx+ 1/2 9))) (check-exn type-exception? (lambda () (fx+ 9 1/2))) (check-exn type-exception? (lambda () (fx+ 1/2 3 9))) (check-exn type-exception? (lambda () (fx+ 3 1/2 9))) (check-exn type-exception? (lambda () (fx+ 3 9 1/2)))
(check-exn fixnum-overflow-exception? (lambda () (fx+ ##max-fixnum 1))) (check-exn fixnum-overflow-exception? (lambda () (fx+ ##min-fixnum -1)))
How would one deal with this situation:
firefly:~/programs/gambit/marc/gambit> gsi Gambit v4.7.1
> (atan +i) *** ERROR IN (console)@1.1 -- (Argument 1) Out of range (atan +i) 1> > (atan -i) *** ERROR IN ##atan -- (Argument 1) Out of range (log 0) 1>
where an "Out of range" exception is raised, but for the wrong function.
Brad
On Dec 14, 2013, at 7:29 PM, Bradley Lucier lucier@math.purdue.edu wrote:
On 12/10/2013 10:27 PM, Marc Feeley wrote:
Moreover, it is important to check that the primitive functions raise exceptions correctly. To give you an idea I have added unit tests for fx+ and fl+. Here's the unit test for fx+:
(check-exn type-exception? (lambda () (fx+ 1/2))) (check-exn type-exception? (lambda () (fx+ 1/2 9))) (check-exn type-exception? (lambda () (fx+ 9 1/2))) (check-exn type-exception? (lambda () (fx+ 1/2 3 9))) (check-exn type-exception? (lambda () (fx+ 3 1/2 9))) (check-exn type-exception? (lambda () (fx+ 3 9 1/2)))
(check-exn fixnum-overflow-exception? (lambda () (fx+ ##max-fixnum 1))) (check-exn fixnum-overflow-exception? (lambda () (fx+ ##min-fixnum -1)))
How would one deal with this situation:
firefly:~/programs/gambit/marc/gambit> gsi Gambit v4.7.1
(atan +i)
*** ERROR IN (console)@1.1 -- (Argument 1) Out of range (atan +i) 1>
(atan -i)
*** ERROR IN ##atan -- (Argument 1) Out of range (log 0) 1>
where an "Out of range" exception is raised, but for the wrong function.
Brad
I have added a check-tail-exn to verify that the exception is raised in tail position. This should be the case of all primitives, so check-tail-exn should be used almost exclusively in all the unit tests. For example:
(check-tail-exn range-exception? (lambda () (atan -i)))
Marc