<div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace;font-size:large">Dear Bruno,<br><br>Thank you for your quick and detailed reply.<br><br clear="all"></div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><font face="monospace, monospace" size="4">Po-Hsun Tseng (Rocky)</font></div></div></div></div></div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Feb 9, 2020 at 6:37 PM Bruno Haible <<a href="mailto:bruno@clisp.org">bruno@clisp.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
> 1. Does CLN support performing two different precision number with basic<br>
> overloading operators (+,-,*, and /)?<br>
<br>
Yes.<br>
<br>
> 2. If yes, how does CLN treat that? eg. zero padding on the precision-less<br>
> number before doing operation?<br>
<br>
It does zero-padding on the operand with the smaller precision, then the<br>
operation on the then equal-size operands, and finally rounding (round-to-even)<br>
to the smallest precision among the operands.<br>
<br>
Example (using decimal numbers for illustrative purposes):<br>
<br>
    3.14149265358979323<br>
  + 2.718282<br>
  ---------------------<br>
    3.14149265358979323<br>
  + 2.71828200000000000<br>
  ---------------------<br>
    5.85969465358979323<br>
  ---------------------<br>
    5.859695<br>
<br>
Therefore, when some computation returns a result, usually a few decimal<br>
places at the end can be wrong, but CLN will never give you a 50-digit<br>
result when in fact the accurary is only 10 digits - UNLESS you use<br>
conversion functions [1] explicitly.<br>
<br>
Bruno<br>
<br>
[1] <a href="https://www.ginac.de/CLN/cln.html#Conversion-functions" rel="noreferrer" target="_blank">https://www.ginac.de/CLN/cln.html#Conversion-functions</a><br>
<br>
</blockquote></div>