Type inference for kernel invariants #13

New Issue

pca006132 · 2021-06-07T10:45:25+08:00

pca006132 commented

2021-06-07 10:45:25 +08:00

Kernel invariant / immutable lists is actually something that is used for iterating over items in kernels. Often with a lists of primitives, objects (e.g. devices), or functions. These could be converted to numpy arrays if those are still allowed to be kernel invariant / immutable.

It seems that the type of the tuples/lists in the kernel invariants may be complicated for such usage. It may be helpful for us to infer the type of the kernel invariants instead of requiring the users to write it. For example:

@kernel
class Foo(EnvExperiment):
    devices: KernelInvariant
    functions: KernelInvariant

    def __init__(self):
        devices = [self.get_device(f'ttl{i}') for i in range(4)]
        self.devices = tuple(devices)
        self.functions = tuple([self.foo, self.bar, self.bar, self.foo])
        
    @kernel
    def run(self) -> None:
        for d in self.devices:
            d.pulse(10*us)
        for fn in self.functions:
            fn()
            
    @kernel
    def foo(self) -> None:
        self.devices[0].pulse(10*us)
        
    @kernel
    def bar(self) -> None:
        self.devices[3].pulse(20*us)

However, this may force us to defer the type checking and code generation until the kernel instance is built...

As mentioned in https://git.m-labs.hk/M-Labs/nac3-spec/issues/5#issuecomment-2026: > Kernel invariant / immutable lists is actually something that is used for iterating over items in kernels. Often with a lists of primitives, objects (e.g. devices), or functions. These could be converted to numpy arrays if those are still allowed to be kernel invariant / immutable. It seems that the type of the tuples/lists in the kernel invariants may be complicated for such usage. It may be helpful for us to infer the type of the kernel invariants instead of requiring the users to write it. For example: ```python @kernel class Foo(EnvExperiment): devices: KernelInvariant functions: KernelInvariant def __init__(self): devices = [self.get_device(f'ttl{i}') for i in range(4)] self.devices = tuple(devices) self.functions = tuple([self.foo, self.bar, self.bar, self.foo]) @kernel def run(self) -> None: for d in self.devices: d.pulse(10*us) for fn in self.functions: fn() @kernel def foo(self) -> None: self.devices[0].pulse(10*us) @kernel def bar(self) -> None: self.devices[3].pulse(20*us) ``` However, this may force us to defer the type checking and code generation until the kernel instance is built...

pca006132 commented

2021-06-07 10:46:35 +08:00

Btw, do users prefer to use numpy.ndarray for a list of objects? Just wondering what is the benefit of it comparing to a typical list.

Btw, do users prefer to use `numpy.ndarray` for a list of objects? Just wondering what is the benefit of it comparing to a typical list.

sb10q commented

2021-06-07 10:47:05 +08:00

Btw, do users prefer to use numpy.ndarray for a list of objects?

No.

> Btw, do users prefer to use numpy.ndarray for a list of objects? No.

sb10q commented

2021-06-07 10:54:07 +08:00

It seems that the type of the tuples/lists in the kernel invariants may be complicated for such usage

Let's keep the compiler simple, explicit and consistent. It's rather weird that type annotations would magically disappear when KernelInvariant is used, and it also goes against the goals of simplicity and explicitness.

KernelInvariant(Tuple[TTLOut]) seems fine to me, as well as KernelInvariant(Tuple[Callable[None]]).

> It seems that the type of the tuples/lists in the kernel invariants may be complicated for such usage Let's keep the compiler simple, explicit and consistent. It's rather weird that type annotations would magically disappear when ``KernelInvariant`` is used, and it also goes against the goals of simplicity and explicitness. ``KernelInvariant(Tuple[TTLOut])`` seems fine to me, as well as ``KernelInvariant(Tuple[Callable[None]])``.

👍 1

pca006132 closed this issue

2021-06-07 10:55:53 +08:00

Sign in to join this conversation.

No Label

No Milestone

No Assignees

2 Participants

Notifications

Due Date

The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: M-Labs/nac3-spec#13