TOSA Specification small discrepancies

TOSA
#1

Hello,
I noticed a couple of nitpicks on the Tosa spec(4fbb794a).

  • for CondIf and WhileLoop operators, Supported Data Types tables define cond_t field which doesn’t appear in argument definitions
  • the Variable operators mention some in_t/out_t fields in argument definitions, but they don’t appear in Supported Data Types tables, there is the var_t field which bears the same name as the enumeration defined at #3.3
  • for Gather the Supported Data Types table defines index_t,in_out_t, while for Scatter order is in_out_t,index_t
#2

Thanks for the feedback, these are good catches. Here’s what I think is the right fix to make things consistent, let me know if this sounds reasonable.

  • I think the right answer here is to not have a type in the table. The only part of the supported data types table would be that these are part of the EXT-CONTROLFLOW extension and there are no types required. For COND_IF, we could change the type of the condition to be T<cond_t>, but it isn’t a necessary indirection.
  • For VARIABLE and VARIABLE_WRITE, change var_t to in_t. For VARIABLE_READ, var_t becomes out_t. This also removes the conflict with the enum type.
  • Switch the order for scatter to be consistent with gather.
#3

Sounds good, thanks for the response.
Also found some typos:

  • CUSTOM domain_name argument “String idenifier which…”
  • RESIZE “Individual scale numerator and denominaor values…”, “Bilinear interpoloation”
  • #4.3. Operator Validation Helpers “This satifies tosa_test_compliance()”
#4

I’ve merged a fix here: https://review.mlplatform.org/c/tosa/specification/+/13861 that I think addresses all of the problems listed above. I should have had you take a look before merging, but feel free to let me know if there are remaining issues.

Thanks again for the feedback.

1 Like