sgolayfilt no longer support SINGLE
in [Matlab]
|
Prev: draw a game board
Next: Posting Code to Matlab Central
From: Derek O'Connor on 11 Apr 2010 13:41 "Bruno Luong" <b.luong(a)fogale.findmycountry> wrote in message <hppd8c$36q$1(a)fred.mathworks.com>... --- snip -- > 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 I agree with Bruno. For me the greatest deficiency in Matlab is the lack of SINGLE floats, and various types of integers. It may be time to move on, or back to C or Fortran. Derek ("Make Mine a Single") O'Connor
From: Honglei Chen on 13 Apr 2010 18:00 Hi Bruno, We take backwards compatibility very seriously. In releases prior to R2010a, sgolayfilt() and other functions in Signal Processing Toolbox returned a double precision output even when the input was single precision. If you expected to save memory you probably wanted single inputs to produce single outputs. We had concerns that that this implicit cast (single in, double out) would be unexpected. Since this function never really supported single precision we opted to check for input data types and error out instead of returning what might be considered a silent wrong answer in case of single data type inputs. If you used to pass single precision inputs to sgolayfilt(), the best workaround is to explicitly cast these inputs to double (e.g. sgolayfilt(double(x),k,f) where x was single). You can also cast the output to single if there is no further downstream processing or if the code supports single data types. With explicit casts, your code will work the same way before and after R2010a. You are correct that starting from version 6.13 (R2010a), Signal Processing Toolbox supports single data type in dfilt objects. Notice however that the single precision support is limited to these objects. In general, Signal Processing Toolbox functions only support the double data type. Sorry to hear the last upgrade has caused you some pain. HTH, Honglei Bruno Luong wrote: > 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: dpb on 13 Apr 2010 22:01
Jan Simon wrote: .... > I also defend the use of Matlab for our software for clinical decision > making --- ... > ... 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. You probably drove a very quiver into TMW legals, there, Jan... :) I've not read it recently, but I'd be quite surprised if the licensing information doesn't have specific disclaimers and all for such "critical use" applications as medical, air flight control (and probably automotive now given the propensity there), nuclear design, etc., etc., etc., ... When in the commercial nuclear design arena I always thought it a little odd that the tools had such limitations on them by the vendors but there was no alternative (and still isn't for the most part) unless a vendor/researcher were to write all their own toolsets from scratch as well. Of course the likelihood of that toolset being any less buggy than the commercial compiler would likely be indetectable from zero to the first approximation and probably more so as a practical matter. A disadvantage I see w/ Matlab and similar products is that being proprietary there is not a broader Standards group that can add some stability and balance to the progression process which makes breaks in backward compatibility more difficult anyway, even if not entirely removing them. This, of course, is a double-edged sword in that standards take much longer to get revisions into and therefore lag and mean less rapid innovation. OTOH, w/ a Standard body there is at least an opportunity to comment before final acceptance on particularly sore points even if one doesn't have the wherewithal to actually participate. And, once there is an actual Standard, then the vendors have reason to comply and users have recourse to expect both compliance and bug fixes when found. In other languages w/ Standards, there are, of course, vendor extensions but at least there is a core basis that is pretty much immutable. If a Standard does devolve sufficiently from some requisite form, one can in that environment also choose to continue to stay within the previous Standard and generally there are toolsets that conform although they may also eventually be sunsetted by vendors. But, of course, all that is simply an essay... -- |