You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Why "domain error" in [3,4]? If a primitive judges it results to NaN from input not containing NaN then "NaN error" should be thrown. But this is not the case, it's just extracting NaN from compound already containing NaN.
If computations must propagate NaN, then shouldn't [5,6] result to NaN?
The text was updated successfully, but these errors were encountered:
The following explanation is based on read the source code and take a bold guess of what it does.
There are a few interesting rules, for o., if left argument is integer and right argument is double float, the cirID function is called, if any of the arguments are complex number, both argument are converted to complex and the cirZZ function is called instead.
So if wrote 9j0 o. _. the same domain error would be raised.
I did not find exactly where domain error was raised, but a possible explanation is by default zcir returns a complex number, but J would try to retract the complex number result to double float if possible, which only happens if left arguments are 9, 10, 11, and when the result is NaN the retraction to double float array would fail and that raises domain error.
To prove that, this example prevents the result been retracted to float and although the complex version of circle function is used, no domain error is detected.
9j0 7j0 o. _. _. NB. need j903
_. _.j_.
9j0 _9j0 o. _. _.j_.
_. _.j_.
It is reasonable to have such kind of check given most o. functions now no longer allows _. and the use of NaN is discourage, but I think theirs is also a good reason to remove such a kind of unnecessary restriction if the same logic is not used elsewhere.
Questions:
The text was updated successfully, but these errors were encountered: