I have a few questions about complex numbers in BASIC progs:

1. Why use them?

2. What uses do they have?

3. How can I use them?

It's a question that's been on my mind all day. I gotta know.

ok, they are useful because they can store 2 number inside of one.

a real and complex use the same variable A-Z + Theta

just do A+Bi->(var) for a complex number

Oh so it saves memory. Or you can use it to store two values for similiar purposes like pixel-coordinates. I still have questions though:

How do you recall the data?

Do you simply use real( and (imag?

If I wanted to alter var A with value 3+2i, can I do A+3->A to make it 6+2i or A+3i->A to make it 3+5i? I think adding a real number works but just not sure about the imagnary part.

yes. all of that is true except the memory part.

it uses half the variables, but almost the same memory wise. useful if you need a junk load of variables, most of which are in pairs

Imaginary variables wouldn't be the right way to go, from what I know.

Yes, they take twice the memory, but it would regularly require usage of real() (xlib users beware!). (Edit: and they are twice as slow to work with.)

If you want the same effects but in a mem-efficient way, use decimal values with iPart() and fPart().

Example: extract coordinates {27,54}

**Quote:**

27.54 -> A

iPart(A -> B

fPart(A)E2 -> C

Text(B,C,"TEXT!!!

How's that for an elite entrance?
Don't forget to add the "a+bi" token at the beginning of your program and the "real" token when it quits, otherwise you may get Err:Imaginary. They are [Mode][down x6][right][enter] and [Mode][down x6][enter] respectively.

I thought that was only for the roots of negatives?

that's what i is - sqrt(-1)...

**Radical Pi wrote:**

Imaginary variables wouldn't be the right way to go, from what I know.

Yes, they take twice the memory, but it would regularly require usage of real() (xlib users beware!). (Edit: and they are twice as slow to work with.)

If you want the same effects but in a mem-efficient way, use decimal values with iPart() and fPart().

Example: extract coordinates {27,54}

**Quote:**

27.54 -> A

iPart(A -> B

fPart(A)E2 -> C

Text(B,C,"TEXT!!!

How's that for an elite entrance?

I love that trick,. Its great for minimizing space, and it allows you to store massive numbers of variables in 1 as long as you can ensure that the variables stay in a given range
Oh so complex isn't the way to go. Decimals it is.

**KermMartian wrote:**

that's what I is - sqrt(-1)...

Sort of what I meant. But if you enter only i on the homescreen, the mode doesn't matter. TI made a+bi specifically for quadratic solvers.
Perhaps everyone is above this, but need I mention that you can use complex numbers for their intended purposes in mathematics? They have many uses, such as fractals and rational root theorem and other stuff as well. Using complex numbers as a data structure is pretty sheisty; I wouldn't reccomend it. (BTW, the reason your i's keep getting capitalized is because I set up a word filter a while ago so I wouldn't have to suffer from your bad grammar.)

Complex vars should be kept in the mathematical programs. Besides that they aren't small and are just as slow as lists. Floating point is the way to go, as mentioned.

Yea, complex numbers are overly slow. they're most convenient for storing pairs of related vars together without taking up too much mem and keeping the var count manageable.

I was going to post, continuing the bashing of imaginary values, but we got all that already.

How about something positive they can do?

That hasn't already been said? Well, they sure prevent noobs from understanding your code

.

You could store alot of coordinates with numbers like .12345678901234+.12345678901234i.

**Radical Pi wrote:**

You could store alot of coordinates with numbers like .12345678901234+.12345678901234i.

but its slower than .1234567890123412345678901234
**elfprince13 wrote:**

**Radical Pi wrote:**

You could store alot of coordinates with numbers like .12345678901234+.12345678901234i.

but its slower than .1234567890123412345678901234

But it doesn't get truncated.