<div dir="ltr">Looks great, thanks! </div> <div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jun 26, 2019 at 7:04 PM Juan Vuletich <<a href="mailto:juan@jvuletich.org">juan@jvuletich.org</a>> wrote: </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello, I had a chance to work on a few things with Andres Valloud, here is his summary of what we just posted on Github. First, we turned Complex into a loadable package once more. Usually the disadvantage is that loading such packages results in code overrides. For instance, since the message sqrt will have to change behavior (so that -1 sqrt returns a complex number, rather than fail outright), one would expect that loading Complex would have to modify the base system to introduce the new feature. This time, however, we engineered how Complex interacts with the rest of the system so that loading the Complex package does not result in any base system code modifications. Of course, loading Complex causes -1 sqrt to evaluate to 0 + 1i, as before. The key to accomplishing this was to introduce a new exception, NegativePowerError, which by default comes in without a defaultAction method. When Complex loads, it simply provides defaultAction so that said exceptions are handled by invoking complex number arithmetic. We hope this mechanism illustrates one way of making different code packages coexist more harmoniously. Please include Complex as a requirement to your packages as appropriate. Second, and along the same lines, we also found that the arithmetic error exceptions looked very similar and yet their implementation was very different. Further, there were some discrepancies in how they were used and handled (some would do things like ^ZeroDivide signal..., and some others simply ZeroDivide signal...). In addition, for floating point numbers, some of the results were not following the IEEE spec. As an aside, it seems trivial, but even the following four operations require *substantial* spec lawyering to get right: 0.0 - 0.0 0.0 - -0.0 -0.0 - 0.0 -0.0 - -0.0 Looks trivial --- it isn't. And then you consider +, /, and *. So, we reorganized these exceptions under a general class called ArithmeticMessageError. This new abstract exception has three instance variables that will look familiar immediately: receiver, message, and arguments. These are provided by the location where the exception occurs, which in turn allows e.g. defaultAction to resume the computation as required without having to either a) guess what went wrong, or b) needing a multitude of different exceptions depending on what actually happened. Currently, ArithmeticMessageError has two subclasses for situations that are special enough to deserve their own class: division by zero, and raising a negative number to powers. In the "rationals" (i.e. Integer and Fraction), things like 1/0 are undefined. But in floating point land, dividing aFloat by zero can be one of three things (!): +INF, -INF, and NaN. No, this was not our idea, but we care that things work according to the manual so that our system enables as many folks as possible. Since floating point requires special handling, there is a ZeroDivide exception to do so. Something similar happens with NegativePowerError. In the "rationals", things like -8 raisedTo: 1/3 make sense. That's because, generally, a^(p/q) = (a^p)^1/q Note the sign of the result, when it is defined, depends on the sign of a and (essentially) the "parity" of p/q. Again, this was not our idea, but we gather the world mostly works this way :). With floating point numbers, however, it's not obvious what a^b is when a and b are floating point numbers. Suppose a is negative, and b is 1.0 / 3.0. Looking at that floating point 1/3, does that mean that if the last bit of the mantissa is zero, that the result does not exist? And that if the last bit of the mantissa is 1, then it's ok to take something *like* the cubic root of a? What does that even mean when b is the result of who knows how many operations, each of which is presumably on the order of one ulp off? Thus, said powers fail, and the result is NaN for floating point numbers. If you are curious, consider the fantastic behavior of the following two examples. Both fail gracefully, as they should. -32 raisedTo: (1/5.0) asTrueFraction -32 raisedTo: (1/5.0) successor asTrueFraction Note that if Complex is loaded, however, a^b will happily work for floating point numbers and produce complex numbers, as expected. For instance, take G_6. Since -8 is 8 * w_3, then one of the possible cubic roots is 2 * w_2 (and so is 2 * w_5). If this behavior does not work for you, look for the relevant defaultAction method, and also take a look at floatErrorValue. We tried to make these moldable and easy to change so that people can configure the system to their liking, while requiring minimal modifications. Third, all these improvements to exceptions brought up the problem that SUnit was catching errors by handling Error. This is not ideal because, as just exemplified above, any exception can provide a defaultAction method that recovers its occurrence. But handling Error like this: [3 / 0] on: Error do: [:ex | ex return: 'everybody knows this is bad'] prevents Error from running its defaultAction, and so a recoverable error always becomes an unrecoverable error. Instead, the above code should say this: [3 / 0] on: UnhandledError do: [:ex | ex return: 'evidently this error was unexpected'] Consequently, TestResult exError should answer UnhandledError, rather than Error. We applied this change. Please consider how you handle exceptions with these observations in mind to maximize flexibility and robustness. Andres thinking the above should be at least mostly correct, Juan approving without being too worried. </blockquote></div>