From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18508 invoked by alias); 3 Jan 2002 16:20:57 -0000 Mailing-List: contact sid-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: sid-owner@sources.redhat.com Received: (qmail 18412 invoked from network); 3 Jan 2002 16:20:52 -0000 Message-ID: <3C3484FA.8070708@redhat.com> Date: Thu, 03 Jan 2002 08:20:00 -0000 From: Dave Brolley User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 X-Accept-Language: en-us MIME-Version: 1.0 To: "Frank Ch. Eigler" CC: sid@sources.redhat.com, cgen@sources.redhat.com Subject: Re: [patch][rfa]: Decoding (not-so) ambiguous insns in sid/sim References: <3C3391D7.6050301.cygnus.project.sid@redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-q1/txt/msg00002.txt.bz2 Frank Ch. Eigler wrote: >brolley wrote: > >>[...] >> (list->vector >> (map (lambda (p0 p1) >> (logit 4 p0 "/" p1 " ") >>! ; (sqrt (+ p0 p1 (* p0 p1))) ; funny function - nice curve >>! (sqrt (* p0 p1))) ; geometric mean >> (vector->list 0-population) (vector->list 1-population)))) >> > >By the way, have you tried the "funny function" above? It would have >the property of separating the 0/0 and 0/N cases like your new >ordering function does, and is monotonic in p0 & p1, so it should not >change the relative order of existing decoders. > Yes, I considered the "funny function" but rejected it because it assigns a non-zero value in the case where a given bit must always be 1 or always 0, e.g. p0==num_insns,p1==0. Such a bit is useless for decoding purposes and is correctly assigned a value of zero both by the old function and by my new function. Can I consider your response to be approval to commit? What about "filter-harmlessly-ambiguous-insns"? Should I remove it from insn.scm? Dave