On 3/7/07, <b class="gmail_sendername">Robert Dodier</b> &lt;<a href="mailto:robert.dodier@gmail.com">robert.dodier@gmail.com</a>&gt; wrote:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On 3/7/07, Stavros Macrakis &lt;<a href="mailto:macrakis@alum.mit.edu">macrakis@alum.mit.edu</a>&gt; wrote:<br></blockquote><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hmm. I think it might be unnecessarily conservative to treat actual<br>constants as potential variables. I think it would OK to treat only<br>inf and minf as potential variables (e.g. 1^inf = limit(1^x, x, inf) = 1).<br><br>
That makes 0*inf = limit(0*x, x, inf) = 0, which differs from IEEE 754<br>arithmetic rules in which 0*INF =&gt; NAN. That makes me slightly<br>uncomfortable but I could get used to it, if Maxima applies its rules<br>consistently.
</blockquote><div><br>IEEE 754 makes 0*inf=nan (i.e. und) for good reason.&nbsp; After all, if 1/inf = 0 and inf/inf = und, then it had better be true that inf/inf = inf*(1/inf) = und.<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
 Incidentally 1^inf =&gt; und differs from IEEE 754 since 1^inf =&gt; 1 there.</blockquote><div><br>I would be interested to understand why IEEE 754 did this.&nbsp; It looks like a bug to me, since (1-epsilon)^inf = 0 and (1+epsilon)^inf = inf, for arbitrarily small positive epsilon.
<br><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -s<br><br></div></div>