Changes between Version 2 and Version 3 of Ticket #636, comment 7


Ignore:
Timestamp:
5 Nov 2019, 14:54:21 (4 years ago)
Author:
afilippov
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #636, comment 7

    v2 v3  
    11I think spec- and implementation-related questions are mixed up again.
    22
    3 Although there is an ''informative'' note in Section 5.1 that "the mathematical operators used in this Specification are '''''similar''''' to those used in the C programming language", I guess implementation-specific aspects of the C programming language are irrelevant to the VVC spec draft. Since the VVC spec draft clearly states that "only the externally observable output behaviour is required to conform to the specifications of this Recommendation | International Standard", it is enough for the spec to guarantee that output is always specified. Outputs of all the operations and the entire process described in Section 8.4.5.2.12 are well defined and unambiguous since the C programming language standard clearly defines that "the result of the binary * operator is the product of the operands". The output value of 0 * x is 0 for any x. Thus, output behaviour of {{{fT[ i ] * ref[ x + iIdx + i ]}}} is well defined for any value of ref[ x + iIdx +  i ] if fT[ i ] == 0. Since the expression {{{fT[ i ] * ref[ x + iIdx + i ]}}} is evaluated from left to right, it is absolutely unnecessary to refer to ref[ 18 ] in your example if the output value of {{{0 * ref[ x + iIdx + i ]}}} is known without ref[ x + iIdx + i ]. At least, I couldn't find any relevant constraints / requirement in the VVC spec draft that could force a VVC spec reader to evaluate x in the expression 0 * x. Thus, I don't see any issues in the VVC spec draft with JVET-P0626 incorporated. By the way, using the expression {{{(fT[ i ] == 0) ? 0 : fT[ i ] * ref[ x + iIdx + i ]}}} in formulae (8-138) and (8-148) could exclude any misunderstandings if you see any.
     3Although there is an ''informative'' note in Section 5.1 that "the mathematical operators used in this Specification are '''''similar''''' to those used in the C programming language", I guess implementation-related aspects of the C programming language are irrelevant to the VVC spec draft. Since the VVC spec draft clearly states that "only the externally observable output behaviour is required to conform to the specifications of this Recommendation | International Standard", it is enough for the spec to guarantee that output is always specified. Outputs of all the operations and the entire process described in Section 8.4.5.2.12 are well defined and unambiguous since the C programming language standard clearly defines that "the result of the binary * operator is the product of the operands". The output value of 0 * x is 0 for any x. Thus, output behaviour of {{{fT[ i ] * ref[ x + iIdx + i ]}}} is well defined for any value of ref[ x + iIdx +  i ] if fT[ i ] == 0. Since the expression {{{fT[ i ] * ref[ x + iIdx + i ]}}} is evaluated from left to right, it is absolutely unnecessary to refer to ref[ 18 ] in your example if the output value of {{{0 * ref[ x + iIdx + i ]}}} is known without ref[ x + iIdx + i ]. At least, I couldn't find any relevant constraints / requirement in the VVC spec draft that could force a VVC spec reader to evaluate x in the expression 0 * x. Thus, I don't see any issues in the VVC spec draft with JVET-P0626 incorporated. By the way, using the expression {{{(fT[ i ] == 0) ? 0 : fT[ i ] * ref[ x + iIdx + i ]}}} in formulae (8-138) and (8-148) could exclude any misunderstandings if you see any.
    44
    55On the other hand, the version of the VVC spec draft before incorporating JVET-P0626 restricted implementation freedom as the value of the reference sample ref[ refW + refIdx + ( Max( 1, nTbW / nTbH ) * refIdx + 2 ] was set to p[ −1 + refW ][ −1 − refIdx ] although ref[ refW + refIdx + ( Max( 1, nTbW / nTbH ) * refIdx + 2 ] can actually take an arbitrary value. Undoubtedly, the result of multiplying 0 by ref[ refW + refIdx + ( Max( 1, nTbW / nTbH ) * refIdx + 2 ] is much more obvious for VVC spec readers than the fact that assigning p[ −1 + refW ][ −1 − refIdx ] to the reference sample ref[ refW + refIdx + ( Max( 1, nTbW / nTbH ) * refIdx + 2 ] is actually optional although this operation is prescribed by the spec.