Return-Path: <tiff-bounces@lists.maptools.org>
X-Original-To: info@awaresystems.be
Delivered-To: info@awaresystems.be
Received: from mx-a.b-one.net (mx-a.one.com [91.198.169.48])
	by mail9.b-one.net (Postfix) with ESMTP id 00BF7400164
	for <info@awaresystems.be>; Wed,  4 Nov 2009 17:07:39 +0100 (CET)
X-Virus-Scanned: by one.com
X-Spam-Score: 0
X-Spam-Level: 
X-Spam-Status: No, score=0 tagged_above=0 required=6 tests=[none]
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.4
Received: from lists.maptools.org (lists.maptools.org [65.39.174.144])
	by mx-a.b-one.net (Postfix) with ESMTP id 51E0E241
	for <info@awaresystems.be>; Wed,  4 Nov 2009 17:07:39 +0100 (CET)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
	by lists.maptools.org (Postfix) with ESMTP id 840C21D279F57;
	Wed,  4 Nov 2009 11:06:01 -0500 (EST)
Received: from toronto2.smartgames.ca (toronto2.smartgames.ca [204.15.192.18])
	by lists.maptools.org (Postfix) with ESMTP id 3EA381D266928
	for <tiff@lists.maptools.org>; Wed,  4 Nov 2009 10:49:54 -0500 (EST)
Received: from [10.143.176.101] (unknown [10.143.176.101])
	by toronto2.smartgames.ca (Postfix) with ESMTP id 1D61B16C5A;
	Wed,  4 Nov 2009 10:50:25 -0500 (EST)
In-Reply-To: <20091104094511.9608685b.pullmoll@t-online.de>
References: <4AEF1C2D.9070907@cybox.com>
	<alpine.GSO.2.01.0911021231460.1964@freddy.simplesystems.org>
	<4AEF564F.9090305@cybox.com>
	<20091103111458.ead77a52.pullmoll@t-online.de>
	<5B235B19-97E3-4CED-B1F9-DF317CF1AD5A@telegraphics.com.au>
	<20091103204626.GA27306@pixar.com>
	<20091104094511.9608685b.pullmoll@t-online.de>
Mime-Version: 1.0 (Apple Message framework v753.1)
Message-Id: <06BC3635-A01E-4E26-98B3-9B70542C771B@telegraphics.com.au>
From: Toby Thain <toby@telegraphics.com.au>
Date: Wed, 4 Nov 2009 10:49:50 -0500
To: Juergen Buchmueller <pullmoll@t-online.de>
X-Mailer: Apple Mail (2.753.1)
Cc: tiff@lists.maptools.org
Subject: Re: [Tiff] Tiffcrop test suite and logluv issues
X-BeenThere: tiff@lists.maptools.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TIFF and libtiff discussion <tiff.lists.maptools.org>
List-Unsubscribe: <http://lists.maptools.org/mailman/listinfo/tiff>,
	<mailto:tiff-request@lists.maptools.org?subject=unsubscribe>
List-Archive: <http://lists.maptools.org/mailman/private/tiff>
List-Post: <mailto:tiff@lists.maptools.org>
List-Help: <mailto:tiff-request@lists.maptools.org?subject=help>
List-Subscribe: <http://lists.maptools.org/mailman/listinfo/tiff>,
	<mailto:tiff-request@lists.maptools.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: tiff-bounces@lists.maptools.org
Errors-To: tiff-bounces@lists.maptools.org


On 4-Nov-09, at 3:45 AM, Juergen Buchmueller wrote:

> On Tue, 3 Nov 2009 12:46:26 -0800
> Daniel McCoy <mccoy@pixar.com> wrote:
>
>> From Toby Thain <toby@telegraphics.com.au>, Tue, Nov 03, 2009 at  
>> 07:16:07AM -0500:
>>>>
>>>> Alternatively one could write:
>>>> 	tp[i] = 65536 * bp[0] + 256 * bp[1] + bp[2];
>>>>
>>>> Compilers today transform the power-of-two multiplications into  
>>>> rather
>>>> effective code (read: shift lefts) and it doesn't require parens.
>>>
>>> This adds to the cognitive load for humans. A shift shows the intent
>>> more clearly.
>>
>> True.
>> One way of reducing the cognitive load in the multiply version
>> is to use hex constants:
>>
>>  	tp[i] = 0x10000 * bp[0] + 0x100 * bp[1] + bp[2];
>>
>> which show the intent more clearly than the decimal constants.
>
> I don't agree, but that may be due to me recognizing powers of two in
> decimal just as well as in hex .. at least up to 2^20.

Sure, most of us can, but why depend on an *arbitrary* reader also  
having that ability when there are clearer ways of expressing it?  
(Multiplication by hex constant seems like one way, though I don't do  
this in my own code.)

*Unless* the reader has memorised powers of binary like you, the  
function of decimal literals here are less clear, and should be  
avoided for maintainability reasons, imho (since we have the choice).  
Plus, shift is more expressive of the intent than multiply, imho.

>
> Here's a suggestion for the ambitious commenter:
>
> #define SHL24(x) 0x1000000*(x)
> #define SHL16(x) 0x10000*(x)
> #define SHL8(x) 0x100*(x)
>
> tp[i] = SHL16(bp[0]) + SHL8(bp[1]) + bp[2];

I don't find this clearer than bitshifts, in fact, hiding the  
operation in macros looks like obfuscation. (Plus for better  
documentation value, the macro/function could be on the "read 3 bytes  
BigEndian" level.)

If the putative reader cannot parse << 8 as "shift left 8 bits", then  
they are going to have bigger problems working in C. A "SHL8" macro  
won't save them.

But this digression is surely dead and buried by now...

--Toby

>
> ;-)
>
> Juergen
> _______________________________________________
> Tiff mailing list: Tiff@lists.maptools.org
> http://lists.maptools.org/mailman/listinfo/tiff
> http://www.remotesensing.org/libtiff/

_______________________________________________
Tiff mailing list: Tiff@lists.maptools.org
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/
