| 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. |
| | 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-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. |
