np.float64 attribute from host crashes compiler, broken error message #90

New Issue

sb10q · 2021-11-10T21:17:42+08:00

sb10q commented

2021-11-10 21:17:42 +08:00

Sometimes code using numpy ends up with a numpy.float64 type instead of float. If such a value is used as a KernelInvariant, nac3 breaks.

Repro:

from numpy import float64
from min_artiq import *

@nac3
class Demo:
    core: KernelInvariant[Core]
    foo: KernelInvariant[float]

    def __init__(self):
        self.core = Core()
        self.foo = float64(2.3)

    @kernel
    def run(self):
        pass


if __name__ == "__main__":
    Demo().run()

results in:

thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: "unknown identifier base (use before def?) at line 2 column 5"', nac3artiq/src/lib.rs:378:44

Sometimes code using numpy ends up with a ``numpy.float64`` type instead of ``float``. If such a value is used as a KernelInvariant, nac3 breaks. Repro: ```python from numpy import float64 from min_artiq import * @nac3 class Demo: core: KernelInvariant[Core] foo: KernelInvariant[float] def __init__(self): self.core = Core() self.foo = float64(2.3) @kernel def run(self): pass if __name__ == "__main__": Demo().run() ``` results in: ``` thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: "unknown identifier base (use before def?) at line 2 column 5"', nac3artiq/src/lib.rs:378:44 ```

sb10q changed title from ~~np.float64 KernelInvariant crashes compiler, broken error message~~ to np.float64 attribute from host crashes compiler, broken error message

2021-11-10 21:18:05 +08:00

sb10q commented

2021-11-10 21:18:24 +08:00

Poster

Does not need to be KernelInvariant, foo: float causes the same behavior.

Does not need to be ``KernelInvariant``, ``foo: float`` causes the same behavior.

pca006132 commented

2021-11-11 13:19:37 +08:00

I guess this is because symbol resolver fails to resolve the type, it should break as this is not intended, we can support float64. The error message is interesting though.

sb10q commented

2021-11-11 13:22:49 +08:00

Poster

I wouldn't introduce a float64 type and its associated complexity... I propose:

investigating the funny error message, which may point to some latent bug in the compiler.
simply converting those host float64 objects to float when they arrive inside NAC3.
investigating what happens when incorrect/unsupported types are passed in those values, and making sure we have a good error message.

I wouldn't introduce a ``float64`` type and its associated complexity... I propose: 1. investigating the funny error message, which may point to some latent bug in the compiler. 2. simply converting those host ``float64`` objects to ``float`` when they arrive inside NAC3. 3. investigating what happens when incorrect/unsupported types are passed in those values, and making sure we have a good error message.

pca006132 commented

2021-11-11 13:24:09 +08:00

I wouldn't introduce a float64 type and its associated complexity... I propose:

investigating the funny error message, which may point to some latent bug in the compiler.

simply converting those host float64 objects to float when they arrive inside NAC3.

Actually floats are now f64, I mean we can convert numpy float64 into our float.

> I wouldn't introduce a ``float64`` type and its associated complexity... I propose: > 1. investigating the funny error message, which may point to some latent bug in the compiler. > 2. simply converting those host ``float64`` objects to ``float`` when they arrive inside NAC3. Actually floats are now f64, I mean we can convert numpy float64 into our float.

ychenfo commented

2021-11-11 13:38:46 +08:00

I think I have encountered the error message before, but not clear how to solve that in a good way for now, since we synthesize the starting point..

It is because we cannot get the type of base in our synthesized starting point of the code (symbol resolver cannot confirm that numpy.float is compatible with float at here when getting the type of base)

I think I have encountered the error message before, but not clear how to solve that in a good way for now, since we synthesize the starting point.. It is because we cannot get the type of `base` in our synthesized starting point of the code (symbol resolver cannot confirm that `numpy.float` is compatible with float at [here](https://git.m-labs.hk/M-Labs/nac3/src/branch/master/nac3artiq/src/symbol_resolver.rs#L147) when getting the type of `base`)

pca006132 commented

2021-11-11 13:43:15 +08:00

I think I have encountered the error message before, but not clear how to solve that in a good way for now, since we synthesize the starting point..

It is because we cannot get the type of base in our synthesized starting point of the code (symbol resolver cannot confirm that numpy.float is compatible with float at here when getting the type of base)

we can fix this simply by returning an error when we cannot get the value of base.

> I think I have encountered the error message before, but not clear how to solve that in a good way for now, since we synthesize the starting point.. > > It is because we cannot get the type of `base` in our synthesized starting point of the code (symbol resolver cannot confirm that `numpy.float` is compatible with float at [here](https://git.m-labs.hk/M-Labs/nac3/src/branch/master/nac3artiq/src/symbol_resolver.rs#L147) when getting the type of `base`) we can fix this simply by returning an error when we cannot get the value of `base`.

sb10q referenced this issue

2021-11-28 12:09:51 +08:00

poor error message when host attributes have incorrect type #116

pca006132 referenced this issue

2022-02-21 18:43:18 +08:00

Better error messages #195

sb10q commented

2022-02-28 10:57:51 +08:00

Poster

The error message is okay now.

nac3artiq.CompileError: type error inside object launching kernel: error when getting type of field `foo` (<class 'numpy.float64'> is not supported in nac3 (did you forgot to put @nac3 annotation?))

We should simply treat the special case of np.float64 as float I guess.

The error message is okay now. ``` nac3artiq.CompileError: type error inside object launching kernel: error when getting type of field `foo` (<class 'numpy.float64'> is not supported in nac3 (did you forgot to put @nac3 annotation?)) ``` We should simply treat the special case of ``np.float64`` as ``float`` I guess.

sb10q added this to the Alpha milestone 2022-04-12 09:43:11 +08:00

sb10q referenced this issue from a commit

2022-04-12 10:34:38 +08:00

nac3artiq: treat host numpy.float64 as float. Closes #90

sb10q closed this issue

2022-04-12 10:34:38 +08:00

Sign in to join this conversation.