Return-path: Received: from mail.deathmatch.net ([72.66.92.28]:2105 "EHLO mail.deathmatch.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757161Ab0KSWoK (ORCPT ); Fri, 19 Nov 2010 17:44:10 -0500 Date: Fri, 19 Nov 2010 17:28:46 -0500 From: Bob Copeland To: Bruno Randolf Cc: Johannes Berg , Jouni Malinen , linville@tuxdriver.com, randy.dunlap@oracle.com, peterz@infradead.org, blp@cs.stanford.edu, linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org, Lars_Ericsson@telia.com, stefanr@s5r6.in-berlin.de, kosaki.motohiro@jp.fujitsu.com, akpm@linux-foundation.org, kevin.granade@gmail.com Subject: Re: [PATCH v7 3/3] nl80211/mac80211: Report signal average Message-ID: <20101119222846.GA26592@hash.localnet> References: <20101112024901.28522.21895.stgit@localhost6.localdomain6> <1290010595.3777.0.camel@jlt3.sipsolutions.net> <201011191807.06013.br1@einfach.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <201011191807.06013.br1@einfach.org> Sender: linux-wireless-owner@vger.kernel.org List-ID: On Fri, Nov 19, 2010 at 06:07:05PM +0900, Bruno Randolf wrote: > Hmm, maybe I suck in mathemathics, but I don't see a way to do that given the > formula: > > (((internal * (weight - 1)) + (val * factor)) / weight I was thinking something along the lines of: round = (1 << n) - 1; (((internal * (weight - 1) + round) >> n) + val) * ((1 << n) / weight) where (1 << n) is the factor and ((1 << n) / weight) can be precomputed. If you think about it, this is just reciprocal multiplication in fixed- point math with n bits of decimal resolution. The problem is the shift of the older terms introduces roundoff error, but there are some tricks you can do to maintain bounded error, e.g. shifting by some smaller factor of n and scaling other terms -- in the limit you reinvent floating point and then it's slower than division :) -- Bob Copeland %% www.bobcopeland.com