On Sunday 10 November 2024 at 01:26:51 UTC Dan Kortschak wrote:
On Sat, 2024-11-09 at 17:01 -0800, 'simon place' via golang-nuts wrote: > > > That's because Complex numbers are immutable - just like strings, > > and regular numbers for that matter. > > > > Hence to replace one component of a complex number, you have to > > create a new complex number. > > https://go.dev/play/p/Cf06Ui6fR59 > > > > new_imag := 3.0 > > a = complex(real(a), new_imag) > after all complex numbers are component editable in the problem- > space, and also in the underlying solution-space (hardware) so this > is a nasty intermediate miss-match, seems like a mistake to me. Have you checked to see whether the compiler elides the parts that are not changing a component? From what I can see it does. yes, see the bench and code in the OP. but since your way is slightly different (just possibly making a difference to the compiler? unpredictable eliding seems a poor thing to rely on.) i benched that, exactly the same, that is, about 5x slower than just operating on a single float. i'd look at the m/c, except at 500% slower i'm happy it can't be, maybe one day? i'm going to search for a lib. (if/when speed becomes a problem.) also unfortunate, complex not being a lib, that wouldn't just be a drop in. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/golang-nuts/2b65ea5f-3fbd-440d-a6e0-400d61d6a3efn%40googlegroups.com.
