feat: Zero and One traits #4254

enitrat · 2023-10-13T09:45:16Z

Continues the work started in #3891
Closes #4236

Created a num directory with traits.cairo file
Added a One trait, and implementations for uints, ints and felt252
Added a Zero trait, and implementations for uints, ints and felt252
Made the Zeroable trait generically implemented from the Zero trait
Made the Oneable trait generically implemented from the One trait

Questions:

Should I split them into num/traits/one.cairo and num/traits/zero.cairo?
Should I bring other numeric traits inside this dir

Starknet tests are failing but I'm not sure why.

This change is

orizi

Reviewable status: 0 of 6 files reviewed, 2 unresolved discussions (waiting on @enitrat)

corelib/src/num/traits.cairo line 6 at r1 (raw file):

    /// Returns the multiplicative identity element of Self, 0.
    #[inline(always)]
    fn zero() -> T;

doesn't do anything here.
and generally avoid unless you have a specific issue (for example, making a current test contract be less efficient)

Suggestion:

trait Zero<T> {
    /// Returns the multiplicative identity element of Self, 0.
    fn zero() -> T;

corelib/src/num/traits.cairo line 15 at r1 (raw file):

impl Felt252Zero of Zero<felt252> {
    #[inline(always)]
    fn zero() -> felt252 {

this is already inlined by heuristic.

Suggestion:

    fn zero() -> felt252 {

enitrat · 2023-10-17T09:09:32Z

Removed #[inline(always)] for zero() and one() functions

orizi

Reviewed 5 of 6 files at r1, 1 of 1 files at r2, all commit messages.
Reviewable status: all files reviewed, 1 unresolved discussion (waiting on @enitrat)

a discussion (no related file):
@yuvalsw for 2nd eye.

yuvalsw

Reviewed 5 of 6 files at r1, 1 of 1 files at r2, all commit messages.
Reviewable status: all files reviewed, 7 unresolved discussions (waiting on @enitrat)

a discussion (no related file):
Please split into num/traits/one.cairo and num/traits/zero.cairo as suggested, and re-export them in num/traits.cairo (e.g. use one::One;).

corelib/src/math.cairo line 132 at r2 (raw file):

}

impl TOneableImpl<T, +One<T>, +Drop<T>> of Oneable<T> {

I think you should +Copy here too, we don't want any such impl to be consuming.

corelib/src/zeroable.cairo line 13 at r2 (raw file):

}

impl ZeroableImpl<T, +Zero<T>, +Drop<T>> of Zeroable<T> {

same here

corelib/src/num/traits.cairo line 3 at r2 (raw file):

// === Zero ===

trait Zero<T> {

please doc. Same for One

corelib/src/num/traits.cairo line 9 at r2 (raw file):

    fn is_zero(self: @T) -> bool;
    /// Returns whether self is not equal to 0, the multiplicative identity element.
    fn is_non_zero(self: @T) -> bool;

Suggestion:

    /// Returns the additive identity element of Self, 0.
    fn zero() -> T;
    /// Returns whether self is equal to 0, the additive identity element.
    fn is_zero(self: @T) -> bool;
    /// Returns whether self is not equal to 0, the additive identity element.
    fn is_non_zero(self: @T) -> bool;

corelib/src/num/traits.cairo line 12 at r2 (raw file):

}

impl Felt252Zero of Zero<felt252> {

Please move the impls to the module where the type is defined and not here. E.g. for uints move to integer.cairo.

Code quote:

impl Felt252Zero of Zero<felt252> {

enitrat · 2023-10-18T16:12:49Z

Applied suggestions.

Split into zero and one files
Moved impls to respective files integer.cairo for uints/ints, lib.cairo for felt252
Added doc for Zero and One traits
Added a requirement for Copy<T> on generic impls

orizi

Reviewed 3 of 7 files at r3, all commit messages.
Reviewable status: 4 of 8 files reviewed, 8 unresolved discussions (waiting on @enitrat and @yuvalsw)

corelib/src/lib.cairo line 8 at r3 (raw file):

};
use serde::Serde;
use num::traits::{Zero, One};

remove this use - as this exports this as core::One - which we shouldn't.

enitrat · 2023-10-19T02:10:09Z

Removed import of num::traits::{Zero,One} in lib.cairo
Referred to the full path of num::traits::Zero and num::traits::One in the impl for felt252 in lib.cairo instead

orizi

Reviewed 1 of 2 files at r4, all commit messages.
Reviewable status: 5 of 8 files reviewed, 8 unresolved discussions (waiting on @enitrat and @yuvalsw)

yuvalsw

Reviewed 5 of 7 files at r3, 2 of 2 files at r4, all commit messages.
Reviewable status: all files reviewed, 7 unresolved discussions (waiting on @enitrat)

corelib/src/integer.cairo line 7 at r4 (raw file):

use array::ArrayTrait;
use array::SpanTrait;
use num::traits::{Zero, One};

this also re-exports it from here. Better fully qualify in the usage instead.

corelib/src/lib.cairo line 211 at r4 (raw file):

impl Felt252Zero of num::traits::Zero<felt252> {

please move these to felt252.cairo (create it). Felt stuff should be in a dedicated module. We can't yet move items that are here as it would break existing code, but new items should be there.
Thanks!

enitrat · 2023-10-19T09:33:02Z

Removed import of {Zero,One} in integer.cairo and used full paths
Moved Felt252{Zero,One} to felt252.cairo

orizi

Reviewed 3 of 3 files at r5, all commit messages.
Reviewable status: all files reviewed, 6 unresolved discussions (waiting on @enitrat)

yuvalsw

Reviewed 3 of 3 files at r5, all commit messages.
Reviewable status: all files reviewed, 1 unresolved discussion (waiting on @enitrat)

corelib/src/integer.cairo line 2330 at r5 (raw file):

    #[inline(always)]
    fn is_zero(self: @u8) -> bool {
        *self == num::traits::Zero::zero()

would be slightly better to use the specific impl directly and not the trait.

Suggestion:

*self == U8Zero::zero()

enitrat · 2023-10-19T14:16:25Z

would be slightly better to use the specific impl directly and not the trait.

Done.

Also, I noticed that I was importing One in math.cairo and Zero in Zeroable. For consistency with previous reviews, I used explicit full paths instead.

yuvalsw

Good catch, thanks. Hope this is the last iteration :)

Reviewed 4 of 4 files at r6, all commit messages.
Reviewable status: all files reviewed, 1 unresolved discussion (waiting on @enitrat)

corelib/src/math.cairo line 143 at r6 (raw file):

        num::traits::One::is_non_one(@self)
    }
}

same in zeroable

Suggestion:

impl TOneableImpl<T, impl OneImpl: num::traits::One<T>, +Drop<T>, +Copy<T>> of Oneable<T> {
    fn one() -> T {
        OneImpl::one()
    }
    #[inline(always)]
    fn is_one(self: T) -> bool {
        OneImpl::is_one(@self)
    }
    #[inline(always)]
    fn is_non_one(self: T) -> bool {
        OneImpl::is_non_one(@self)
    }
}

enitrat · 2023-10-19T16:00:19Z

Done, should be all good now, thanks for taking the time!

yuvalsw

LGTM, but CI fails. Please check and fix.

Reviewed 2 of 2 files at r7, all commit messages.
Reviewable status: complete! all files reviewed, all discussions resolved (waiting on @enitrat)

enitrat · 2023-10-19T17:17:44Z

CI fails after moving felt impls to felt_252.cairo. Because these impls are not part of the prelude, they're not found by the generic TZeroableImpl - and thus Zeroable<felt252> can't be used as it used to before.
The following code is erroneous:

    #[inline(always)]
    fn is_zero(self: EthAddress) -> bool {
        self.address.is_zero()
    }

-->

Method `is_zero` not found on type "core::felt252". Did you import the correct trait and impl?

One solution would be this

use felt_252::{Felt252Zero};

    //...
    #[inline(always)]
    fn is_zero(self: EthAddress) -> bool {
        zeroable::TZeroableImpl::<felt252>::is_zero(self.address)
    }

But I'm not sure if it's the best approach. Another approach would be to re-export them in lib.cairo (I don't think we want that either.)

A third approach would be using impl alias in the felt_252.cairo file to declare Felt252Zeroable from TZeroableImpl<felt252> and refer to this one.

yuvalsw

The third approach SG. Also note:

you must rename felt252.cairo to e.g. felt_252.cairo. Otherwise there would be a conflict with the type name.
You need to add felt_252 as a module in lib.cairo.

Reviewable status: complete! all files reviewed, all discussions resolved (waiting on @enitrat)

enitrat · 2023-10-23T03:58:32Z

What I ended up doing for ClassHash, ContractAddress, EthAddress is:

Replaced Zeroable<ContractAddress> impls by Zero<ContractAddress> - it will automatically generate an implementation for the Zeroable trait through TZeroableImpl.
Used impl aliases to instantiating the generic TZeroable with the concrete type
Explicitly used Felt252Zero in class_hash, contract_address, and eth_address files with:

    #[inline(always)]
    fn is_zero(self: EthAddress) -> bool {
        felt_252::Felt252Zero::is_zero(self.address)
    }

The only concern I have is that the Zero trait becomes practically unusable because:

To use .is_zero() on a felt252, I need to import Felt252Zero
If I import Felt252Zero, then I think an impl for zeroable::TZeroableImpl<felt252>; is created
Since Zeroable is included in the prelude, then both Zeroable and Zero can be applied to the felt252 type, which causes the following conflict.

Ambiguous method call. More than one applicable trait function with a suitable self type was found: Zero::is_zero and Zeroable::is_zero. Consider adding type annotations or explicitly refer to the impl function.

I don't think the approach is right, and I do think that we should rethink how Zeroable / Zero are used - ideally, we can perhaps don't include Zeroable in the prelude and only use the Zero trait instead?
In the current state of things, I would be against merging this PR until we find a satisfying solution.

yuvalsw

That is true, but as you realised, it's currently impossible to remove it from the prelude. We are working on solutions to do that. For now we have some workarounds.

What I meant is to have the generic impl (TZeroableImpl) "hidden" (in a module), and instantiate impl aliases of it with the concrete relevant types, each in its relevant module. A similar approach is used in into_felt252_based::HashImpl, you can take a look there.
This will mean that Zeroable will not be implemented (in context) for any type that implements Zero, but only for the types for which there is an impl alias with them as the generic argument.
For now, there will indeed be ambiguity between Zeroable and Zero for the types already implementing Zeroable, so you can't use Zero for such types. What would be possible is to use it in generic implementations, e.g. fn something<T, +Zero<T>>(t: T) { ... t.is_zero() ... }.

I feel like it's not super clear what needs to be done here, so let me try to elaborate:

Put the generic impl of Zeroable in an inline module.
Have impl aliases with the relevant type for all the types that already implement Zeroable (like you did).
Leave Zero as is.
Same for One.

Reviewed 2 of 5 files at r8, 4 of 4 files at r9, all commit messages.
Reviewable status: complete! all files reviewed, all discussions resolved (waiting on @enitrat)

orizi

Reviewable status: complete! all files reviewed, all discussions resolved (waiting on @enitrat)

corelib/src/zeroable.cairo line 24 at r9 (raw file):

        ZeroImpl::is_non_zero(@self)
    }
}

as this currently causes Zeroable to be available whenever Zero is available, so is_zero is always ambiguous - we can do this instead:

(this would provide backwards compatility for only what we already provided without causing collisions in the general case)

Do the same for Oneable.
(just saw yuval wrote the same thing, but this is some more info, so leaving here)

Suggestion:

mod zero_based {
impl ZeroableImpl<T, impl ZeroImpl: num::traits::Zero<T>, +Drop<T>, +Copy<T>> of Zeroable<T> {
    fn zero() -> T {
        ZeroImpl::zero()
    }
    #[inline(always)]
    fn is_zero(self: T) -> bool {
        ZeroImpl::is_zero(@self)
    }
    #[inline(always)]
    fn is_non_zero(self: T) -> bool {
        ZeroImpl::is_non_zero(@self)
    }
}
}
/// In the files this originally existed in:
impl U8Zeroable = zero_based::ZeroableImpl<u8, integer::U8Zero>;
impl U16Zeroable = zero_based::ZeroableImpl<u16, integer::U16Zero>;
impl U32Zeroable = zero_based::ZeroableImpl<u32, integer::U32Zero>;
impl U64Zeroable = zero_based::ZeroableImpl<u64, integer::U64Zero>;
impl U128Zeroable = zero_based::ZeroableImpl<u128, integer::U128Zero>;
impl U256Zeroable = zero_based::ZeroableImpl<u256, integer::U256Zero>;

yuvalsw

Reviewed 7 of 7 files at r10, all commit messages.
Reviewable status: all files reviewed, 7 unresolved discussions (waiting on @enitrat)

.tool-versions line 0 at r10 (raw file):
this is unrelated.

corelib/src/integer.cairo line 2332 at r10 (raw file):

// Zero trait implementations
impl U8Zero of num::traits::Zero<u8> {

BTW, you can use the same method for these impls. Impl it once, generically and hidden in an inner module here, and then have impl aliases. It would be shorter.

Same for One.

corelib/src/math.cairo line 131 at r10 (raw file):

}

impl TOneableImpl<T, impl OneImpl: num::traits::One<T>, +Drop<T>, +Copy<T>> of Oneable<T> {

do the same for oneable. "Hidden" generic impl plus impl aliases.

corelib/src/zeroable.cairo line 28 at r10 (raw file):

}

impl ContractAddressZeroable = zeroable::zero_based::ZeroableImpl<felt252, felt_252::Felt252Zero>;

Remove, I see it's already in contract_address.cairo, and correctly (here you accidentally use felt252).

Code quote:

impl ContractAddressZeroable = zeroable::zero_based::ZeroableImpl<felt252, felt_252::Felt252Zero>;

corelib/src/starknet/class_hash.cairo line 40 at r10 (raw file):

}

impl ContractAddressZeroable = zeroable::zero_based::ZeroableImpl<ClassHash, ClassHashZero>;

Suggestion:

ClassHashZeroable

corelib/src/starknet/contract_address.cairo line 42 at r10 (raw file):

}

impl ContractAddressZeroable = zeroable::zero_based::ZeroableImpl<ContractAddress,ContractAddressZero>;

Suggestion:

ContractAddress, ContractAddre

corelib/src/felt_252.cairo line 33 at r8 (raw file):

}

impl Felt252Zeroable = zeroable::TZeroableImpl<felt252>;

An impl for felt existed , use an impl alias instead here.

enitrat

Sorry, I was still working on it but got interrupted before pushing the commit with one and fixing what was previously wrong - should be good now.

Last problem is the failing CI on contract class tests, which I think is due to the change in sierra code induced by the changes in the corelib. Should I update the test fixtures as well?

Reviewable status: 10 of 14 files reviewed, 7 unresolved discussions (waiting on @yuvalsw)

.tool-versions line at r10 (raw file):

Previously, yuvalsw wrote…

this is unrelated.

Done.

corelib/src/integer.cairo line 2332 at r10 (raw file):

Previously, yuvalsw wrote…

BTW, you can use the same method for these impls. Impl it once, generically and hidden in an inner module here, and then have impl aliases. It would be shorter.

Same for One.

I don't think I can because I cannot create generic numeric literals. Or I didn't understand what you suggested, but I don't see how I can create a generic impl for Zero and One.

corelib/src/math.cairo line 131 at r10 (raw file):

Previously, yuvalsw wrote…

do the same for oneable. "Hidden" generic impl plus impl aliases.

Done.

corelib/src/zeroable.cairo line 28 at r10 (raw file):

Previously, yuvalsw wrote…

Remove, I see it's already in contract_address.cairo, and correctly (here you accidentally use felt252).

Done.

corelib/src/starknet/class_hash.cairo line 40 at r10 (raw file):

}

impl ContractAddressZeroable = zeroable::zero_based::ZeroableImpl<ClassHash, ClassHashZero>;

Done.

corelib/src/starknet/contract_address.cairo line 42 at r10 (raw file):

}

impl ContractAddressZeroable = zeroable::zero_based::ZeroableImpl<ContractAddress,ContractAddressZero>;

Done.

corelib/src/felt_252.cairo line 33 at r8 (raw file):

Previously, yuvalsw wrote…

An impl for felt existed , use an impl alias instead here.

These are Zero and One impls, not Zeroable/Oneable. Oneable didn't exist for felt, Zeroable did but under the zeroable.cairo file

yuvalsw

Reviewed 4 of 4 files at r11, all commit messages.
Reviewable status: all files reviewed, 2 unresolved discussions (waiting on @enitrat)

.tool-versions line at r10 (raw file):

Previously, enitrat (Mathieu) wrote…

Done.

I still see it.

corelib/src/integer.cairo line 2332 at r10 (raw file):

Previously, enitrat (Mathieu) wrote…

I don't think I can because I cannot create generic numeric literals. Or I didn't understand what you suggested, but I don't see how I can create a generic impl for Zero and One.

Ah, you are right, it's not currently possible.

enitrat

Should be good now, sorry for the troubles - I finally understood how reviewable works which makes thing easier indeed.

I still have this CI problem I raised above.

Reviewable status: all files reviewed, 1 unresolved discussion (waiting on @yuvalsw)

.tool-versions line at r10 (raw file):

Previously, yuvalsw wrote…

I still see it.

Done. For some reason it reappeard 🤔

yuvalsw

Yes, please update the expected test files with: CAIRO_FIX_TESTS=1 cargo test -p starknet.
We'll review the changes to make sure they look good.

Reviewable status: all files reviewed, 1 unresolved discussion (waiting on @enitrat)

.tool-versions line at r10 (raw file):

Previously, enitrat (Mathieu) wrote…

Done. For some reason it reappeard 🤔

I still see it :(

enitrat

Done.

Reviewable status: 13 of 28 files reviewed, 1 unresolved discussion (waiting on @orizi and @yuvalsw)

.tool-versions line at r10 (raw file):

Previously, yuvalsw wrote…

I still see it :(

Done. I triple checked this time! It seems that scarb auto-generates it

yuvalsw

Reviewed 15 of 15 files at r12, all commit messages.
Reviewable status: complete! all files reviewed, all discussions resolved (waiting on @enitrat)

yuvalsw · 2023-10-26T13:15:45Z

Seems like you need to rebase.

orizi

Reviewed 2 of 7 files at r3, 1 of 2 files at r4, 1 of 5 files at r8, 1 of 4 files at r9, 3 of 7 files at r10, 4 of 4 files at r11, all commit messages.
Reviewable status: complete! all files reviewed, all discussions resolved (waiting on @enitrat)

orizi

Reviewed 2 of 15 files at r13, all commit messages.
Reviewable status: 15 of 28 files reviewed, all discussions resolved (waiting on @yuvalsw)

yuvalsw

Reviewed 15 of 15 files at r13, all commit messages.
Reviewable status: complete! all files reviewed, all discussions resolved (waiting on @enitrat)

orizi requested changes Oct 17, 2023

View reviewed changes

orizi approved these changes Oct 17, 2023

View reviewed changes

yuvalsw requested changes Oct 18, 2023

View reviewed changes

orizi requested changes Oct 18, 2023

View reviewed changes

orizi reviewed Oct 19, 2023

View reviewed changes

yuvalsw requested changes Oct 19, 2023

View reviewed changes

orizi approved these changes Oct 19, 2023

View reviewed changes

yuvalsw requested changes Oct 19, 2023

View reviewed changes

yuvalsw approved these changes Oct 19, 2023

View reviewed changes

yuvalsw approved these changes Oct 22, 2023

View reviewed changes

enitrat force-pushed the feat/zero-one-traits branch from 82178e8 to 849c327 Compare October 23, 2023 04:49

yuvalsw approved these changes Oct 23, 2023

View reviewed changes

orizi reviewed Oct 24, 2023

View reviewed changes

yuvalsw requested changes Oct 25, 2023

View reviewed changes

enitrat commented Oct 25, 2023

View reviewed changes

yuvalsw requested changes Oct 26, 2023

View reviewed changes

enitrat commented Oct 26, 2023

View reviewed changes

yuvalsw requested changes Oct 26, 2023

View reviewed changes

enitrat commented Oct 26, 2023

View reviewed changes

yuvalsw approved these changes Oct 26, 2023

View reviewed changes

enitrat added 12 commits October 26, 2023 20:23

feat: Zero and One traits

c7e6ea6

feat: iX types Zero/One impl

310c9f8

fix: remove inlining and fns

cf90066

dev: apply PR review suggestions

d9e9940

remove re-export of Zero,One

95dca4e

refactor: moved felt impls to felt252.cairo

6cee90a

refactor: use named impls

ad66f0f

fix: use named impl requirement

86a5dc5

fix: CI

5278cde

refactor: hidden TZeroableImpl module

4ef1028

refactor: hidden OneableImpl module

0730b43

fix: Zeroable class hash name

9b27c2b

orizi approved these changes Oct 26, 2023

View reviewed changes

tests: updated test_data contract_classes

510a242

enitrat force-pushed the feat/zero-one-traits branch from 5fb0afd to 510a242 Compare October 26, 2023 13:31

orizi reviewed Oct 26, 2023

View reviewed changes

yuvalsw approved these changes Oct 26, 2023

View reviewed changes

yuvalsw added this pull request to the merge queue Oct 26, 2023

Merged via the queue into starkware-libs:main with commit d205edc Oct 26, 2023

orizi mentioned this pull request Nov 21, 2023

feat: Implement One Trait Analogous to Rust's in Cairo #3881

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

feat: Zero and One traits #4254

feat: Zero and One traits #4254

enitrat commented Oct 13, 2023 •

edited

Loading

orizi left a comment

enitrat commented Oct 17, 2023

orizi left a comment

yuvalsw left a comment

enitrat commented Oct 18, 2023

orizi left a comment

enitrat commented Oct 19, 2023

orizi left a comment

yuvalsw left a comment

enitrat commented Oct 19, 2023

orizi left a comment

yuvalsw left a comment

enitrat commented Oct 19, 2023

yuvalsw left a comment

enitrat commented Oct 19, 2023

yuvalsw left a comment

enitrat commented Oct 19, 2023 •

edited

Loading

yuvalsw left a comment

enitrat commented Oct 23, 2023 •

edited

Loading

yuvalsw left a comment

orizi left a comment

yuvalsw left a comment

enitrat left a comment

yuvalsw left a comment

enitrat left a comment

yuvalsw left a comment

enitrat left a comment

yuvalsw left a comment

yuvalsw commented Oct 26, 2023

orizi left a comment

orizi left a comment

yuvalsw left a comment

feat: Zero and One traits #4254

feat: Zero and One traits #4254

Conversation

enitrat commented Oct 13, 2023 • edited Loading

orizi left a comment

Choose a reason for hiding this comment

enitrat commented Oct 17, 2023

orizi left a comment

Choose a reason for hiding this comment

yuvalsw left a comment

Choose a reason for hiding this comment

enitrat commented Oct 18, 2023

orizi left a comment

Choose a reason for hiding this comment

enitrat commented Oct 19, 2023

orizi left a comment

Choose a reason for hiding this comment

yuvalsw left a comment

Choose a reason for hiding this comment

enitrat commented Oct 19, 2023

orizi left a comment

Choose a reason for hiding this comment

yuvalsw left a comment

Choose a reason for hiding this comment

enitrat commented Oct 19, 2023

yuvalsw left a comment

Choose a reason for hiding this comment

enitrat commented Oct 19, 2023

yuvalsw left a comment

Choose a reason for hiding this comment

enitrat commented Oct 19, 2023 • edited Loading

yuvalsw left a comment

Choose a reason for hiding this comment

enitrat commented Oct 23, 2023 • edited Loading

yuvalsw left a comment

Choose a reason for hiding this comment

orizi left a comment

Choose a reason for hiding this comment

yuvalsw left a comment

Choose a reason for hiding this comment

enitrat left a comment

Choose a reason for hiding this comment

yuvalsw left a comment

Choose a reason for hiding this comment

enitrat left a comment

Choose a reason for hiding this comment

yuvalsw left a comment

Choose a reason for hiding this comment

enitrat left a comment

Choose a reason for hiding this comment

yuvalsw left a comment

Choose a reason for hiding this comment

yuvalsw commented Oct 26, 2023

orizi left a comment

Choose a reason for hiding this comment

orizi left a comment

Choose a reason for hiding this comment

yuvalsw left a comment

Choose a reason for hiding this comment

enitrat commented Oct 13, 2023 •

edited

Loading

enitrat commented Oct 19, 2023 •

edited

Loading

enitrat commented Oct 23, 2023 •

edited

Loading