[GRASS-dev] Re: i.modis.qc

[Yann Chemin]

My apologies,

It should indeed be pixel in the bitshift and after Glynn comment (>>=):

    pixel >>= 2;                /*bits [2-3] become [0-1] */

and not:

    qctemp >> 2;                /*bits [2-3] become [0-1] */

I'll see through this.
Yann


---------- Forwarded message ----------
From: Yann Chemin <yann.chemin at gmail.com>
Date: 2008/10/27
Subject: Re: [GRASS-dev] Re: i.modis.qc
To: Paul Kelly <paul-grass at stjohnspoint.co.uk>
Cc: Glynn Clements <glynn at gclements.plus.com>, GRASS developers list
<grass-dev at lists.osgeo.org>


Hi Paul,

Thanks for your comments.
I go back to the code and to the books then.

Yann

2008/10/27 Paul Kelly <paul-grass at stjohnspoint.co.uk>:
> Hi Yann,
> Thought I would comment too so you know it is not just Glynn who sees there
> is a problem here.
>
> On Mon, 27 Oct 2008, Yann Chemin wrote:
>
>> Hello Glynn,
>>
>> since I rewrote the code, and tested it, I know quite much what I do
>> with the bitshifts, the image input, and the classification resulting
>> from bitshifts.
>>
>> I have not seen so far any need to >>= instead of >>, in any of the
>> related code I read.
>
> Well, it is not in doubt that the statement with the bit shift does not do
> anything and has no effect. So if you feel it works OK the way it is then
> that statement can be safely removed with no effect.
>
>> My worry in this email below was that a non-Unix platform compiler
>> (which I don't have) would cough on it for some unknown reason to me.
>
> Whether or not there is a warning is a moot point (apart from the fact that
> because we're only finding this bug because of a warning, it suggests there
> could be other undiscovered bugs in the code that aren't generating
> warnings). Anyway as Glynn said, the point is that a statement like qctemp
>>> 2;
> does not do anything. qctemp is not modified as a result; the bit-shifted
> value theoretically exists in the ether for an instant, but it is not
> assigned to anything so it is lost again instantly. That statement can be
> removed from the program and the output will be exactly the same.
>
>> As I can imagine, the compiler would find strange there is no variable
>> data allocation in a line of code, but I would expect it to understand
>> the unique feature of bitshift too.
>
> What do you mean? Bitshift doesn't have a unique feature; it works just like
> any other operator like + or - or | or &.
>
> Paul
>



--
Yann Chemin
International Rice Research Institute
Office: http://www.irri.org/gis
Perso: http://www.freewebs.com/ychemin
YiKingDo: http://yikingdo.unblog.fr/



-- 
Yann Chemin
International Rice Research Institute
Office: http://www.irri.org/gis
Perso: http://www.freewebs.com/ychemin
YiKingDo: http://yikingdo.unblog.fr/