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

Support/Enforce dtype for empty() #2294

Merged
merged 18 commits into from
Aug 28, 2023

Conversation

Shaikh-Ubaid
Copy link
Collaborator

fixes #1790

@Shaikh-Ubaid Shaikh-Ubaid changed the title Support dtype for empty() Support/Enforce dtype for empty() Aug 24, 2023
@Shaikh-Ubaid Shaikh-Ubaid force-pushed the dtype_for_empty branch 3 times, most recently from fd741b5 to 5bfa55e Compare August 24, 2023 18:48
for i in range(n):

m: Const[i32] = 10
b: Allocatable[i32[:]] = empty((m,), dtype=int32)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here m doesn't need to be constant. Instead this test is testing that it can be a runtime variable. So we need to preserve the test.

@certik
Copy link
Contributor

certik commented Aug 24, 2023

I think this is great. Thank you. I left an important comment to fix before we can merge.

@certik certik marked this pull request as draft August 24, 2023 23:28
integration_tests/array_03.py Outdated Show resolved Hide resolved
@Shaikh-Ubaid Shaikh-Ubaid marked this pull request as ready for review August 28, 2023 05:06
a: c64[n] = empty([n], dtype=complex64)
b: c64[n] = empty([n], dtype=complex64)
a: c64[n] = empty([n], dtype=complex128)
b: c64[n] = empty([n], dtype=complex128)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good catch. It's confusing, but I think it's less confusing to use c32 and c64 to mean 32bit and 64bit complex numbers (each component), so c32 corresponds to f32 and c64 to f64. NumPy uses the size of the whole complex number (both components together). Now LPython catches the mistake, so that's good.

@@ -16,21 +16,21 @@ def add_float(x: f32, y: f32) -> f32:

def g(n: i32, a: T[n], b: T[n], **kwargs):
r: T[n]
r = empty(n)
r = empty(n, dtype=object)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is fine for now to get it to compile. Good catch. This we will have to fix later, since this should really be just:

r: T[n] = empty(n, dtype=T)

But that requires cooperation of numpy and generics. We are improving the generics in LFortran, once we are done and have a reasonably good design, we'll update LPython as well.

--> tests/errors/test_dict2.py:4:7
|
4 | y[1] = -3
| ^ type mismatch (found: 'i32', expected: 'str')
| ^
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I liked the short label, showing what is wrong.

@certik
Copy link
Contributor

certik commented Aug 28, 2023

What is the default for "empty" in NumPy, is it f64? Perhaps later we can allow the default as well. For now it's fine.

I found a bug: #2294 (comment), so that should be fixed.

Other than that, the rest are minor comments. Great job! Thanks for implementing this. I'll mark it as Draft until the bug is fixed.

@certik certik marked this pull request as draft August 28, 2023 15:49
Previously, the test was using float64 (which is the default value for dtype).
After providing the value of dtype=float32 the test seems to fail sometimes.
Therefore, making the error bound less stricter.
@Shaikh-Ubaid Shaikh-Ubaid marked this pull request as ready for review August 28, 2023 17:06
Copy link
Contributor

@certik certik left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that looks good to merge. Let's add a test for an error message if the dtype mismatches the type annotation? That can be done in a subsequent PR.

@Shaikh-Ubaid
Copy link
Collaborator Author

Let's add a test for an error message if the dtype mismatches the type annotation? That can be done in a subsequent PR.

Yes, I have it planned.

@Shaikh-Ubaid
Copy link
Collaborator Author

Thank you so much for the approval!

@Shaikh-Ubaid Shaikh-Ubaid merged commit f011dbe into lcompilers:main Aug 28, 2023
12 checks passed
@Shaikh-Ubaid Shaikh-Ubaid deleted the dtype_for_empty branch August 28, 2023 18:33
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Enforce dtype for empty()
4 participants