Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Data type confusion for ARTIQ Python #656

Closed
vontell opened this issue Jan 16, 2017 · 7 comments · Fixed by #2470
Closed

Data type confusion for ARTIQ Python #656

vontell opened this issue Jan 16, 2017 · 7 comments · Fixed by #2470

Comments

@vontell
Copy link

vontell commented Jan 16, 2017

Do parts of the ARTIQ codebase override or clear default Python types? For the most part I have been able to get around these issues, but now it has become a hassle. For instance, I am unable to use default Python arrays, dictionaries, and even some casting methods such as str. For example, when casting an integer into a string: fatal: name 'str' is not bound to anything

Issues like this occur when even creating dictionaries: fatal: name 'dict' is not bound to anything; did you mean 'int'? Finally, it seems that even Python arrays don't usually work in my environment: when setting a variable my_array = [], I am told that this object does not have functions such as append, pop, or push. I was just wondering if these types are overridden by one of the classes or packages in artiq.experiment. When testing in the Python interpreter, these methods still work even after importing artiq.experiment, so does is this a side effect of using the @kernel decoration?

@whitequark
Copy link
Contributor

whitequark commented Jan 16, 2017

You can think of the ARTIQ Python compiler to override all built-in types.

The ARTIQ Python language is a subset of Python proper for several good reasons.

First, the experiments must run in realtime. This all but excludes most data structures relying on heap allocation and reallocation, like dicts and extensible arrays, since ARTIQ Python has no heap. (Implementing a decent real-time garbage collector is an extremely complicated affair and the payoff for experiments isn't that big.)

Second, the experiments must not have runtime dispatch. This means that, for example, all elements of array must be the same type, and all instances of a class must contain an object of the same type in a given field.

That said, some things are missing simply because they haven't been implemented. Many operations (e.g. string concatenation) would be easy to implement. Others (e.g. string indexing) are unlikely to ever be added.

For your specific issues, I recommend:

  • Instead of dicts, you can use distinct classes.
  • Instead of performing string operations in the kernel, you can collect the data in the kernel, perhaps in tuples, and format them in the host Python code afterwards.
  • Instead of pushing into an array, pre-allocate the array for the maximum number of elements you expect with a list comprehension, i.e. x = [0 for _ in range(1024)], and then keep a variable noting the last filled element of an array. Afterwards, x[0:n] will give you a list with that number of elements.

@vontell
Copy link
Author

vontell commented Jan 17, 2017

Some of the tricks you have mentioned work great. I notice that tuples have no accessors on them (for instance, my_tuple[0] will throw an exception type is not iterable). Is this due to the fact that experiments must not have a runtime dispatch, and tuples are capable of holding values of different types?

Sorry, something went wrong.

@vontell
Copy link
Author

vontell commented Jan 17, 2017

Also, I believe that warnings to the developers during compilation (i.e. Note that append on the array type (line ###) is not supported within kernels!) would be extremely helpful.

Sorry, something went wrong.

@whitequark
Copy link
Contributor

Is this due to the fact that experiments must not have a runtime dispatch, and tuples are capable of holding values of different types?

Absolutely correct. You can deconstruct tuples with a, b, c = tup.

Also, I believe that warnings to the developers during compilation (i.e. Note that append on the array type (line ###) is not supported within kernels!) would be extremely helpful.

I don't understand what do you mean by this. Trying to use the append method in kernels already results in errors. Do you also want a warning in the host Python code?

Sorry, something went wrong.

@jordens
Copy link
Member

jordens commented Jan 18, 2017

The error's context (being a @kernel and ARTIQPython being different from regular Python) is not always obvious for beginners.

@vontell
Copy link
Author

vontell commented Jan 18, 2017

@whitequark sorry, this is true that the errors are quite clear of the problem. As @jordens said, as a beginner such as myself where ARTIQ is my first endeavor in using FPGA systems, it was not immediately clear that the host Python code is compiled into a different type of Python code. From the documentation it is clear that there is a conversion happening, but I had no idea that the compiled code would have a subset of the original Python features (I originally assumed that the conversion was more on the 'optimization' side of things) . I think what would be helpful to developers is a few quick examples of unsupported operations in this section of the manual (regarding things such as lists, and possibly even presenting the idea of pre allocated arrays using list comprehensions; this part was confusing considering the supported section includes 'lists of any supported types'). It might even be useful to put a quick note at the beginning of the Getting started with the code language section, something simple such as "Please note the limitiations of some Python operations imposed by ARTIQ's compiler.

@jbqubit
Copy link
Contributor

jbqubit commented Jan 24, 2017 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants