[FFmpeg-cvslog] r14218 - trunk/libavcodec/ra288.c

[Vitor Sessak]

M?ns Rullg?rd wrote:
> Vitor Sessak wrote:
>> M?ns Rullg?rd wrote:
>>> Vitor Sessak wrote:
>>>> Reimar D?ffinger wrote:
>>>>> Hello,
>>>>> On Sun, Jul 13, 2008 at 10:41:09PM +0200, vitor wrote:
>>>>>> Author: vitor
>>>>>> Date: Sun Jul 13 22:41:09 2008
>>>>>> New Revision: 14218
>>>>>>
>>>>>> Log:
>>>>>> Simplify
>>>>>>
>>>>>> Modified:
>>>>>>    trunk/libavcodec/ra288.c
>>>>>>
>>>>>> Modified: trunk/libavcodec/ra288.c
>>>>>> ==============================================================================
>>>>>> --- trunk/libavcodec/ra288.c	(original)
>>>>>> +++ trunk/libavcodec/ra288.c	Sun Jul 13 22:41:09 2008
>>>>>> @@ -69,9 +69,7 @@ static void decode(Real288_internal *glo
>>>>>>      for (x=0; x < 5; x++)
>>>>>>          buffer[x] = codetable[cb_coef][x] * sumsum;
>>>>>>
>>>>>> -    sum = scalar_product_float(buffer, buffer, 5) / 5;
>>>>>> -
>>>>>> -    sum = FFMAX(sum, 1);
>>>>>> +    sum = FFMAX(1, scalar_product_float(buffer, buffer, 5) / 5);
>>>>> Personally I think this is more an obfuscation than a simplification,
>>>> This is a matter of taste. I, personally, hate the construction "var =
>>>> fct(var);".
>>> What's the alternative?  A new operator, perhaps:
>>>
>>>   var ()= fct;
>> You missed my point.
> 
> No, I think you missed mine ;-)
> 
>> I'm fine with "var1 = fct(var2);". What I don't
>> like is when var1 is the same as var2. The reason is that normally the
>> output of a function is something conceptually different than it's
>> input, so it can be confusing to put in the same var. For example (out
>> of my mind, I've never saw such code):
> 
> Well, in the case of max(), input and output are both numbers.  Hence,
> no problem.

Yes, but I mean conceptually different. "clipped dot-product" != "dot 
product" even if both are numbers.

>>> int rms = sum_squares(vect);
>>>
>>> (a lot of code)
>>>
>>> rms = sqrt(rms);
>>>
>>> (more code)
>>>
>>> rms = rms_table[rms];
>>>
>>> return rms;
>> But I also do not like defining useless variables, so I try a compromise.
> 
> I believe what you're saying is that you'd prefer a more strongly
> typed language.

No! Making a thousand of "typedef type_xxx_t int16_t;" is very, very 
ugly!! And I think such things should be decided by the programmer 
(often it is not worth the trouble), not enforced by the compiler...

>>> And linked lists can be improved too.  Just replace all those ugly
>>>
>>>   item = item->next;
>> This one I like. item->next is an item too.
> 
> It could be an index.  I've coded such linked lists.
> 
> I probably should have used more smileys in the previous email,
> so here are some extra: ;-) :-] 8-} :-{)

Sorry, I'm a bit too serious these days... Vacations approaching, maybe ;-)

-Vitor