On Fri, 20 Mar 2009, Devin Heitmueller wrote: > On Thu, Mar 19, 2009 at 7:06 PM, Trent Piepho <xyzzy@xxxxxxxxxxxxx> wrote: > >> The argument being put forth is based on the relative efficiency of > >> the multiply versus divide opcodes on modern CPU architectures?? And > > > > Maybe I just like writing efficient code to do interesting things? > > Wow, um, ok. You realize that getting the SNR on most devices is > probably going to require an i2c call that is going to take a couple > hundred CPU instructions, not to mention I/O, right? And that you're > doing this in an expensive ioctl call? So perhaps a > micro-optimization with no visible gain, at the cost of readability > and complexity shouldn't be a overriding consideration? Did I submit a patch to modify dvb-apps? I just wanted to show how to convert fixed point numbers to IEEE 754 floating using only integer math. I think such things are interesting. > >> that you're going to be able to get an SNR with a higher level of > >> precision than 0.1 dB?? (if the hardware suggests that it can then > >> it's LYING to you) > > > > Not really. Absolute accuracy is not going to be that good of course. But > > the error measurements from which SNR is calculated do support precision of > > better than 0.1 dB. That precision does give you more power when fine > > tuning antenna position. > > > > Put another way, what advantage is there of less precision? > > Well, here is one disadvantage: The driver decides the SNR is 23.1. > So I convert that to your format: 0x1719. Then userland gets it back You've assumed the driver will find SNR in decimal fixed point. The lgdt demods and the oren demods all *start* with binary fixed point. So you have the opposite problem were converting to decimal fixed point changes the result. > and goes to display it. I'm going to show the user an SNR of > 23.09765625, and I have no way to know what the expected precision > (and thus I don't know where to round). So the end result is the user > sees a really stupid number in the GUI (and might actually think it is > more accurate than it really is). Or when I push patches to > applications I just round to 0.1dB anyway. It also means apps like > femon and zap are going to have to change to support a non-fixed width > result with no appreciable gain in value. Since 8 binary digits is 2.4 decimal digits, it's perfectly ok to display SNR with 3 fixed decimal digits. You could just as well round to 1 fixed decimal digit too, in which case you've got exactly what you'd get if you started with the decimal fixed point, except the extra precision is there for a situation where it is useful. > By saying explicitly there is one digit of precision - it allows for > applications to know how to round, and I continue to disagree with Binary fixed point says explicitly that there are 8 binary digits of precision. Decimal fixed point says there are 3.3219281 binary digits of precision. We stopped using BCD 30 years ago, computers do everything in binary now. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
