Array analysis error for constant float tuple creation

Reporting a bug

• I have tried using the latest released version of Numba (most recent is visible in the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
• I have included below a minimal working reproducer (if you are unsure how to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

Minimal example:

import numba

@numba.njit(parallel=True)
def f():
    a = (1.2, 1.3)
    return a[0]

f()

  File "/Users/ehsan/dev/numba/numba/parfors/parfor.py", line 2708, in run
    self._pre_run()
  File "/Users/ehsan/dev/numba/numba/parfors/parfor.py", line 2700, in _pre_run
    self.array_analysis.run(self.func_ir.blocks)
  File "/Users/ehsan/dev/numba/numba/parfors/array_analysis.py", line 1119, in run
    self._run_on_blocks(topo_order, blocks, cfg, init_equiv_set)
  File "/Users/ehsan/dev/numba/numba/parfors/array_analysis.py", line 1139, in _run_on_blocks
    pending_transforms = self._determine_transform(
  File "/Users/ehsan/dev/numba/numba/parfors/array_analysis.py", line 1220, in _determine_transform
    pre, post = self._analyze_inst(
  File "/Users/ehsan/dev/numba/numba/parfors/array_analysis.py", line 1337, in _analyze_inst
    needs_define = equiv_set.insert_equiv(lhs, shape)
  File "/Users/ehsan/dev/numba/numba/parfors/array_analysis.py", line 518, in insert_equiv
    obj_names = [self._get_names(x) for x in objs]
  File "/Users/ehsan/dev/numba/numba/parfors/array_analysis.py", line 518, in <listcomp>
    obj_names = [self._get_names(x) for x in objs]
  File "/Users/ehsan/dev/numba/numba/parfors/array_analysis.py", line 431, in _get_names
    raise NotImplementedError(
NotImplementedError: Failed in nopython mode pipeline (step: convert to parfors)
ShapeEquivSet does not support 1.2

[njriasan]

whether equivalence across inexact types is desirable or useful is another matter?

I spoke to @ehsantn regarding this. I can’t speak to other possible usage, but our concern is simply that it doesn’t compile and not that we need to track tuples of floats. @stuartarchibald I assume this has been deprioritized, so I will make sure someone from Bodo picks up this issue.

[stuartarchibald]

@DrTodd13

It will make the error go away perhaps but why would we ever need to track tuples of floats for the purpose of determining if two array dimensions are equivalent?

Quite 😃 This is why I was considering whether this is useful or desirable, couldn’t come up with a use case for it but wasn’t sure if I was missing something.

We just wouldn’t form a shape equiv entry for non-int parts of tuples and also wouldn’t throw an error either. Does that make sense? Do you want to take a stab or you want me to still look into it?

This makes sense if there’s no conditions that exist for it. I think ShapeEquivSet._get_names needs to return () in such cases, I can take a look. Thanks for the input.