'int' object has no attribute 'item' on conv shapes calculation about nir

[stevenabreu7]

Hi there, thanks a lot for catching this! Could you add a simple test input that gives you this failure? And is the shape variable a list, or a single int? I don't immediately see why it would be a list, since we make sure that it would be a np.array here:

NIR/nir/ir/utils.py

Line 100 in df2f1fc

return np.array([tuple])

[chanokin]

I just looked again and the input_shape type is no int nor list nor tuple it's a lovely torch.Size type. I would have thought that type would get bundled with the Sequence type in Line 91?

I think this comes from

NIR/nir/ir/utils.py

Line 53 in df2f1fc

shape = input_shape[i]

when padding == "same" and there is no conversion to np.array([input_shape[i]])

[stevenabreu7]

I made a PR to fix this, see #101, could you please confirm that it works for you now? Then I will merge it. Thanks again for your help!

[chanokin]

Hi, sadly, it's still no good.

Here's a minimal test

from nir.ir.graph import NIRGraph
from nir.ir.conv import Conv2d
from nir.ir.neuron import LI

import torch


def test_nir_conv2d_same():
    # Create a NIR Network
    conv_weights = torch.tensor([[[1.0, 1.0, 1.0], [1.0, 1.0, 1.0], [1.0, 1.0, 1.0]]])
    li_tau = torch.tensor([0.9, 0.8])
    li_r = torch.tensor([1.0, 1.0])
    li_v_leak = torch.tensor([0.0, 0.0])

    nir_network = NIRGraph.from_list(
        Conv2d(
            input_shape=torch.Size((3, 3)),
            weight=conv_weights,
            stride=1,
            padding="same",
            dilation=1,
            groups=1,
            bias=torch.tensor([0.0] * 9),
        ),
        LI(li_tau, li_r, li_v_leak),
    )

I think that's because _index_tuple still returns a pure int in

NIR/nir/ir/utils.py

Lines 97 to 98 in df2f1fc

	if isinstance(tuple, np.ndarray) or isinstance(tuple, Sequence):
	return tuple[index]

I don't know what the design phylosophy is here but I assume you could return a np.array([tuple[index]])

[Jegp]

Thank you so much for the insight @chanokin. You're indeed right that we should be returning a Numpy number. And there was an additional bug in that it assumed numpy types and not PyTorch arrays or the like. I expanded the function and added some tests to make sure it works.

Please don't hesitate to reopen if anything is broken. And ping us if you'd like a release. Otherwise, I'll wait a few weeks until the next exciting new features drop ;-)