Maybe this needs to be in Developers.
Given
const t = 3i;
const v = INFINITY + 6i;
const tv = t * v;
If t which is **imag**(64) is converted to complex(128) before multiplication, then `tv` will be a complex number with a real part of _NaN_ and a complex part of INFINITY.
However, the mathematically correct result should have a real part of `-18.0` which should be discernable if `t` is **imag**(64) and the operator rules were modified.
Food for thought. Very, very low priority.Hi Damian —
Just saw this before signing off and got curious. Looking into the imag * complex operator overload, it appears to be doing the right thing, and it looks to me like the place where the -18.0 is disappearing on us is in the cast from a tuple of values to a complex rather than in the multiplication operator itself.
Here's some code where I'm exploring the values and types of various expressions where the middle cluster of writeln()s reproduces the guts of that * overload and suggests that things are looking OK up until the cast. The final cluster reinforces this impression: Run – Attempt This Online
I'm too tired to look into the cast itself tonight, but this would be good for one of us to check out tomorrow,
-Brad
There is absolutely no rush. It has been a problem in C for 30 years, supposedly able to be solved by the (now well) defined but (as yet) unimplemented Imaginary type which might see the light of day in a compiler in the next 5 years. I thought it would be good if Chapel got one up on C if it was a relatively easy fix because Chapel at least has a working and quite solid imag(w) type working.
Again, low, low priority.
@damianmoz — This should now be resolved with the merge of Improve how tuples are converted into complex values by bradcray · Pull Request #24184 · chapel-lang/chapel · GitHub. If you were to grab a copy of the main development branch, you should be able to experiment with it, and we'd be curious for any feedback.
Thanks for bringing this to our attention.
-Brad