input fixes and docs #72
Conversation
|
This pull request introduces 1 alert when merging aa47e5b into 7daf290 - view on LGTM.com new alerts:
Comment posted by LGTM.com |
docs/source/input_format.rst
Outdated
| >>> z.shape | ||
| (5, 2) | ||
|
|
||
| The main difference is that thousands of symbols in the form of unicode |
There was a problem hiding this comment.
Maybe explicitly say "In addition to standard characters, opt_einsum also supports unicode..." or the like?
| @@ -805,6 +805,9 @@ def contract_expression(subscripts, *shapes, **kwargs): | |||
| raise ValueError("'{}' should only be specified when calling a " | |||
| "`ContractExpression`, not when building it.".format(arg)) | |||
|
|
|||
| if not isinstance(subscripts, compat.strings): | |||
There was a problem hiding this comment.
Any reason why we just do not call parse_einsum_input here? It would be good, if possible to always parse the input at a single location. I think current parse_einsum_input does not yet support non-array like inputs such as tuples, but this should easy to correct I believe.
There was a problem hiding this comment.
So, it's just because contract_expression routes through contract and all its machinery once the shapes and constants are processed and thus parse_einsum_input will be called again anyway. The only reason convert_interleaved_input is needed here (which will then not be called again), is to simplify the constants processing.
One option might be have contract accept a tuple of the parsed inputs, or a is_parsed option or something, so that contract_expression could do the parsing and call contract with the guarantee that it is already parsed.
There was a problem hiding this comment.
It might be good to break out the inner contract loops at some point to make the actual iterations more flexible.
Description
Makes
contract_expressionaccept interleaved-style input (fixes #71) and adds general documentation on the input formats (resolves #70) following on from #67.Questions
Status