Skip to main content
Grammar
Source Link
chux
  • 36.5k
  • 2
  • 43
  • 97

Seem strange to use VLAs and multiple malloc() allocations - and not checking for success (that- that is unsafe).

When able, use restrict. When Compiler can assume refenced data does not overlap, it and so allows for potential optimizations. It also lets the user to know data should not overlap. As is, x and result could overlap and code works correctly. Yet I suspect later code re-org may not support that. Do you really want the user to be allowed to provide overlapped data?

fft() uses unsigned. size_t is the Goldilocks type for array sizing and indexing. Neither size_t is neither too narrow nor too wide for a general purpose sizing with fft().

Seem strange to use VLAs and multiple malloc() allocations - and not checking for success (that is unsafe).

When able, use restrict. When refenced data does not overlap, it allows for potential optimizations. It also lets the user to know data should not overlap. As is, x and result could overlap and code works correctly. Yet I suspect later code re-org may not support that. Do you really want the user to be allowed to provide overlapped data?

fft() uses unsigned. size_t is the Goldilocks type for array sizing and indexing. Neither too narrow nor too wide for a general purpose fft().

Seem strange to use VLAs and multiple malloc() allocations - and not checking for success - that is unsafe.

When able, use restrict. Compiler can assume refenced data does not overlap and so allows for potential optimizations. It also lets the user know data should not overlap. As is, x and result could overlap and code works correctly. Yet I suspect later code re-org may not support that. Do you really want the user to be allowed to provide overlapped data?

fft() uses unsigned. size_t is the Goldilocks type for array sizing and indexing. size_t is neither too narrow nor too wide for a general purpose sizing with fft().

Added ref
Source Link
chux
  • 36.5k
  • 2
  • 43
  • 97

Late to the party...

Memory

Code should checkcheck if N is not a power of 2.

I'd expect fft() calls to apppass in a size_t for size. As   unsigned may narrow a size_t and thus create a pesky compiler warning.

// void fft(double complex *x, unsigned int N, double complex *result){
double complex *fft*fft_alloc(size_t n, const double complex x[n]) {

Late to the party...

Memory

Code should check if N is not a power of 2.

I'd expect fft() calls to app in a size_t for size. As unsigned may narrow a size_t and thus create a pesky compiler warning.

// void fft(double complex *x, unsigned int N, double complex *result){
double complex *fft(size_t n, const double complex x[n]){

Memory

Code should check if N is not a power of 2.

I'd expect fft() calls to pass in a size_t for size.   unsigned may narrow a size_t and thus create a pesky compiler warning.

// void fft(double complex *x, unsigned int N, double complex *result){
double complex *fft_alloc(size_t n, const double complex x[n]) {
added 472 characters in body
Source Link
chux
  • 36.5k
  • 2
  • 43
  • 97

IMO, this improves output as small values do not report like a zero value.

Design

Perhaps allocate the result space?

// void fft(double complex *x, unsigned int N, double complex *result){
double complex *fft(size_t n, const double complex x[n]){

IMO, this improves output as small values do not report like a zero value.

Design

Perhaps allocate the result space?

// void fft(double complex *x, unsigned int N, double complex *result){
double complex *fft(size_t n, const double complex x[n]){
added 472 characters in body
Source Link
chux
  • 36.5k
  • 2
  • 43
  • 97
Loading
added 472 characters in body
Source Link
chux
  • 36.5k
  • 2
  • 43
  • 97
Loading
added 472 characters in body
Source Link
chux
  • 36.5k
  • 2
  • 43
  • 97
Loading
Source Link
chux
  • 36.5k
  • 2
  • 43
  • 97
Loading