Add or document signature syntax for zero dimensional arrays

[cems2]

Problem Being addressed.

Numba has a text syntax for function signatures such as
'f8' or 'float32[:,:]'

However there is no simple text syntax for other arrays such as zero dimensional arrays

You can do this using a poorly documented alternative syntax of using explicit types in the signature rather than the simplified text string convention. For example
@nb.njit(nb.types.Array(nb.int64, 0, "C")())

Feature request

Add syntax for at least the Zero dimensional case since this is actually pretty common when using cuda. (because you can store scalars on the GPU if you make them zero dimensional arrays).

Here's a possible syntax that might be worth considering.

'float32[]' # empty brackets without any colons would imply zero dimensions

A final matter to consider would be if one wants to also worry about fortran versus C order arrays. My vote would be not to worry about that since it would complicate the syntax. But if you chose to do so then a possible ansatz would be to replace the ":" colon sigils with the letter F like this:

'float32[F,F]' # where F is the signal for a fortran order 2 D array

Note that zero and 1D arrays are identical in C and F

[stuartarchibald]

Thanks for the suggestion. Some background:

Essentially, the string syntax works by just evaluating the string using Python's eval with numba.types.__dict__ as globals, e.g. eval('f8()', numba.types.__dict__). The way e.g. float32[:, :] ends up as a types.Array(float32, 2, A) is through an overload of the __getitem__ syntax (and slice objects) on the numba.types.Type to instantiate the appropriate type, similarly, f8() ends up as Signature(float64, (), None) (repr: () -> float64) through an overload of the __call__ method on the numba.types.Type. As a result, because e.g. float32[] # empty brackets without any colons would imply zero dimensions is not valid Python syntax, it would not be possible to support this without having a parser to handle such cases.

All this said, some other syntax could be overloaded e.g. float32[0] could indicate a 0-d float32 array, and more generally a type[x] indicating a types.Array(type, x, "A") type. Something similar for Fortran/C ordering could be permitted too. The code in question is here, if you wanted to experiment:

numba/numba/types/abstract.py

Lines 175 to 204 in ccb5705

	def __getitem__(self, args):
	"""
	Return an array of this type.
	"""
	from . import Array
	ndim, layout = self._determine_array_spec(args)
	return Array(dtype=self, ndim=ndim, layout=layout)
	def _determine_array_spec(self, args):
	# XXX non-contiguous by default, even for 1d arrays,
	# doesn't sound very intuitive
	if isinstance(args, (tuple, list)):
	ndim = len(args)
	if args[0].step == 1:
	layout = 'F'
	elif args[-1].step == 1:
	layout = 'C'
	else:
	layout = 'A'
	elif isinstance(args, slice):
	ndim = 1
	if args.step == 1:
	layout = 'C'
	else:
	layout = 'A'
	else:
	ndim = 1
	layout = 'A'
	return ndim, layout

[cems2]

Hi. Sorry if I'm not supposed to write to you but we have corresponded on a couple of bugs I had submitted. I already asked a couple cuda experts like Alex Ford. Unsure of where to post Numba Cuda Questions in general (tried stackoverflow for this one already). What would cause a Numba Cuda kernel to do nothing but not return an error? Problem: My code runs fine with small threadblocks (16x8 or less) but Above a certain number of threads my call to the cuda kernel leaves the output array unmodified. Expected result: If it runs on a small block then it either runs on the large block or I get an error. Actual result: No error. But output array is unmodified (stays zero). Regression: 1. Doesn't depend on block shape or special block sizes. It's just block bigger than a certain size fail 2. When it runs the output is mathematically correct for a very complex calculation regardless of thread block 3. THe numba reported register count is less than 64 (usual 45 to 56 registers). Since this is an RTX 2070 the SM should support 64K registers and thus 1024 threads with a register count under 64. 4. If I do increase the register count intentionally above that limit I can cause an error. 5. if I break the code up into pieces each of them runs fine on large blocks. Suggesting something like a register issue but as noted no evidence of this. 6. I'm running it in Jupyter notebooks. It's very hard to run it outside of the notebook because of all the initializations. I may need to do this. But since I'm in the dark about what could do this without causing an error thats a desperation move.

[stuartarchibald]

@cems2 I would suggest opening a new issue, ideally with sample code demonstrating the problem, and someone will take a look (to get a faster response, also include a description of the hardware on which it is running). Sounds like it might be resource contention/exhaustion. You'll note in the issue tracker that there's a CUDA label and a lot of issues found under it https://github.com/numba/numba/issues?q=is%3Aissue+is%3Aopen+label%3ACUDA Thanks.