Path: news.mathworks.com!not-for-mail
From: <HIDDEN>
Newsgroups: comp.soft-sys.matlab
Subject: Re: Matlab coder and FFT
Date: Wed, 18 Apr 2012 19:40:14 +0000 (UTC)
Organization: Rincon Research Corp
Lines: 8
Message-ID: <jmn5au$85a$1@newscl01ah.mathworks.com>
References: <jmkoij$hot$1@newscl01ah.mathworks.com> <jmn4k8$4o6$1@newscl01ah.mathworks.com>
Reply-To: <HIDDEN>
NNTP-Posting-Host: www-03-blr.mathworks.com
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Trace: newscl01ah.mathworks.com 1334778014 8362 172.30.248.48 (18 Apr 2012 19:40:14 GMT)
X-Complaints-To: news@mathworks.com
NNTP-Posting-Date: Wed, 18 Apr 2012 19:40:14 +0000 (UTC)
X-Newsreader: MATLAB Central Newsreader 2235717
Xref: news.mathworks.com comp.soft-sys.matlab:765059

"Mark Shore" wrote in message <jmn4k8$4o6$1@newscl01ah.mathworks.com>...
> And that's still the same in online documentation for 2012a
> 
> fft   Length of input vector must be a power of 2.
> 
> http://www.mathworks.com/help/toolbox/eml/ug/bq1h2z7-11.html

Thanks.  I guess I wasn't really in doubt that it had to be a power of two, just in denial that the usefulness of the coder for so many of my problems has just (from my perspective) been destroyed.  One routine I converted to mex now takes 3x longer to run.  I guess getting the good FFT (FFTW I think) to compile into stuff was too hard so they just punted and put something in from a textbook.  I hope they figure this out for a future release.