Why does GreaterThan not have a scale parameter.

[Mickanos]

Hello,
I am still exploring the code of ezkl, and I was curious about why does the GreaterThan LookupOp not include a scale parameter.

From tensor::ops, we find:

    pub fn greater_than(a: &Tensor<i128>, b: f64) -> Tensor<i128> {
        // calculate value of output
        let mut output: Tensor<i128> = a.clone();

        for (i, a_i) in a.iter().enumerate() {
            output[i] = if (*a_i as f64 - b) <= 0_f64 {
                0_i128
            } else {
                1_i128
            };
        }
        output
    }

Since the values are not rescaled, it seems that the input is compared in whatever scale it comes in to the same float value a. So, the same Onnx node plugged at different places of the circuit may have different behaviours, depending on the scale of inputs, but I don't think the intent is for it to behave that way.

The operation could also adapt to the scale by rescaling the parameter a. This would have to happen in circuit::ops::lookup::rescale, but there the relevant code is as follows:

LookupOp::GreaterThan { .. } => Box::new(self.clone())

Is GreaterThan intended to work without rescaling? Or is there a place in the code that handles that and which I missed?

[alexander-camuto]

Hey @Mickanos. Thank you for your question :)

The output of GreaterThan is essentially a Boolean mask, which should correspond to 0s and 1s at any scale.

We mostly use the op to mask the output of other operations. For instance, say you wanted to filter x for any values less than 0. The idea would be to calculate the following:

x * greater_than(x,0)

The greater than mask only serves its function if it is composed of 0s and 1s (not of rescaled integers).

Another added benefit is that

x * greater_than(x,0)

has the same scale as x so we don't get the increase in scale one usually gets with multiplication.

Part of the reason this is good is that we want to keep scale down such that the inputs to any subsequent lookup table can be found in range.

Tldr: Large compounding scales create big numbers which can fall out of range of a lookup table

[Mickanos]

Thank you for your reply.

What I meant to ask was more that the result of the comparison x>a depends on the scale of x, while the value of a is fixed. If you use GreaterThan(x,0) this is obviously fine, but if you were to use GreaterThan(x,2), you might get a different result depending on whether the previous operation outputs something at scale 7 or at scale 14, even if the value of x (as a variable in the Onnx graph) is the same.

Did you mean that you essentially just use GreaterThan(x,0), so this is not a problem?

[alexander-camuto]

Ahhh gotcha :) yeah currently just use greater than 0 (for PreLU) but can definitely generalize it to other scales if required. Is that something you need atm ? can roll it out if you want

[Mickanos]

Actually, the applications that I have in mind would only require to use greater_than(x,0), so this is fine for me. I just got curious while inspecting the code.

Thank you for clarifying! :)

[alexander-camuto]

Hey @Mickanos added it to #213 . Should be merged imminently. Hope that helps :)