# Why j for Imaginary Unit?

# Why j for Imaginary Unit?

Join the DZone community and get the full member experience.

Join For FreeHortonworks Sandbox for HDP and HDF is your chance to get started on learning, developing, testing and trying out new features. Each download comes preconfigured with interactive tutorials, sample data and developments from the Apache community.

Electrical engineers use *j* for the square root of -1 while nearly everyone else uses *i*. The usual explanation is that EE’s do this because they use *i* for current. But here’s one advantage to using *j* that has nothing to do with electrical engineering.

The symbols **i**, **j**, and **k** are used for unit vectors in the directions of the *x*, *y*, and *z* axes respectively. That means that “i” has two different meanings in the real plane, depending on whether you think of it as the vector space spanned by **i** and **j** or as complex numbers. But if you use *j* to represent the imaginary unit, its meaning does not change. Either way it points along the *y* axis.

Said another way, bold face **i **and italic *i* point in different directions But bold face **j** and italic *j*both point in the same direction.

Here’s what moving from vectors to complex numbers looks like in math notation:

And here’s what it looks like in electrical engineering notation:

I don’t expect math notation to change, nor would I want it to. I’m happy with *i*. But using *j* might make moving between vectors and complex numbers a little easier.

***

By the way, I use *j* on @DSP_fact. DSP came out of electrical engineering, so *j* is conventional there. I also use *j* in Python because that’s what the language requires.

Hortonworks Community Connection (HCC) is an online collaboration destination for developers, DevOps, customers and partners to get answers to questions, collaborate on technical articles and share code examples from GitHub. Join the discussion.

Published at DZone with permission of John Cook , DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

## {{ parent.title || parent.header.title}}

## {{ parent.tldr }}

## {{ parent.linkDescription }}

{{ parent.urlSource.name }}