Add implicit scope to batch_permutation

[stiepan]

Category:

Bug fix /New feature (non-breaking change which adds functionality)

Description:

The PR makes the following code work.

batch =  fn.decoders.image(batch, device="mixed")
if fn.random.coin_flip():
        permuted_batch = fn.permute_batch(batch, indices=fn.batch_permutation())

Without it, the fn.permute_batch will fail due indicies exceeding the valid indicies for the batch in the inner scope.

Even though we call fn.batch_permutation() inside the if body, the operator will run as if it was called in the outer scope - that is it will produce a permutation for a full batch size. Then, that permutation will be split according to the fn.random.coin_flip() predicate.

Unfortunately, randomly splitting permutation in two smaller lists usually does not produce a valid permutations for smaller lists, i.e. while [3, 0, 2, 1] is a valid permutation of four elements, splitting it in two [3, 0], [2, 1] does not produce valid permutations of two elements.

The hoisting of fn.batch_permutation into an outer scope happens becuase the fn.batch_permutation does not accept any tensor arguments - those args serve as a source of the "local scope" batch size. This PR fixes the problem by introducing an implicit "_scope" argument that is automatically injected with a dummy batch whose size matches the local batch size.

Additional information:

Affected modules and functionalities:

• OpSchema - by introduction of HiddenOptional arguments.
• fn.batch_permutation - it now has new parent schema with the _scope arg.
• ops.py - code that automatically injects a referential scope to those operators that have the _scope argument.

A possible follow-up would be to use the same mechanism for any operator that can potentially have no other tensor arugments. For example random generators - in their case, hositing to global scope and then splitting the output does not impact the correctness, but may incur some performence penalty.

Key points relevant for the review:

Is it tested properly? Is the hidden _scope arg hidden in the docs? Anywhere else where you'd rather not see a hidden argument that I should check?

Tests:

• Existing tests apply
• New tests added
  • Python tests
  • GTests
  • Benchmark
  • Other
• N/A

Checklist

Documentation

• Existing documentation applies
• Documentation updated
  • Docstring
  • Doxygen
  • RST
  • Jupyter
  • Other
• N/A

DALI team only

Requirements

• Implements new requirements
• Affects existing requirements
• N/A

REQ IDs: N/A

JIRA TASK: DALI-3495

[stiepan]

!build

[dali-automaton]

CI MESSAGE: [10010511]: BUILD FAILED

[dali-automaton]

CI MESSAGE: [10016104]: BUILD STARTED

[dali-automaton]

CI MESSAGE: [10016104]: BUILD PASSED

[mzient]

In that case, why add functions AddHidden... instead of just hiding all arguments that start with _?

[stiepan]

Good point, I've changed it for an arg to be hidden iff its name starts with "_".

[mzient]

Suggested change

	.AddHiddenOptionalArg<int>("_scope", R"code(Any CPU batch to infer the current batch size from.
	.AddHiddenOptionalArg<int>("_scope", R"code(Any batch to infer the current batch size from.

That's just current limitation that we don't need to repeat here and may lift in the future.

[stiepan]

done

[stiepan]

!build

[dali-automaton]

CI MESSAGE: [10030396]: BUILD STARTED

[dali-automaton]

CI MESSAGE: [10030396]: BUILD FAILED

[mzient]

Can you move it inside the Schema class as a static function?
Also, the imperative name doesn't look like a boolean query.
Alternatives: ShouldHideArgument, ArgumentHidden, IsArgumentHidden or perhaps just IsHidden(const string &arg_name)

[stiepan]

good point

[stiepan]

!build

[dali-automaton]

CI MESSAGE: [10037057]: BUILD STARTED

[dali-automaton]

CI MESSAGE: [10030396]: BUILD PASSED

[dali-automaton]

CI MESSAGE: [10037057]: BUILD PASSED