[Cuis-dev] New updates posted on Github

[Luciano Notarfrancesco]

Looks great, thanks!

On Wed, Jun 26, 2019 at 7:04 PM Juan Vuletich <juan at jvuletich.org> wrote:

> 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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20190627/4aff503e/attachment.htm>