<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Hi Stephen</div><div class=""><br class=""></div><br class=""><blockquote type="cite" class="">Hi Erica, thanks for the feedback.<br class=""><br class=""><blockquote type="cite" class="">On Apr 14, 2016, at 6:29 PM, Erica Sadun <<a href="mailto:erica@ericasadun.com" class="">erica@ericasadun.com</a>> wrote:<br class=""><br class="">* I do use % for floating point but not as much as I first thought before I started searching through my code after reading your e-mail. But when I do use it, it's nice to have a really familiar symbol rather than a big word. </blockquote><div class=""><br class=""></div></blockquote>Agreeing completely with Erica here.<div class=""><br class=""><blockquote type="cite" class=""><br class=""><blockquote type="cite" class="">What were the ways that it was used incorrectly? Do you have some examples?<br class=""></blockquote></blockquote><blockquote type="cite" class=""><br class="">As it happens, I have a rationale sitting around from an earlier (internal) discussion:<br class=""><br class="">While C and C++ do not provide the “%” operator for floating-point types, many newer languages do (Java, C#, and Python, to name just a few). Superficially this seems reasonable, but there are severe gotchas when % is applied to floating-point data, and the results are often extremely surprising to unwary users. </blockquote><div class="">What is your definition of unwary users? Programmers that usually don’t work with floating point data? </div><div class="">No gotchas or total flabbergasting astonishment with day to day floating point usage.</div><br class=""><blockquote type="cite" class=""> C and C++ omitted this operator for good reason. Even if you think you want this operator, it is probably doing the wrong thing in subtle ways that will cause trouble for you in the future.<br class=""></blockquote>I don’t share this opinion at all.<br class=""><blockquote type="cite" class=""><br class="">The % operator on integer types satisfies the division algorithm axiom: If b is non-zero and q = a/b, r = a%b, then a = q*b + r. This property does not hold for floating-point types, because a/b does not produce an integral value.</blockquote>The axiom is correct of course, but only in a perfect world with perfect numbers. Not in real life. **</div><div class="">Floats never represent integral values, if so then they were Integers.<br class=""><br class=""><blockquote type="cite" class=""> If it did produce an integral value, it would need to be a bignum type of some sort (the integral part of DBL_MAX / DBL_MIN, for example, has over 2000 bits or 600 decimal digits).<br class=""></blockquote>Impossible. E.g. one would need a planet covered completely </div><div class="">with memory (even holographic quantum) units and even then </div><div class="">you would not have enough storage to store (one) PI with all its decimals.</div><div class="">By the way most of PIs decimals are unknown as you know.</div><div class="">It could even be that memory units on all the planets in (this) </div><div class="">the universe are even not enough to satisfy the storage need </div><div class="">for just one PI.</div><div class=""> * Please read the Hitchhikers Guide To The Galaxy for more info on this interesting subject :o)</div><div class="">Of course, the last decimals of PI are …42. Dolphins know that, but they left long ago in the future * <br class=""><blockquote type="cite" class=""><br class="">Even if a bignum type were returned, or if we ignore the loss of the division algorithm axiom, % would still be deeply flawed. </blockquote><div class=""> % is not flawed. It’s just the real life precision limitations of the floating point type. Live with it.</div><div class=""><br class=""></div><br class=""><blockquote type="cite" class="">Whereas people are generally used to modest rounding errors in floating-point arithmetic, because % is not continuous small errors are frequently enormously magnified with catastrophic results:<br class=""><br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>(swift) 10.0 % 0.1<br class=""> // r0 : Double = 0.0999999999999995 // What?!<br class=""></blockquote>As I have tried to explain in more detail before:</div><div class="">This is perfectly normal, acceptable and expected, because,</div><div class="">whether you like it or not, that is the exactly? the nature of </div><div class="">floating point numbers stored in a computer</div><div class="">(well, at least in this age) they’re not precise,</div><div class="">but in context precise enough voor most purposes in scientific </div><div class="">and engineering applications.</div><div class="">If you want to work with exact values e.g. for representing money,</div><div class="">then use an appropriate numerical type </div><div class="">or roll your own, make a struct for it.</div><div class=""><br class=""></div><div class="">Swift is poor in this because it only offers Integer and Floating point numerical types,</div><div class="">not Fixed Decimal (Like e.g. in PL/1 and C#) </div><div class="">also its Ranges and iterations are with Integers only and</div><div class="">going in one direction only.</div><div class=""> </div><div class=""><blockquote type="cite" class=""><br class="">[Explanation: 0.1 cannot be exactly represented in binary floating point; the actual value of “0.1” is 0.1000000000000000055511151231257827021181583404541015625. Other than that rounding, the entire computation is exact.]<br class=""></blockquote>no, it's not. or at least you can’t count on that. especially when intermediate expressions (with floats) are involved.</div><div class=""><br class=""></div><div class="">** (to all, not meant cynically here, and with all due respect:</div><div class="">If you don’t value floats and understand their purpose and place,</div><div class="">please go programming for a half year or so in an industrial/engineering workshop.</div><div class="">You’ll notice that these precision issues you are writing about are mostly irrelevant.</div><div class="">E.g. You could theoretically calculate the length of a steel bar for a bridge (the hardware one :o)</div><div class="">exactly to 0.000000000001 or so, but the bar in question would only coincidentally have</div><div class="">this exact value. For instance thermal expansion will be much larger. </div><div class=""><a href="http://www.engineeringtoolbox.com/thermal-expansion-metals-d_859.html" class="">http://www.engineeringtoolbox.com/thermal-expansion-metals-d_859.html</a></div><div class="">It’s all a matter of magnitude in the context/domain of what one is calculating.</div><div class=""> </div><div class=""><blockquote type="cite" class=""><br class="">Proposed Approach:<br class="">Remove the “%” operator for floating-point types. The operation is still be available via the C standard library fmod( ) function (which should be mapped to a Swiftier name, but that’s a separate proposal).<br class=""></blockquote>I completely disagree here. It is very useful in many calculations!</div><div class="">E.g. If I want to space (geometric) objects in 3D space in SceneKit</div><div class="">I don’t care and would really not notice if a block > 0.000000000000000001 or so dislocated</div><div class="">(it would also not be possible, because this small value is </div><div class="">very much less of the resolution in use, although, in theory</div><div class="">(no one has checked this :o) 3D space is infinite) <br class=""></div><div class="">Btw. SceneKit is so fast, because it uses floating point values.</div><div class=""><br class=""></div><div class="">Very sure I am missing things / come for a different time / world, etc.</div><div class="">but to me, a floating point value is nothing more than a storage location</div><div class="">holding a number of bytes, in an IEEE standard format</div><div class="">with all its related arithmetic perfectly well implemented in Swift, </div><div class="">no need to touch it or define additional functions. infinity etc.</div><div class="">So, better imho to leave it as it is. it’s OK.</div><div class=""><br class=""></div><div class="">=============</div><div class="">Off topic, but perhaps readable just the same: </div><div class=""><br class=""></div><div class="">Just a thought/ fear:</div><div class="">Watching trends here. I am also (hopefully unnecessary) </div><div class="">a bit afraid that in the long run Swift might become more </div><div class="">complex and thus as tedious to work with as Objective C? </div><div class="">Loosing it’s simplicity? </div><div class=""><br class=""></div><div class="">Note that the language should serve (nearly) every one,</div><div class=""><br class=""></div><div class="">I am now talking like an old guy, well I am 65 earth years :o) -> </div><div class="">Most of you are very talented, that’s great! and I am learning</div><div class="">things from U 2. But it appears to me that the trend is to introduce </div><div class="">a lot of “very exotic” features, (albeit with great things too that make</div><div class="">a programmer’s life easier) but for some, are they really necessary? Useful?</div><div class="">How fragile is the line between “academic” and “academic distortion” ? </div><div class="">How far does it go? </div><div class="">E.g for Strings, it is all logically very correct, Unicode and all,</div><div class="">but I had to write my own extensions for this:</div><div class=""> s2 = s1[1..5] // was an unimplemented feature. Silly.</div><div class="">One could have saved the trouble, by pushing the Unicode values</div><div class="">(with variable length of course) down as atomic values, </div><div class="">instead of the opposite and laying a character view over it...</div><div class="">using overly complicated things like</div><div class="">startIndex, strides and so on ?</div><div class="">Just one example.</div><div class=""><br class=""></div><div class="">Maybe it’s just a cultural difference,</div><div class="">but like you all the same.</div><div class=""><br class=""></div><div class="">Kind regards</div><div class="">Ted</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""> </div><div class=""><br class=""></div></body></html>