DSP Naming Conventions

[ktakagaki]

I've started to work on fftshift and fftfreq per the issue:
numpy parity: finish FFts #127

I'm sorry to vacillate on this, but I realize now that while "FourierTransform" and "InverseFourierTransform" are conceptually nice clean names, they aren't quite practical. As I explore more of the breeze package, I've also gotten a better feeling for naming within the rest of the package, as well. I think I want to rename them to "FourierTr" and "iFourierTr."

My main wish is that breeze.signal naming should be clean and coherent, so I've reviewed the DSP/image analysis packages in Matlab and SciPy, and sketched out an overview for breeze.signal, to figure out a coherent naming scheme that is also practical. Please take a look at:

https://github.com/ktakagaki/breeze/wiki/Digital-Signal-Processing
(crossed out functions are ones that I probably won't get around to myself in the immediate future, so the exact naming is not an acute problem)

The main point is that I put in some abbreviations (eg FourierTr, iFourierTr, chirpWf), and for most actions, I use a simple, full verb (eg convolve, correlate, detrend, ...), with minor implementation differences relegated to option arguments. I also tried to start the names logically without abbreviation, so that IDE suggestions would be reasonable. I would be OK with alternate abbreviations, as long as they would be coherent within the package.

@dlwh and @rtreffer , please let me know what you think.

[dlwh]

Ok, cool! So, I'm definitely on board with coherent. I can't really comment
on specifics, since I don't know signal processing.

I'm not in love with Tr as the suffix. Tr could be trace, transpose, or
transform. But, this seems like something people would get used to quickly,
so it's probably fine. I agree that Transform starts to get a little long.

-- David

On Sun, Feb 2, 2014 at 9:28 AM, ktakagaki notifications@github.com wrote:

I've started to work on fftshift and fftfreq per the issue:
numpy parity: finish FFts #127#127

I'm sorry to vacillate on this, but I realize now that while
"FourierTransform" and "InverseFourierTransform" are conceptually nice
clean names, they aren't quite practical. As I explore more of the breeze
package, I've also gotten a better feeling for naming within the rest of
the package, as well. I think I want to rename them to "FourierTr" and
"iFourierTr."

My main wish is that breeze.signal naming should be clean and coherent,
so I've reviewed the DSP/image analysis packages in Matlab and SciPy, and
sketched out an overview for breeze.signal, to figure out a coherent
naming scheme that is also practical. Please take a look at:

https://github.com/ktakagaki/breeze/wiki/Digital-Signal-Processing
(crossed out functions are ones that I probably won't get around to
myself in the immediate future, so the exact naming is not an acute problem)

The main point is that I put in some abbreviations (eg FourierTr,
iFourierTr, chirpWf), and for most actions, I use a simple, full verb (eg
convolve, correlate, detrend, ...), with minor implementation issues
relegated to options. I also tried to start the names logically without
abbreviation, so that IDE suggestions would be reasonable. I would be OK
with alternate abbreviations, as long as they would be coherent within the
package.

@dlwh https://github.com/dlwh and @rtrefferhttps://github.com/rtreffer, please let me know what you think.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/145
.

[ktakagaki]

Would "fourierTf" be better? "FourierTransf" would be OK too, but it would
be getting a bit long. A slightly more esoteric abbreviation would be
"fourierTx"... Kenta

On Mon, Feb 3, 2014 at 7:22 AM, David Hall notifications@github.com wrote:

Ok, cool! So, I'm definitely on board with coherent. I can't really
comment
on specifics, since I don't know signal processing.

I'm not in love with Tr as the suffix. Tr could be trace, transpose, or
transform. But, this seems like something people would get used to
quickly,
so it's probably fine. I agree that Transform starts to get a little long.

-- David

On Sun, Feb 2, 2014 at 9:28 AM, ktakagaki notifications@github.com
wrote:

I've started to work on fftshift and fftfreq per the issue:
numpy parity: finish FFts #127<
https://github.com/scalanlp/breeze/issues/127>

I'm sorry to vacillate on this, but I realize now that while
"FourierTransform" and "InverseFourierTransform" are conceptually nice
clean names, they aren't quite practical. As I explore more of the
breeze
package, I've also gotten a better feeling for naming within the rest of
the package, as well. I think I want to rename them to "FourierTr" and
"iFourierTr."

My main wish is that breeze.signal naming should be clean and
coherent,
so I've reviewed the DSP/image analysis packages in Matlab and SciPy,
and
sketched out an overview for breeze.signal, to figure out a coherent
naming scheme that is also practical. Please take a look at:

https://github.com/ktakagaki/breeze/wiki/Digital-Signal-Processing
(crossed out functions are ones that I probably won't get around to
myself in the immediate future, so the exact naming is not an acute
problem)

The main point is that I put in some abbreviations (eg FourierTr,
iFourierTr, chirpWf), and for most actions, I use a simple, full verb
(eg
convolve, correlate, detrend, ...), with minor implementation issues
relegated to options. I also tried to start the names logically without
abbreviation, so that IDE suggestions would be reasonable. I would be OK
with alternate abbreviations, as long as they would be coherent within
the
package.

@dlwh https://github.com/dlwh and @rtreffer<
https://github.com/rtreffer>, please let me know what you think.

—
Reply to this email directly or view it on GitHub<
https://github.com/scalanlp/breeze/issues/145>
.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/145#issuecomment-33927344
.

[dlwh]

Tr's probably best. We can always deprecate and change if we need to.

On Sun, Feb 2, 2014 at 10:33 PM, ktakagaki notifications@github.com wrote:

Would "fourierTf" be better? "FourierTransf" would be OK too, but it would
be getting a bit long. A slightly more esoteric abbreviation would be
"fourierTx"... Kenta

On Mon, Feb 3, 2014 at 7:22 AM, David Hall notifications@github.com
wrote:

Ok, cool! So, I'm definitely on board with coherent. I can't really
comment
on specifics, since I don't know signal processing.

I'm not in love with Tr as the suffix. Tr could be trace, transpose, or
transform. But, this seems like something people would get used to
quickly,
so it's probably fine. I agree that Transform starts to get a little
long.

-- David

On Sun, Feb 2, 2014 at 9:28 AM, ktakagaki notifications@github.com
wrote:

I've started to work on fftshift and fftfreq per the issue:
numpy parity: finish FFts #127<
https://github.com/scalanlp/breeze/issues/127>

I'm sorry to vacillate on this, but I realize now that while
"FourierTransform" and "InverseFourierTransform" are conceptually nice
clean names, they aren't quite practical. As I explore more of the
breeze
package, I've also gotten a better feeling for naming within the rest
of
the package, as well. I think I want to rename them to "FourierTr" and
"iFourierTr."

My main wish is that breeze.signal naming should be clean and
coherent,
so I've reviewed the DSP/image analysis packages in Matlab and SciPy,
and
sketched out an overview for breeze.signal, to figure out a coherent
naming scheme that is also practical. Please take a look at:

https://github.com/ktakagaki/breeze/wiki/Digital-Signal-Processing
(crossed out functions are ones that I probably won't get around to
myself in the immediate future, so the exact naming is not an acute
problem)

The main point is that I put in some abbreviations (eg FourierTr,
iFourierTr, chirpWf), and for most actions, I use a simple, full verb
(eg
convolve, correlate, detrend, ...), with minor implementation issues
relegated to options. I also tried to start the names logically
without
abbreviation, so that IDE suggestions would be reasonable. I would be
OK
with alternate abbreviations, as long as they would be coherent within
the
package.

@dlwh https://github.com/dlwh and @rtreffer<
https://github.com/rtreffer>, please let me know what you think.

—
Reply to this email directly or view it on GitHub<
https://github.com/scalanlp/breeze/issues/145>
.

—
Reply to this email directly or view it on GitHub<
https://github.com/scalanlp/breeze/issues/145#issuecomment-33927344>
.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/145#issuecomment-33927638
.