Open jasonpaulos opened 2 years ago
Looks good!
Leaving pointers to branches making progress towards the story's request:
In this fork, we can see an initial implementation for signed integers. It is leveraging Uint implementation with some minor issues. Namely:
Expr
, the result must be checked for valid range. This ends up checking for < 2^bit_len
in Uint implementation and for < 2^(bit_len - 1)
. This is obviously correct but redundant.So far most ABI types can make use of native instructions to provide correct results and that makes their usage in contracts trivial (.get()
to extract and then use). This will not be the case for both signed integers and fixed point numbers. There should be a way to have "methods" or operator overloading for ABI types such that we can make their usage transparent to the particular implementation of an abstract type.
P.S.: The ideal name would be Int
and IntTypeSpec
but I didn't want abi.int.Int
to clash with ast.int.Int
. I find SInt
not to be the obvious name for this. Name suggestions are much welcomed.
Since Int's in pyteal and teal are really uint's by default, it seems reasonable to signal the opposite with a name such as Sint or even the more verbose SignedInt
Added some implementation for fixed point numbers. Not much to show but feedback is appreciated.
Added some implementation for fixed point numbers. Not much to show but feedback is appreciated.
Thanks for this work.
How would you like to receive feedback? If you open a pull request, even in draft mode, this will facilitate having a discussion and it is easier to point to specific code in the PR-mode. Other forms of discussion could work as well if you have something specific in mind.
Good point. I have opened this draft PR. Thanks!
Summary
Add support for the following numeric types to PyTeal:
Scope
Ideally this would replicate most of the feature described in https://github.com/algorand/pyteal/issues/181 for these new types.
Note that signed integers and signed fixed point numbers are not ARC-4 ABI compliant, so we should not allow public ABI methods to accept arguments or have a return value that uses these types. But they could be added to the ABI in the future, and in any case they are still useful internally.