This is a follow-up to "A2: More Announcements" on the main (all-campus) announcement page,
and answers a number of questions my students have asked but for which there has not yet been a public authoritative answer.
St. George students can consider the following to be authoritative:
We will consider either 0.0001 or x1+0.0001 correct as the start of the Logarithm domain.
If that is giving a vertical line in the graphing code that's okay: you don't have to `fix' that (it looks like the sample output either used a slightly larger value (0.001 maybe?) or maybe slightly different code that drew the y axis on top of the line).
You can leave the end of the Logarithm domain as Prof. Jansen specified (even though strictly speaking that could violate the spirit of the setDomain precondition if you're using x1+0.0001 for the start endpoint).
You may add reasonable preconditions to value(), integral() and derivative(), or document and test for NaN and infinities: we will consider either approach correct (see the bulletin board topic "Domain of value(), integral() and derivative()" if you're not sure what this means).
The assignment sometimes mentions the function "type", and sometimes the "name", making it unclear whether it's per-class or per-instance. If you treat the name instance variable and parameter in the simplest way, and don't override getName(), you get a consistent interpretation that it's a name that the user sets per function and you should use it everywhere the function name/type is needed. If you did something consistent but more elaborate let me know and I can tell you whether you need to change your approach.
The toString() specification must be followed exactly as in the handout (except for the -2.0 typo in the Arc toString() example of the handout),
and you should simply use that for the function name/description in the legend.
In the legend, you may include the function value line or you may omit it: we will consider both correct.
In the legend, you may indent the lines under the function name/description or not: we will consider both correct.
Also, we will not test for specific spacing in those lines (e.g. it appears that there is a space after x1=, but not after x2= — don't worry about that).
For testing doubles using assertEquals (especially against the sample, hand calculations, a calculator, etc) use a delta of 1 in the second-last decimal place of the less precise answer (e.g. if you're using a 6-digit calculator that gives you an expected value of 1.23457 and Java gives you something like 1.23456789..., you could use a delta of 0.0001). There are theoretical reasons this might not be achievable (e.g. "conditioning" and "stability" which you'll see soon in A65/165), especially near the endpoints for log and arc, and near where the expected value is large or zero, so if you're getting reasonable results in non-extreme cases but some extreme cases require a bigger delta that's okay.
