From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: tomas@tuxteam.de Newsgroups: gmane.emacs.help Subject: Re: Check for redundancy Date: Thu, 25 Jun 2015 09:47:41 +0200 Message-ID: <20150625074741.GA32430@tuxteam.de> References: <558A7875.4050905@easy-emacs.de> <24a1b328-82a8-44ff-8f8d-1425ab89ab67@default> <20150624211049.GA14854@tuxteam.de> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-action=pgp-signed X-Trace: ger.gmane.org 1435218497 1250 80.91.229.3 (25 Jun 2015 07:48:17 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 25 Jun 2015 07:48:17 +0000 (UTC) Cc: help-gnu-emacs@gnu.org To: Stefan Monnier Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Thu Jun 25 09:48:07 2015 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Z81tG-0002zc-Vx for geh-help-gnu-emacs@m.gmane.org; Thu, 25 Jun 2015 09:48:07 +0200 Original-Received: from localhost ([::1]:54303 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z81tG-0004jX-BA for geh-help-gnu-emacs@m.gmane.org; Thu, 25 Jun 2015 03:48:06 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50172) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z81t0-0004fM-LJ for help-gnu-emacs@gnu.org; Thu, 25 Jun 2015 03:47:51 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z81sw-0006sc-Cc for help-gnu-emacs@gnu.org; Thu, 25 Jun 2015 03:47:50 -0400 Original-Received: from mail.tuxteam.de ([5.199.139.25]:38820 helo=tomasium.tuxteam.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z81sw-0006rJ-6t for help-gnu-emacs@gnu.org; Thu, 25 Jun 2015 03:47:46 -0400 Original-Received: from tomas by tomasium.tuxteam.de with local (Exim 4.80) (envelope-from ) id 1Z81sr-0008Vx-Ua; Thu, 25 Jun 2015 09:47:41 +0200 In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 5.199.139.25 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:105147 Archived-At: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, Jun 24, 2015 at 11:23:41PM -0400, Stefan Monnier wrote: > > To throw an unorthodox idea into the air, one could measure the compression > > ratio (e.g. with gzip) and relate it to the compression ratio of "known > > good" code (I know, I know... :-) > > Compressing a file does give you some information about the amount of > redundancy in that code, but that might not be the redundancy you care > about (e.g. using longer identifiers will give you higher compression > ratios, but that's usually not what's considered "redundancy in code"). > Also, it's not immediately clear how to go from this to finding the > actual redundancy. Yeah -- the thing was a bit tongue-in-cheek. Much of the redundancy is (as you noted) in the eye of the beholder, and this is what makes this discussion "interesting". You'd have to keep (as you say) the variable names out of the equation (or do you? *I* for one consider "hungarian notation" highly redundant -- let the type system cope with that, others may not). That said, I have seen this rough measure (gzip compression ratio) used as a rough "similarity measure": compress each file separately, slap both together and compress, and watch the reduction. For a first step in exploratory work, just to learn what one really wants to put into the term "redundancy you care about" it might be useful. regards - -- t -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlWLsh0ACgkQBcgs9XrR2kZDVwCfRyAPGKBVFtkWrm1BapWAPqcd q4AAnRe8hLtPYhLzesXveBuvcJcDlolj =YpFU -----END PGP SIGNATURE-----