High CPU usage when calculating with 0, low with 1e-17

EDIT (first version of this question was confusing):

Hi all,

I found some peculiar behavior in R2013a:

I implemented my own textbook DFT algorithm and was amazed to see how much CPU usage was increasing when I added zero padding. The calculation time had linear proportionality to the amount of zeros I added. So I tried substituting the zeros with a very low value (1e-17) and suddenly the algorithm was super fast in comparison. I don't want to optimize the code, but understand why it takes so long when using zeros instead of floating points.

This is the trouble-causing function:

function [ Y ] = DFT_matrix( y, pointsToCalculate, samplingPoints )
% Creates a matrix with the complex factors of a DFT

Y = zeros(pointsToCalculate,pointsToCalculate);

for k = 1:pointsToCalculate
    for n = 1:pointsToCalculate
        Y(k,n) = y(n)*exp(-1j*2*pi*(k-1)*(n-1)/pointsToCalculate);
    end
end

Y = Y./samplingPoints;

end

This is my testfunction that sets all the parameters and has the function call in the last line. If you substitute paddingValue with 1e-17, it is super fast in comparison:

clear;
clc;

%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%PARAMETERS %%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%

% Signal Parameters
signalFrequency = 3906.25; % Hz
signalRunTime = 1e0; % s
signalPower = 23.9794; % dBm, 50 ohm
SNR = 1e3; % dBm

% Signal Processing Parameters
samplingPoints = 256;
windowShift = 0e2; % Samples
samplingFrequency = 1e4; % Hz
paddingNum = 6e2;
paddingValue = 0;

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%SIGNAL GENERATION %%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

% Time Vector
t = 0 : 1/samplingFrequency : signalRunTime;

% Signal Power in W
P_S = 10^(signalPower/10)/1000;

% Signal Type
A = sqrt(2*P_S*50);
signal = A*sin(2*pi*signalFrequency*t);

% AWGN
%signal = awgn(signal,SNR/1000, 'measured');

%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%CALCULATIONS %%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%

% Window Shift
shiftedWindowedSignal = signal(windowShift+1 : windowShift+samplingPoints);

% Zero Padding
shiftedPaddedWindowedSignal = padarray(shiftedWindowedSignal,[0 paddingNum], paddingValue);
pointsToCalculate = length(shiftedPaddedWindowedSignal);

% Create DFT-Matrix
Y = DFT_matrix(shiftedPaddedWindowedSignal, pointsToCalculate, samplingPoints);

Answer 1

[Jan]

I don't understand the question completely. You showed, that you have applied the zero padding by padarray (a function, that I do not have) to the variable shiftedPaddedWindow. But where is this variable used later on? Where did you inster 1e-17 instead? Which size and type do the inputs have? Could you please provide some test data?

The problem is redundant because (k-1)*(n-1) replies the same values if you e.g. interchange k and n. This can be exploited to reduce the number of expensive EXP() calls.

Another idea is to move the constant expressions out of the loop:

c = -1j*2*pi/pointsToCalculate;
Y = zeros(pointsToCalculate,pointsToCalculate);

for k = 1:pointsToCalculate
  Y(k,k) = y(k) * exp(c * (k-1) * (k-1));;
  for n = k + 1:pointsToCalculate
     d      = y(n) * exp(c * (k-1) * (n-1));
     Y(k,n) = d;
     Y(n,k) = d;
  end
end

[Helmar]

Sorry, I realize that my Question is somewhat confusing. I'll edit it and provide the full code. My goal is not to optimize the code, I can use the fft() function for that. I want to understand why it makes such a huge difference when I use either 0 or 1e-17 for padding, because if there is a good explanation, like floating point calculation vs. something else, I will never calculate things using 0 again.