Implement Range for OpStack

[cyberbono3]

Closes #322

[jan-ferdinand]

Thanks for taking this on! Unfortunately, there is a logic error in the implementation. The documentation of field stack on OpStack reads:

/// The underlying, actual stack. When manually accessing, be aware of reversed indexing:
/// while `op_stack[0]` is the top of the stack, `op_stack.stack[0]` is the lowest element in
/// the stack.

Consequently, accessing op_stack[0..2] (equivalent to op_stack.index(0..2) or op_stack.index_mut(0..2) depending on context and determined by the compiler) should give op_stack.stack[op_stack.stack.len() - 2..op_stack.stack.len()].reverse() or similar. Note that this probably (a) doesn't compile and (b) is likely to contain off-by-one errors.

[jan-ferdinand]

This file is only generated due to a bug in proptest. It has purposefully not been commited.

[cyberbono3]

I have added processor.txt into .gitignore. Does it sound good to you ?

[jan-ferdinand]

In this repository, we use an import granularity of item in order to trivialize git merging of imports.

[cyberbono3]

I have merged all std::ops imports together: use std::ops::{Index, IndexMut, Range, RangeInclusive};

[jan-ferdinand]

I think's it's cleaner to just use the underlying panics, should there be any:

• By not implementing these checks yourself, you cannot introduce logic bugs in them. Concretely, the range check in the impl Index<RangeInclusive<usize>> for OpStack looks suspiciously similar to the one in impl Index<Range<usize>> for OpStack.
• The panic's message will correctly reflect the kind of access violation. For example, if the range is invalid, the current implementation will display an error regarding range bounds, whereas rust's panic message reads “slice index starts at x but ends at y.”
• By dropping the manual bounds-check here people will see the accustomed message “index out of bounds: the len is x but the index is y.”
• The stacktrace will point to the relevant method in either case.

[cyberbono3]

@jan-ferdinand Sorry for delay. Thanks for your clarifications. Any thoughts on my update?

[jan-ferdinand]

The name does not really describe what the function does. A better name could be flip_range, indicating that the range is mirrored or flipped along the “length” axis. There might be better names yet.

Furthermore, I don't think the special cases are necessary since they all collapse into the general case.

fn flip_range(start: usize, end: usize, len: usize) -> (usize, usize) {
    (len - end, len - start)
}

[jan-ferdinand]

That's the wrong way around. 🙂 You've applied item granularity “module”, whereas granularity “item” results in one line per used type. See also here.

[jan-ferdinand]

That's a creative way of solving this. 😃 However, I feel uncomfortable with consciously introducing memory leaks.

The approach you take here indicates to me that implementing Index<Range<_>> for OpStack requires refactoring OpStack such that the internal field stack is always in the correct order, for example using a VecDeque. It's probably a good idea to make the field non-public at the same time. Please let me know if this is too much scope creep. 😌

[cyberbono3]

Introduction of VecDeque sounds a good idea.

pub struct OpStack {
    pub stack: VecDeque<BFieldElement>,

    underflow_io_sequence: Vec<UnderflowIO>,
}

impl OpStack {
    pub fn new(program_digest: Digest) -> Self {
        let mut stack = VecDeque::with_capacity(OpStackElement::COUNT);
        stack.extend(program_digest.values());

        Self {
            stack,
            underflow_io_sequence: vec![],
        }
    }

In this case we do not reverse program_digest and set self.stack[0] is a top of the stack.

Additionally, we can update OpStack.push, OpStack.pop to add new item to the beginning of the stack and remove item from the beginning of the stack, respectively. Vec<BFieldElement> lacks this functionality.

  pub fn push(&mut self, element: BFieldElement) {
        self.stack.push_front(element);
        self.record_underflow_io(UnderflowIO::Write);
    }

    pub fn pop(&mut self) -> Result<BFieldElement> {
        self.record_underflow_io(UnderflowIO::Read);
        self.stack.pop_front().ok_or(OpStackError::TooShallow)
    }

    pub fn insert(&mut self, index: OpStackElement, element: BFieldElement) {
        let insertion_index = usize::from(index);
        self.stack.insert(insertion_index, element);
        self.record_underflow_io(UnderflowIO::Write);
    }

Index<Range<usize>> for OpStack can be implemented like that :

impl Index<Range<usize>> for OpStack {
    type Output = [BFieldElement];

    fn index(&self, range: Range<usize>) -> &Self::Output {
        &self.stack.as_slices().0[range.start..range.end]
    }
}

I wonder if this make sense.