generate enabler column

[shaharsamocha7]

This change is 

[shaharsamocha7]

Warning

This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

• Padding example #334
• generate enabler column #333 👈 (View in Graphite)
• Move multiplicy column code to utils #332
• main

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

[ohad-starkware]

Reviewable status: 0 of 2 files reviewed, 1 unresolved discussion (waiting on @shaharsamocha7)

---

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

/// The padding column is a MultiplicityColumn with the first `padding_offset` elements set to 1 and
/// the rest set to 0.
pub fn gen_padding_column(log_size: usize, padding_offset: usize) -> MultiplicityColumn {

I don't think this should go through the MultiplicityColumn logic
can you just generate a vector of simd elements? I think it should also be faster (calloc, memwrite, fix one vector in the middle)

[ohad-starkware]

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

Previously, ohad-starkware (Ohad) wrote…

I don't think this should go through the MultiplicityColumn logic
can you just generate a vector of simd elements? I think it should also be faster (calloc, memwrite, fix one vector in the middle)

take only offset, the size is always next_power_of_2 right?
if not, logsize u32

[shaharsamocha7]

Reviewable status: 0 of 2 files reviewed, 1 unresolved discussion (waiting on @ohad-starkware)

---

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

Previously, ohad-starkware (Ohad) wrote…

take only offset, the size is always next_power_of_2 right?
if not, logsize u32

Do you think it matters in terms of efficiency?

I just wanted the simplest implementation that would be clear what it is.
Using MultiplicityColumn to generate the padding column is the most clear to me, WDYT?

[ohad-starkware]

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

Previously, shaharsamocha7 wrote…

Do you think it matters in terms of efficiency?

I just wanted the simplest implementation that would be clear what it is.
Using MultiplicityColumn to generate the padding column is the most clear to me, WDYT?

it doesn't matter
IMO the simplest implementation will be doing the simplest thing, take a 0zed column, write 1s in the range you want.
and you won't have to call into_simd_vec().
also, what happens if we delete MultiplicityColumn and keep only the atomic one?

[ohad-starkware]

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

Previously, ohad-starkware (Ohad) wrote…

it doesn't matter
IMO the simplest implementation will be doing the simplest thing, take a 0zed column, write 1s in the range you want.
and you won't have to call into_simd_vec().
also, what happens if we delete MultiplicityColumn and keep only the atomic one?

it doesn't matter in terms of efficiency*

[shaharsamocha7]

Reviewable status: 0 of 2 files reviewed, 1 unresolved discussion (waiting on @ohad-starkware)

---

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

Previously, ohad-starkware (Ohad) wrote…

it doesn't matter in terms of efficiency*

so you don't think of the padding column as a multiplicity column?
I'm willing to change the impl, do you have a better name for this function?

[ohad-starkware]

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

Previously, shaharsamocha7 wrote…

so you don't think of the padding column as a multiplicity column?
I'm willing to change the impl, do you have a better name for this function?

gen_enabler_column