Prev: draw a game board
Next: Posting Code to Matlab Central
From: Bruno Luong on 9 Apr 2010 17:58 The Savitzky-Golay filter (Signal Processing Toolbox) no longer supports array of single type. I bumps into an unexpected error message when running my code on 2010A. It seems TMW just adds a type check in this function (lines 51-55) which was not there previously. The odd thing is that - It works just fine if the check code is commented out. - Unless if I overlook - I can't find this behavior documented in the release note. So my question is simply: who can explain "why"? Bruno
From: Bruno Luong on 9 Apr 2010 18:03 "Bruno Luong" <b.luong(a)fogale.findmycountry> wrote in message <hpo7td$f9f$1(a)fred.mathworks.com>... > > > So my question is simply: who can explain "why"? PS: Typing "why" on command window does not really help.
From: Honglei Chen on 9 Apr 2010 18:41 Hi Bruno, If you open the documentation for Signal Processing Toolbox and go to Getting Started -> Overview -> Product Overview, under Supported Data Types section, it states that The Signal Processing Toolbox software supports only double-precision inputs. If you input single-precision floating-point or integer data, you should not expect to receive correct results, and in many cases, an error will occur. The Filter Design Toolbox? product, in conjunction with the Fixed-Point Toolbox? product, enables single-precision floating-point and fixed-point support for filtering and filter design. HTH, Honglei Bruno Luong wrote: > The Savitzky-Golay filter (Signal Processing Toolbox) no longer supports > array of single type. I bumps into an unexpected error message when > running my code on 2010A. It seems TMW just adds a type check in this > function (lines 51-55) which was not there previously. The odd thing is > that - It works just fine if the check code is commented out. - Unless if > I overlook - I can't find this behavior documented in the release note. > > So my question is simply: who can explain "why"? > > Bruno
From: Bruno Luong on 10 Apr 2010 04:35 Honglei Chen <Honglei.Chen(a)mathworks.com> wrote in message <hpoaee$l6j$1(a)fred.mathworks.com>... > Hi Bruno, > > If you open the documentation for Signal Processing Toolbox and go to > Getting Started -> Overview -> Product Overview, under Supported Data Types > section, it states that > > The Signal Processing Toolbox software supports only double-precision > inputs. If you input single-precision floating-point or integer data, you > should not expect to receive correct results, and in many cases, an error > will occur. The Filter Design Toolbox? product, in conjunction with the > Fixed-Point Toolbox? product, enables single-precision floating-point and > fixed-point support for filtering and filter design. > > HTH, > > Honglei > Thank you for Honglei, now it get even more question. The Release Notes of Version 6.13 of Signale Pr. Tbx states: "Single-Precision Support Added for dfilt Objects In R2010a, users can construct dfilt objects with single-precision floating point arithmetic. Set the Arithmetic property to 'single' to obtain a single-precision floating point representation of the filter coefficients.". Clearly it extend some of the capability of SINGLE. TMW must take more seriously the backward compatibility into account. The decision to cut down the action of the set function or move to another toolbox can be problematic problem for us. We develop commercial code that measures the blade of a turbine engine. Monitoring an engine with 20 blades running at 10kRPM requires a lot of memory. Storing it on single increase the monitoring time by 2 given the limited amount of memory. If TMW decides not to support SINGLE, then the spec of our product divide by half in the same token. In this particular case, fortunately we can still access to the source code and comment out the unfortunate checking part and get back to the original specification. But I must say, reducing a filter method that can no longer work on SINGLE, and further more without apparent numerical reason that can justify it (Yes I test the filter for few years with SINGLE and it works just fine) , and without proper warning in the release note is not the right thing to do. I used to defend the use of Matlab in our commercial product when I discuss to my colleagues about software development strategy. I'll be more reluctant to do so in the future. Bruno
From: Jan Simon on 10 Apr 2010 12:30
Dear Bruno! > I used to defend the use of Matlab in our commercial product when I discuss to my colleagues about software development strategy. I'll be more reluctant to do so in the future. I agree. I had a lot of troubles with loosing features in newer Matlab versions, especially if they are not mentioned in the documentation as e.g. the FOPEN('vaxd') problem. I also defend the use of Matlab for our software for clinical decision making --- but I absolutely recommend our custumors *not* to update to newer versions! Obviously this should conflict with the financial interests of TMW, so I'm really surprised, that Matlab has still no long term support (bugs are fixed in the newest or more likely in the next version only), which would be essential for using Matlab for "serious" fields. Jan PS: Of course I know, that half of the CSSMers are working "seriously" with Matlab (the other half tries to get their homework solved by anyone else). But I have the impression that decisions about surgical operations of children should in no way and under no circumstances be influenced by (undocumented) changes of the computing system. I know, that every software is subject to changes, which must cause incompatibilities ever. Nevertheless, it would be nice to see that TMW does its very best. |