[Cuis-dev] Negative sqrt

[Gerald Klix]

On 2020-12-30 16:57, Juan Vuletich wrote:
> Hi Gerald,
> 
> On 12/30/2020 9:32 AM, Gerald Klix via Cuis-dev wrote:
>> Hi Juan,
>>
>> please see below.
> ...
>>> Note that if you haven't selected "Install Complex" or "Don't ask 
>>> again", `-4.0 sqrt` will still ask the question, the same as if the 
>>> receiver was an integer.
>>>
>>> The difference is if you chose not to install Complex. And, yes, it 
>>> is the intended behavior.
>>>
>>> If Complex is installed, -4 sqrt and -4.0 sqrt answer Complex. But if 
>>> not, -4 sqrt is an error, but -4.0 sqrt isNaN. This is because of the 
>>> Floating Point standard.
>>>
>>> Floats play by their own rules, stated in the IEEE 754 standard. They 
>>> include special values Float infinity (so 1.0 / 0.0 = Float infinity) 
>>> and Float nan (so -4.0 sqrt isNaN). The other Number classes don't 
>>> handle these concepts, and just give errors.
>> OK, point taken: I agree.
>>>
>>> Strict compliance of IEEE 754 is important. Most well known numeric 
>>> algorithms are guaranteed to give the expected results if the 
>>> standard is followed, and might break otherwise.
>> Well, strict IEEE 754 compliance will also require  the programming 
>> language to raise/signal/throw
>> exceptions for certain types of NaNs, if
>> the program/programmer requests those.
> 
> Yes. For Signaling NaNs. Section 6.2 of the standard says that the only 
> way to generate a Signaling NaN is as a constant set by the programmer. 
> This behavior can easily be implemented in Smalltalk with a SignalingNaN 
> class, perhaps inheriting from Object, so no numeric operation will work 
> on them, and an exception will be raised. The usual Smalltalk practice 
> is to just use nil.
> 
> Supporting that behavior for signaling NaNs would require modifying the 
> VM: Just did a quick experiment, and all NaNs are treated as silent NaN 
> by the VM.
Ok.
> 
>>
>> IEEE-754 2019 Clause 8.3 specifies so
>> called "immediate exception handling",
>> which, IHMO, should be implemented by signaling
>> Smalltalk exceptions. But this interpretation
>> is based on my limited understanding of the standard's concepts and 
>> may be wrong.
>> I am by no means an expert in this domain,
>> I only want to express my impression,
>> that full IEEE-754 is probably not easy to achieve. Let's be careful 
>> here!
>>
>>
>> Best Regards,
>>
>> Gerald
> 
> Having worked with numerical algorithms using floating point, mainly in 
> image and signal processing, but also in numerical linear algebra and 
> discrete simulations, I never saw Signaling NaNs have any relevance. I 
> don't think they are used much in practice. And they can be implemented 
> in Smalltalk.
I can well imagine that the standard's requirements are of little use in 
practice. If you can live without signalling NaNs, I will have not 
objections. Before starting to read the standard, I quickly checked 
Python's behavior in this case:

bear at speedy ~/D/Specs> ~/py381/bin/python3
Python 3.8.1 (tags/v3.8.1-dirty:1b293b6006, Feb  3 2020, 18:37:36)
[GCC 7.4.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
 >>> from math import sqrt
 >>> sqrt(-4.0)
Traceback (most recent call last):
   File "<stdin>", line 1, in <module>
ValueError: math domain error

I thought to myself: Here be dragons!
When taking a closer look I discovered this behavior:

 >>> sqrt(-4.0+0j)
Traceback (most recent call last):
   File "<stdin>", line 1, in <module>
TypeError: can't convert complex to float
 >>> from cmath import sqrt
 >>> sqrt(-4.0+0j)
2j

I don't know what to think about this.
> 
> Still, you may bring the issue to VM-Dev. If floating point primitives 
> are made to fail when encountering a Signaling NaN, I'll be happy to 
> raise an appropriate Smalltalk exception.
I am not competent enough to do this.
> 
> Thanks,
> 

Best Regards,

Gerald