Enabler struct

[shaharsamocha7]

This change is 

[shaharsamocha7]

• Enabler struct #362 👈 (View in Graphite)
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

[alon-f]

Reviewed 1 of 1 files at r1, all commit messages.
Reviewable status: all files reviewed, 2 unresolved discussions (waiting on @Gali-StarkWare and @shaharsamocha7)

---

stwo_cairo_prover/crates/prover/src/components/utils.rs line 88 at r1 (raw file):

/// The enabler column is a column of length `padding_offset.next_power_of_two()` where
/// 1. The first `padding_offset` elements set to 1;

elements are set

Code quote:

elements set

---

stwo_cairo_prover/crates/prover/src/components/utils.rs line 89 at r1 (raw file):

/// The enabler column is a column of length `padding_offset.next_power_of_two()` where
/// 1. The first `padding_offset` elements set to 1;
/// 2. Otherwise set to 0.

The rest are set to 0.

Code quote:

Otherwise set to 0.

[Gali-StarkWare]

Reviewable status: all files reviewed, 4 unresolved discussions (waiting on @shaharsamocha7)

---

stwo_cairo_prover/crates/prover/src/components/utils.rs line 87 at r1 (raw file):

}

/// The enabler column is a column of length `padding_offset.next_power_of_two()` where

Will it always be the case? It makes sense but I can imagine a scenario where we change the size of the table as part of an optimisation (uniting it with another bigger table for some reason).

---

stwo_cairo_prover/crates/prover/src/components/utils.rs line 101 at r1 (raw file):

    pub fn packed_at(&self, vec_row: usize) -> PackedM31 {
        let packed_row_offset = vec_row * N_LANES;
        PackedM31::from_array(array::from_fn(|i| {

We can use broadcast for cases of an all '0'/'1' arrays but I'm not sure how important is efficiency here. Non-blocking.

[shaharsamocha7]

Reviewable status: 0 of 1 files reviewed, 2 unresolved discussions (waiting on @alon-f and @Gali-StarkWare)

---

stwo_cairo_prover/crates/prover/src/components/utils.rs line 87 at r1 (raw file):

Previously, Gali-StarkWare wrote…

Will it always be the case? It makes sense but I can imagine a scenario where we change the size of the table as part of an optimisation (uniting it with another bigger table for some reason).

You mean padding by more than a power of two?
This is inherit in the protocol, so I don't think this should change.
But if it will, we will change the code when we need that :)

---

stwo_cairo_prover/crates/prover/src/components/utils.rs line 101 at r1 (raw file):

Previously, Gali-StarkWare wrote…

We can use broadcast for cases of an all '0'/'1' arrays but I'm not sure how important is efficiency here. Non-blocking.

Agree, but don't want to focus on optimizations ATM.

[Gali-StarkWare]

Reviewed 1 of 1 files at r2, all commit messages.
Reviewable status: complete! all files reviewed, all discussions resolved (waiting on @shaharsamocha7)