<HTML>
Well, I would argue that when computing log(x) of any base, as x tends to 0 from a positive number, log(x) becomes a progressively more negative number to the point that, yes, it's undefined, but that's only going by the definition of limits.<br>
<br>
<div>The issue here is that my proposed logarithm functions work not on floating-point numbers, but integers, primarily for the sake of speed and application.  There is no way to store a NaN or plus or minus infinity in an integral type, which means the only other option is to raise an exception.</div><div><br>
</div><div>For truly mathematical functions with a continuous domain, then yes, it should return proper values.  I suppose what I'm proposing is not the true base-2 logarithm, but two functions that do the following:<br>
<br>
</div><div>FLog2(x), x element of N (natural numbers), including zero<br>
<br>
0, x = 0<br>
floor(log2(x)); x ≠ 0<br>
</div><br>
CLog2(x), x element of N, including zero<br>
<br>
0, x = 0<br>
ceil(log2(x)); x ≠ 0<br>
<div><br>
</div><div>(Not easy to describe when you can't use proper mathematical notation in an e-mail!)</div><div><br>
</div><div>In this instance, it's less about mathematical correctness and more for the sake of convenience, because only a single input (zero) would be undefined, and for the sake of bit lengths and loop iterations, 0 is a more convenient value than throwing an exception or returning something undefined or potentially hazardous like $FFFFFFFF, which if passed blindly into a for-loop, will cause 4.29 billion iterations..</div><div><br>
</div><div>Gareth<br>
</div><br>
<br>
<span style="font-weight: bold;">On Wed 13/06/18 00:45 , Wolf wv99999@gmail.com sent:<br>
</span><blockquote style="BORDER-LEFT: #F5F5F5 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT:0px; PADDING-LEFT: 5px; PADDING-RIGHT: 0px"> 
  
 <defanged_meta http-equiv="Content-Type" content="text/html; charset=utf-8"> 
  
 <defanged_body text="#000000" bgcolor="#FFFFFF"> 
 <p>Hi</p> 
 <p>I object to one component of Gareth's proposal - to make 
 log2(0)=0. The problem lies not with what Gareth wants to do with 
 it, but what other people will use it for once it becomes 
 available.  log2(0) is undefined (and undefinable, as it is not a 
 computable number), the appropriate choice for log2(0) is to make 
 it Not-A-Number (NaN). <br>
 
 </p> 
 <p align="center">FLog2(0) = NaN = CLog2. <br>
 
 </p> 
 <p>Such a choice would avoid the mess Gustavson got himself into 
 when he <a moz-do-not-send="true" href="www.johngustafson.net/pdfs/BeatingFloatingPoint.pdf">mapped</a> 
 0 and 1/0 onto the same number - a mapping that has many 
 advantages for computing, but eventually <a moz-do-not-send="true" href="https://arxiv.org/pdf/1701.00722">destroys 
 computability</a>. To a lesser degree, this mess is already 
 present in the IEEE 754 standard for floating-point arithmetic, 
 and thus led to, to put it mildly, <a moz-do-not-send="true" href="www.itu.dk/%7Esestoft/bachelor/IEEE754_article.pdf">computing 
 difficulties</a>, difficulties that many programmers gloss over 
 - or simply ignore.<br>
 
 </p> 
 I will have to say more about this when I am ready to file a bug 
 report on floating point exceptions, since Gareth's proposal has 
 deep links to how floating point numbers are defined - and why they 
 were defined such.<br>
 
 <br>
 
 Wolf<br>
 
 <br>
 
 <div class="moz-cite-prefix">On 13/06/2018 00:42, J. Gareth Moreton 
 wrote:<br>
 
 </div> 
 <blockquote type="cite" cite="mid:2794.1528807356@web-cluster.fastnet.co.uk"> 
 <div> 
 Hi 
 everyone,</div> 
 <div><br>
 
 </div> 
 <div>Sorry to flood the mailing list again with more ideas and 
 experiments.<br>
 
 <br>
 
 I would like to propose introducing a new pair of in-built 
 functions for the compiler.<br>
 
 <br>
 
 function FLog2(X: Cardinal): Cardinal;<br>
 
 function CLog2(X: Cardinal): Cardinal;<br>
 
 <br>
 
 FLog2 returns the base-2 logarithm of X, rounded down, while 
 CLog2 returns the base-2 logarithm of X, rounded up.<br>
 
 <br>
 
 To give examples where these functions could be useful, FLog2(X) 
 + 1 indicates the minimum number of bits required to store X as 
 an unsigned integer, while CLog2(X) is equal to the maximum 
 number of iterations required for a binary search of an X-sized 
 list.<br>
 
 </div> 
 </blockquote> 
 Given the stated purpose, I could withdraw my objection if any 
 reference to logarithm was removed from the function and its name. 
 Then Gareth would be free to create his function any way he likes 
 and assign to it the properties he chooses. The only requirement 
 left then would be to state in the comments around the function what 
 it is supposed to achieve, as a deterrence to mis-use and guidance 
 to future maintainers, who may not think the same as Gareth does.<br>
 
 <blockquote type="cite" cite="mid:2794.1528807356@web-cluster.fastnet.co.uk"> 
 <div> 
 Why should they be in-built though? With the binary search 
 example, the size of the list is sometimes known at compile 
 time, hence is a constant - therefore, its logarithm is also a 
 constant.  By pre-calculating the logarithm using the in-built 
 function, it can be used to aid optimization such as loop 
 unrolling.  It also makes them easier to inline, where FLog2(X) 
 on x86_64-win64 translates to a single line of assembly 
 language: BSR EAX, ECX (unless X is zero, in which case ZF is 
 set and EAX is undefined).<br>
 
 <br>
 
 If there had to be a slight nuance though, it's what happens if 
 X = 0, since log(0) = -oo</div> 
 </blockquote> 
 This statement is false. log(0) is not infinity. To obtain a 
 numerical value for log(0) by e.g. Taylor series expansion, at one 
 stage you have to divide by zero since the differential<br>
 
 <div align="center">(d ln x )/ d x = 1/x.<br>
 
 </div> 
  And since 1/0 is not an element of the set of computable numbers, 
 log(0) is not either. The only valid assignment can be log(0):=NaN, 
 for any base.<br>
 
 <blockquote type="cite" cite="mid:2794.1528807356@web-cluster.fastnet.co.uk"> 
 <div>, which cannot be stored as an integer and may cause problems 
 with the compiler.  I would propose it return 0 as a special 
 case, as this will fix most problems when it comes to loops and 
 storage, and also ensure that FLog2 and CLog2 are "entire 
 functions".  To give an optimised example of FLog(2) in x86-64 
 assembly language:<br>
 
 <br>
 
 XOR EDX, EDX<br>
 
 BSR EAX, ECX // ZF is set if ECX is zero<br>
 
 CMOVZ EAX, EDX // Zero (EDX) written to result if ZF is set.<br>
 
 <br>
 
 Some kind of deep optimization could be used if the input is 
 known to be non-zero and remove the instructions either side of 
 BSR.<br>
 
 <br>
 
 (Alternative names: FILog2 and CILog2, to indicate they work on 
 integers and to distinguish them from versions that work with 
 floating-point numbers)<br>
 
 <br>
 
 Gareth<br>
 
 </div> 
 <!--'"--><br>
 
 <fieldset class="mimeAttachmentHeader"></fieldset> 
 <br>
 
 <pre wrap="">_______________________________________________ 
fpc-devel maillist - <a class="moz-txt-link-abbreviated" href="mailto:fpc-devel@lists.freepascal.org">fpc-devel@lists.freepascal.org</a> 
<a class="moz-txt-link-freetext" href="http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel">http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel</a> 
</pre> 
 </blockquote> 
 <br>
 
  
 
 

_______________________________________________<br>

fpc-devel maillist  -  <a href="mailto:fpc-devel@lists.freepascal.org">fpc-devel@lists.freepascal.org</a><br>

<a target="_blank" href="<a href="http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel">http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel</a>"><span style="color: red;">http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel</span></a><br>

<br>

</defanged_body></defanged_meta></blockquote></HTML>