no direct write to a complex types components?

[simon place]

{please tell me if i am missing something here}

1. seems common to want to change a component of a complex number.

2. seems common to manipulate complex numbers in a tight loop (simulation)

but whereas you can read a component...

real com.:=Real(cmplx)

imaginary com.:=Imag(cmplx)

i can't see any way to write to a component.

i had hoped, maybe, the compiler would help, but testing shows the, expected, 5x longer time for this solution/hack....

c+=complex(0,v)  // add v to the imaginary part of c

seems re-implementing complex is pretty simple, but its less clear/documentable and this seems like an omission to me.

BTW couldn't find any help in reflect

BTW c code just does it fine.

[Sean Liao]

https://go.dev/play/p/_uLHdBIRLBv

- sean

--
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...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/golang-nuts/2de28954-fccb-48f2-9374-950f3ba6d573n%40googlegroups.com.

[simon place]

thanks, but isn't that only for a constant?

and

wouldn't it be making a complete complex pair underneath and so no faster?

On Saturday 9 November 2024 at 00:56:52 UTC Sean Liao wrote:

https://go.dev/play/p/_uLHdBIRLBv

- sean

74-950f3ba6d573n%40googlegroups.com.

[Brian Candler]

On Saturday 9 November 2024 at 00:25:21 UTC simon place wrote:

but whereas you can read a component...

real com.:=Real(cmplx)

imaginary com.:=Imag(cmplx)

i can't see any way to write to a component.

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)

[simon place]

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)

really, strings are usefully immutable so as to be keys in maps, (also utf8 encoded makes for non-editable) complex numbers as keys make no sense and would be a BIG mistake.

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.

[Dan Kortschak]

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.

[simon place]

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.

 

[Axel Wagner]

On Mon, 11 Nov 2024 at 03:24, 'simon place' via golang-nuts <golan...@googlegroups.com> wrote:

yes, see the bench and code in the OP.

I don't see any benchmarking code in this thread.

From the godbolt output, it looks to me as if the compiler generates a single move, which seems as efficient as it can be.

 

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...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/golang-nuts/2b65ea5f-3fbd-440d-a6e0-400d61d6a3efn%40googlegroups.com.

[simon place]

OK, i have it, apologies..

i was benching the complex path with an extra dereference and with such a tight loop it makes so much more difference than i thought was possible.

now all makes sense. thanks.