[FFmpeg-cvslog] r21062 - trunk/libavcodec/h263.c

Diego Biurrun diego
Fri Jan 8 01:38:24 CET 2010


On Fri, Jan 08, 2010 at 01:11:58AM +0100, Michael Niedermayer wrote:
> On Thu, Jan 07, 2010 at 10:46:17PM +0100, Diego Biurrun wrote:
> > On Thu, Jan 07, 2010 at 04:31:54PM +0100, michael wrote:
> > > 
> > > Log:
> > > Move restore_ac_coeffs() call into decode_ac_pred(), this makes later behave
> > > more understandable.
> > 
> > I assume you meant "behavior" there?
> 
> I meant that the second function behaves more understandable after the patch.
> I see nothing wrong with what i wrote though, am i missing something?

You said (grammar mistakes more or less conserved)

  Verschiebe den Aufruf von restore_ac_coeffs() in decode_ac_pred(),
  das macht sp?ter verh?lt sich einfacher zu verstehen.

from which I guessed

  Verschiebe den Aufruf von restore_ac_coeffs() in decode_ac_pred(),
  das macht sp?teres Verhalten einfacher zu verstehen.

instead of

  Verschiebe den Aufruf von restore_ac_coeffs() in decode_ac_pred(),
  das macht letztere Funktion einfacher zu verstehen.

Be careful, English has a very low Hamming distance between words:

      later  == sp?ter
(the) latter == letztere[rs]

You make this mistake quite often and unfortunately it has this
propensity to create confusion, as it did now.

I fixed the message:

  Move restore_ac_coeffs() call into decode_ac_pred().
  This makes the latter function easier to understand.

But probably

  Move restore_ac_coeffs() call into decode_ac_pred().
  This makes decode_ac_pred() easier to understand.

is both simpler to write and easier to understand.

So you see, writing good prose can be a lot like writing good code.
My last variant is (arguably) the simplest possible way to express
the thought :)

Diego



More information about the ffmpeg-cvslog mailing list