For now, I've decided not to redefine interval-scale and array-sample,
it seems to complicate how to explain the procedures.  I'll see how to
simplify my image processing codes with the current definitions.

Brad

On 9/21/26 21:01, Bradley Lucier wrote:
> Currently if an interval is defined as
>
> (define Int (make-interval (vector u_0 u_1 ... u_d)))
>
> (so Int has all zero lower bounds) and
>
> (define S (vector s_0 s_1 ... s_d))
>
> is a vector of positive exact integers, then (interval-scale Int S) is
> currently given by
>
> (make-interval (vector (ceiling-quotient u_0 s_0) ... (ceiling-quotient
> u_d s_d)))
>
> If u_k is positive, then (ceiling-quotient u_k s_k) is positive, so if 0
> is a valid kth index of Int, it's a valid kth index of (interval-scale
> Int S).
>
> This means that if 0 ... 0 (d times) is a valid multi-index of Int
> (i.e., Int is nonempty) then the same multi-index is valid for the
> scaled interval result (no matter the values in S).
>
> Unfortunately, this doesn't match the needs of the algorithms I know
> that use interval-scale and array-sample, which are multi-scale image
> processing algorithms in 2, 3, and 4 (space and time) dimensions.
>
> These algorithms need the scaled interval to be
>
> (make-interval (vector (floor-quotient u_0 s_0) ... (floor-quotient u_d
> s_d)))
>
> This means that the scaled interval might be empty even when the input
> interval is nonempty, but in the algorithms I know this is how things
> should be.
>
> I'm soliciting comments about whether I should add this change to what I
> call SRFI 231-bis, where I'm polishing SRFI 231:
>
>   https://github.com/gambiteer/srfi-231/tree/231-bis
>
> In particular, I'd be very interested to hear about algorithms that rely
> on the current definition.
>
> Brad