In files bbox.cpp and bsphere.cpp there is unnecessary conversion from int to
float for multiplication value by 1.5 and then it is converted back for
assignement to the same int variable. I'm talking about:

bbox.cpp:
  maxfinitecount = 1.5 * maxfinitecount;

bsphere.cpp:
  maxelements = 1.5 * maxelements;

It is possible that some C++ compilers perform such operations completly on
ints but I doubt it is part of C++ standard or component of being not
outdated. The same written as

bbox.cpp:
  maxfinitecount += maxfinitecount / 2;

bsphere.cpp:
  maxelements += maxelements / 2;

where '/2' on ints is often calculated using bits operations seems useful.
I'm reposting it here becouse it seems not ordinary 'warning free' issue.

ABX

Post a reply to this message

In article <o5na3v0s4oa527db5bp2229mqkaolse3p4@4ax.com> , ABX 
<abx### [at] abxartpl>  wrote:

> In files bbox.cpp and bsphere.cpp there is unnecessary conversion from int to
> float for multiplication value by 1.5 and then it is converted back for
> assignement to the same int variable. I'm talking about:

IIRC this code is in the sorting part of bounding and not speed critical.
Whenever possible readability should be given preference for non-critical
code.

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

"ABX" <abx### [at] abxartpl> wrote:
>
> bbox.cpp:
>   maxfinitecount += maxfinitecount / 2;
>
> bsphere.cpp:
>   maxelements += maxelements / 2;
>
> where '/2' on ints is often calculated using bits operations seems useful.

Not in this case. '/2' and '>>1' are only equivalent for unsigned values
(although this can also be applied to signed variables known [by the
compiler] to contain positive values).

Post a reply to this message

"Thorsten Froehlich" <tho### [at] trfde> wrote:
>
> IIRC this code is in the sorting part of bounding and not speed
> critical. Whenever possible readability should be given preference
> for non-critical code.

'maxfinitecount = maxfinitecount * 3 / 2' seems to be a viable alternative
(equally [if not better] readable and more efficient).

Post a reply to this message

Vadim Sytnikov <syt### [at] rucom> wrote:
> Not in this case. '/2' and '>>1' are only equivalent for unsigned values
> (although this can also be applied to signed variables known [by the
> compiler] to contain positive values).

  The compiler will always generate a shift opcode for integer/2, regardless
of whether 'integer' is signed or unsigned. Processors have two kinds of
shift right opcode for this.
  IIRC, this applies to integer>>1 as well. Thus they are completely
equivalent.

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

"Warp" <war### [at] tagpovrayorg> wrote:
>
>   The compiler will always generate a shift opcode for integer/2,
> regardless of whether 'integer' is signed or unsigned. Processors
> have two kinds of shift right opcode for this.
>   IIRC, this applies to integer>>1 as well. Thus they are
> completely equivalent.

Well, they are *not* equivalent.

The thing is that -1/2 ("minus one divided by two") is 0, while -1>>1
("minus one shifted right by one") is still -1. That's that problem that
compilers have to resolve somehow. One of the solutions is to add 1 to
negative numbers right before the shift, so truly equivalent code would look
like this:

  n / 2  <==> (n >= 0? n: n + 1) >> 1

These two expressions yield equivalent results, indeed. Of course, any
comparisons would be way too expensive to be used in practice...
Fortunately, most instruction sets have some tricks/workarounds for the
problem. For instance, here is what an x86 32-bit back-end generates for a
signed integer division by 2 of the operand loaded into 'eax':

  cdq
  sub eax, edx
  sar eax, 1

The first instruction fills 'edx' with -1 if 'eax' is negative, or with 0
otherwise. Therefore, the second instruction adds 1 in the former case, or
does nothing in the latter. Finally, the third instruction does the division
by 2 itself.

Post a reply to this message

In article <3e36ba51@news.povray.org> , "Vadim Sytnikov" <syt### [at] rucom>
wrote:

>>   The compiler will always generate a shift opcode for integer/2,
>> regardless of whether 'integer' is signed or unsigned. Processors
>> have two kinds of shift right opcode for this.
>>   IIRC, this applies to integer>>1 as well. Thus they are
>> completely equivalent.
>
> Well, they are *not* equivalent.

They are equivalent in the sense Warp means it also he didn't put it very
well in what sense he means it :-)

There are logical and arithmetic shift instructions which work for signed
and unsigned shifts no matter what direction.  No need to make a big fuss
about it ;-)

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

"Thorsten Froehlich" <tho### [at] trfde> wrote:
>
> > Well, they are *not* equivalent.
>
> They are equivalent in the sense Warp means it also he didn't put it very
> well in what sense he means it :-)

Likewise, they are not equivalent in the sense I mean it :-) What is
important is that one should exercise due caution when hand-optimizing such
code...

Post a reply to this message