M-Labs/nac3
M-Labs/nac3
8
1
Fork 12
Code Issues 98 Pull Requests 19 Releases Wiki Activity

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

New Issue
Closed
opened 2021-11-10 21:17:42 +08:00 by sb10q · 7 comments
sb10q commented 2021-11-10 21:17:42 +08:00
Owner
Copy Link

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
Author
Owner
Copy Link

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
Contributor
Copy Link

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.

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
Author
Owner
Copy Link

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.
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
Contributor
Copy Link

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.

> 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
Collaborator
Copy Link

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
Contributor
Copy Link

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 commented 2022-02-28 10:57:51 +08:00
Author
Owner
Copy Link

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 closed this issue 2022-04-12 10:34:38 +08:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels   
future-extension

   
high-priority

   
low-priority

   
UROP0622
No Label
future-extension
high-priority
low-priority
UROP0622
Milestone
Clear milestone
No items
No Milestone
Alpha
Assignees
Clear assignees
No Assignees
3 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#90
No description provided.
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?