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

Chore: Update version 0.5.0 #67

Merged
merged 4 commits into from
Aug 30, 2024
Merged

Chore: Update version 0.5.0 #67

merged 4 commits into from
Aug 30, 2024

Conversation

jcabrero
Copy link
Member

@jcabrero jcabrero commented Aug 29, 2024

This PR includes the changes required to update Nada-Numpy to version 0.5.0 corresponding to version 0.6.0 of Nada-DSL and Nillion Python Client.

Note: This is expected to fail before finishing we need to:

  • Version 0.6.0 of Nada DSL and Python Client needs to be released.
  • Update poetry lock: poetry lock
  • Push to and wait for CI/CD to execute.

Copy link
Contributor

@mathias-nillion mathias-nillion left a comment

Choose a reason for hiding this comment

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

Looks good once CI/CD passes - left some comments/ideas but I think they fall outside of the scope of this PR

D_2:
SecretInteger: "3"

B_1: 3
Copy link
Contributor

Choose a reason for hiding this comment

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

interesting change. how do we know if these values are public/secret and signed/unsigned?
can we no longer customize this is these YAML files?

Copy link
Member Author

Choose a reason for hiding this comment

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

Basically, the value is introduced into the specific type expected by the Nada program. So it takes it already from the Nada Program.

b: 330643400256
Copy link
Contributor

Choose a reason for hiding this comment

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

If we can no longer type-annotate in these YAMLs, that removes any prospect of annotating as Rational to abstract away this scaling logic?
Or do we just assume that if a float is passed then it is a rational?

@@ -14,6 +14,8 @@ def nada_main():
b = na.NadaArray(np.array([]))
c = na.NadaArray(np.array([na.rational(1.5)]))

a += Integer(0)
Copy link
Contributor

Choose a reason for hiding this comment

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

Not a big fan of this :p
Same goes for all other instances of this.

Copy link
Member Author

Choose a reason for hiding this comment

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

In this new version, programs without compute stop compiling. All these programs where there's this instance of a += Integer(0) are programs that without this compute line would not compile. I know it's a tricky thing, but I don't know a better/faster way to handle it.

SecretInteger: '3'
A_0_1_1:
SecretInteger: '3'
A_0_0_0: 3
Copy link
Contributor

Choose a reason for hiding this comment

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

Looking at this, it would actually be quite nice if we could put a (possibly nested) list in these YAMLs
So something like A: [[1, 2, 3], [4, 5, 6], ...]

Copy link
Member Author

Choose a reason for hiding this comment

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

WIth the new testing infrastructure, I would like to deprecate the use of these files and creating programmatic tests that check for all these behaviours. In such case, we can directly input lists and forget about filling up ginormous files.

@jcabrero jcabrero merged commit 178a4f4 into main Aug 30, 2024
4 checks passed
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.

2 participants