dev: Exponentiation & Bitshift generics

[akhercha]

Pull Request type

Please check the type of change your PR introduces:

• Bugfix
• Feature
• Code style update (formatting, renaming)
• Refactoring (no functional changes, no API changes)
• Build-related changes
• Documentation content changes
• Other (please describe):

What is the current behavior?

Resolves: #408

What is the new behavior?

• Added ExponentiationImpl<T, ...> of Exponentiation<T>

  • then removed U256ExpImpl & U128ExpImpl

• Added BitshiftImpl<T, ...> of Bitshift<T>

  • then removed U256BitshiftImpl & U128BitshiftImpl

Does this introduce a breaking change?

• Yes
• No

[Eikix]

Nice PR overall,
Good catch that wrappingbitshift and wrappingpow are not able to be generic over T

[akhercha]

Saw that the original implementation of shr has 2 different behavior depending on the type:

fn shr(self: u128, shift: u128) -> u128 {
        if shift > 127 {
            return 0;
        }
        self / 2.pow(shift)
    }
// or
fn shr(self: u256, shift: u256) -> u256 {
        if shift > 255 {
            // 2.pow(shift) for shift > 255 will panic with 'u256_mul Overflow'
            panic_with_felt252('u256_mul Overflow');
        }
        self / 2.pow(shift)
    }

Not sure of which we prefer for the T type. I'd say panic, what do you think @Eikix ?

[enitrat]

Regular shr is supposed to panic indeed

[akhercha]

Should be good then!
Let me know if I missed something. 🙏

I also quickly updated the organization of the code, added a mem module & updated the names of the functions.

[enitrat]

Great work

[enitrat]

Also @akhercha I think your local git is not synced to your GH account - not sure if it's on purpose or not

[akhercha]

Ah no indeed, something exploded in my config I guess, gonna check that thanks!

[enitrat]

@akhercha I just pushed a change with more optimized gas usage - basically since Oneable and Zeroable fns are not inlined there's a small overhead in gas consumption if we rely on them for genericity. Therefore I changed my mind about my previous comment, and explicitly implemented Zero and One for u128, u256, and felt252 ( we won't need other impls, at least for now).

This nullifies any increase in gas consumption for pow-dependent functions; however there's still an increase for shr. and shl, I'm looking for the cause

[enitrat]

LGTM!
@akhercha do you want to open an issue to implement SizeOf in the corelib https://github.com/starkware-libs/cairo?

[Eikix]

lgtm 🔥