<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>I've updated the copy on gitHub with these notes.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div><div><div><div>- Which module should this go into? (I think math, but I don't think you state it.)</div></div></div></div></div></div></div></div></div></blockquote><div><br></div><div>added to text. </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div><div><div><div></div>- Sometimes the default relative tolerance is described as 1e-8, sometimes as 1e-9.<br></div></div></div></div></div></div></div></div></blockquote><div><br></div><div>that's what I get for changing it -- fixed. </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div><div><div></div>- The formula with "abs(a-b) <= max( ... min(..." is missing an all-important close parenthesis. I presume it goes before the last comma. :-)<br></div></div></div></div></div></div></div></blockquote><div><br></div><div>fixed.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div><div></div>- What if a tolerance is inf or nan? What if all args are inf or nan?<br></div></div></div></div></div></div></blockquote><div><br></div><div>0.0 < rel_tol < 1.0)<br></div><div><br></div><div>I've enforced this in the sample code -- it's not strictly necessary, but what does a negative relative tolerance mean, anyway, and a tolerance over 1.0 has some odd behaviour with zero and could hardly be called "close" anyway. Text added to make this clear.</div><div><br></div><div>if a and/or b are inf or nan, it follows IEE754 (which mostly "just works" with no special casing in the code.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div></div><div>- I'd argue for allowing the tolerances to be floats even if a and b are Decimals. There's not much difference in the outcome. Also, what if exactly one of a and b is Decimal?<br></div></div></div></div></div></div></blockquote><div><br></div><div>This resulted from tests failing with trying to convert a float to a Decimal in the code. Though I can't find that problem right now. But maybe type dispatch is a better way to handle that. </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><div><div><div>- Your language about complex confuses me. What is z?</div></div></div></div></div></blockquote><div><br></div><div>"standard" notation for an arbitrary complex value -- I've clarified the language.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><div><div><div> I'd expect the following behavior:<br></div>  - tolerances cannot be complex<br></div>  - abs(a-b) is the right thing to use<br></div>  Or maybe you meant to say that abs() of the tolerances will be used if they are complex? That makes some sense in case someone just mindlessly passes a real cast to complex (i.e. with a zero imaginary part, or near-zero in case it's the outcome of a very fuzzy computation). But still. Maybe you can just give the formula to be used for complex args, if it is in fact any different from the one for reals?<br></div></div></blockquote><div><br></div><div>it's the same, with the exception of using isinf from cmath. At this point, my example code multiplies the tolerance times the tested values, then takes the absolute values -- so a complex tolerance will do complex multiplication, then use the magnitude from that -- I'll have to think about whether that is reasonable.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">- For unittests are you proposing to replace assertAlmostEquals or deprecate that and add a new assertIsCloseTo? (I hope the latter.<br></div></blockquote><div><br></div><div>Add an assertIsCloseTo -- whether assertAlmostEquals should be deprecated I have no opinion on. Though it is useful, as it acts over a sequence -- I"m guessing fols will want to keep it. Then we'll need them to reference each other in the docs.</div><div><br></div><div> On Thu, Feb 5, 2015 at 10:46 AM, Nikolaus Rath <span dir="ltr"><<a href="mailto:Nikolaus@rath.org" target="_blank">Nikolaus@rath.org</a>></span> wrote:</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="im" style="font-size:12.8000001907349px">> 2) ``(abs(a-b) <= tol*abs(a)) or (abs(a-b) <= tol*abs(a))``<br><br></span><span style="font-size:12.8000001907349px">I think the last 'a' should be a 'b'?</span></blockquote><div><br></div><div>indeed -- fixed.</div><div><br></div><div>Thanks,</div><div><br></div><div>-Chris</div><div> </div></div>-- <br><div class="gmail_signature"><br>Christopher Barker, Ph.D.<br>Oceanographer<br><br>Emergency Response Division<br>NOAA/NOS/OR&R            (206) 526-6959   voice<br>7600 Sand Point Way NE   (206) 526-6329   fax<br>Seattle, WA  98115       (206) 526-6317   main reception<br><br><a href="mailto:Chris.Barker@noaa.gov" target="_blank">Chris.Barker@noaa.gov</a></div>
</div></div>