mirror of
https://git.savannah.gnu.org/git/guile.git
synced 2025-06-10 14:00:21 +02:00
9d427b2cc3
When parsing non-real complex numbers, apply exactness specifiers on per-component basis, as is done in PLT Scheme. For complex numbers written in rectangular form, exactness specifiers are applied to the real and imaginary parts before calling scm_make_rectangular. For complex numbers written in polar form, exactness specifiers are applied to the magnitude and angle before calling scm_make_polar. There are two kinds of exactness specifiers: forced and implicit. A forced exactness specifier is a "#e" or "#i" prefix at the beginning of the entire number, and applies to both components of a complex number. "#e" causes each component to be made exact, and "#i" causes each component to be made inexact. If no forced exactness specifier is present, then the exactness of each component is determined independently by the presence or absence of a decimal point or hash mark within that component. If a decimal point or hash mark is present, the component is made inexact, otherwise it is made exact. After the exactness specifiers have been applied to each component, they are passed to either scm_make_rectangular or scm_make_polar to produce the final result. Note that this will result in a real number if the imaginary part, magnitude, or angle is an exact 0. Previously, both forced and implicit exactness specifiers applied to the number as a whole _after_ calling scm_make_rectangular or scm_make_polar. For example, (string->number "#i5.0+0i") now does the equivalent of: (make-rectangular (exact->inexact 5.0) (exact->inexact 0)) which yields 5.0+0.0i. Previously it did the equivalent of: (exact->inexact (make-rectangular 5.0 0)) which yielded 5.0. * libguile/numbers.c (mem2ureal): Receive a forced exactness specifier (forced_x), create and maintain our own implicit exactness specifier flag local to this component (implicit_x), and apply these exactness specifiers within this function. Previously, we received a pointer to an implicit exactness specifier flag from above, and the exactness specifiers were applied from within scm_i_string_length. (mem2complex): Receive a forced exactness specifier parameter and pass it down to mem2ureal. Previously, we passed down a pointer to an implicit exactness specifier flag instead. (scm_i_string_to_number): No longer create an implicit exactness specifier flag here, and do not apply exactness specifiers here. All we do here now regarding exactness is to parse the "#e" or "#i" prefix (if any) and pass this information down to mem2ureal via mem2complex in the form of an explicit exactness specifier (forced_x). (scm_c_make_polar): If the cosine and sine of the angle are both NaNs and the magnitude is zero, return 0.0+0.0i instead of +nan.0+nan.0i. This case happens when the angle is not finite. * test-suite/tests/numbers.test (string->number): Move the test cases for non-real complex numbers into a separate table in which the expected real and imaginary parts are separate entries. Add several new test cases. |
||
|---|---|---|
| .. | ||
| lalr | ||
| standalone | ||
| tests | ||
| vm | ||
| ChangeLog-2008 | ||
| guile-test | ||
| lib.scm | ||
| Makefile.am | ||
| README | ||
This directory contains some tests for Guile, and some generic test support code. To run these tests, you will need a version of Guile more recent than 15 Feb 1999 --- the tests use the (ice-9 and-let*) and (ice-9 getopt-long) modules, which were added to Guile around then. For information about how to run the test suite, read the usage instructions in the comments at the top of the guile-test script. You can reference the file `lib.scm' from your own code as the module (test-suite lib); it also has comments at the top and before each function explaining what's going on. Please write more Guile tests, and send them to bug-guile@gnu.org. We'll merge them into the distribution. All test suites must be licensed for our use under the GPL, but I don't think I'm going to collect assignment papers for them. Some test suite philosophy: GDB has an extensive test suite --- around 6300 tests. Every time the test suite catches a bug, it's great. GDB is so complicated that folks are often unable to get a solid understanding of the code before making a change --- we just don't have time. You'll see people say things like, "Here's a fix for X; it doesn't cause any regressions." The subtext is, I made a change that looks reasonable, and the test suite didn't complain, so it must be okay. I think this is terrible, because it suggests that the writer is using the test suite as a substitute for having a rock-solid explanation of why their changes are correct. The problem is that any test suite is woefully incomplete. Diligent reasoning about code can catch corner conditions or limitations that no test suite will ever find. Jim's rule for test suites: Every test suite failure should be a complete, mysterious surprise, never a possibility you were prepared for. Any other attitude indicates that you're using the test suite as a crutch, which you need only because your understanding is weak.