<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Presently, I'm implementing operations for a WASM emulator/runtime, so it's more a case of transitively acquiring use cases from WASM, though I'm also doing this specifically to practice accomplishing useful things with the vector API.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Regarding saturating arithmetic: WASM has operations for that as well (both signed and unsigned), so on that basis alone it would be a welcome addition as far as I'm concerned. FWIW, another simple use case for saturating arithmetic is audio processing/mixing (when processing many channels at once) because saturation closely matches analog clipping, and also perhaps image compositing for similar reasons.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Apr 18, 2024 at 1:40 PM Paul Sandoz <<a href="mailto:paul.sandoz@oracle.com">paul.sandoz@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi David,<br>
<br>
It’s not at all outlandish, but would caution it's more work than one might initially think.<br>
<br>
Could you describe a little more about your use case? that can be helpful to understand the larger picture and demand. Using unsigned comparison would be my recommended approach with the current API. CC'ing Sandhya for her opinion.<br>
<br>
Generally when we add new Vector operations we also consider the impact on the scalar types and try to fill any gaps there, so the vector operation behavior is composed from the scalar operation behavior (so like you indicated regarding symmetry). <br>
<br>
We are seeing demand for saturated arithmetic primarily for vector (not “vector” as in hardware vector) search, so we may do something there for specific integral types.<br>
<br>
Paul.<br>
<br>
> On Apr 17, 2024, at 7:13 AM, David Lloyd <<a href="mailto:david.lloyd@redhat.com" target="_blank">david.lloyd@redhat.com</a>> wrote:<br>
> <br>
> I've been trying the the incubating Vector API and one thing I've missed on integer-typed vectors is having unsigned min/max operations. There is a signed min/max operation, and unsigned comparison, but no unsigned min/max.<br>
> <br>
> I guess this is for symmetry with `Math`, which only has signed `min`/`max`. However, I would point out that while it's not very hard to implement one's own unsigned min/max for integer types using `compareUnsigned`, it is a bit harder to do so with vectors. The best I've come up with is to take one of two approaches:<br>
> <br>
> 1. Zero-extend the vector to the next-larger size, perform the min/max, and reduce it back down again, or<br>
> 2. Add <IntType>.MIN_VALUE, min/max with a value or vector also offset by <IntType>.MIN_VALUE, and then subtract the offset again<br>
> <br>
> I guess a third approach could be to do a comparison using unsigned compares, and then use the resultant vector mask to select items from the original two vectors, but I didn't bother to work out this solution given I already had the other two options.<br>
> <br>
> Would it be feasible to add unsigned min/max operations for vectors? It looks like at least AArch64 has support for this as a single instruction, so it doesn't seem too outlandish.<br>
> <br>
> And as a separate (but related) question, what about `Math.minUnsigned`/`Math.maxUnsigned` of `int` and `long` for symmetry?<br>
> <br>
> -- <br>
> - DML • he/him<br>
<br>
</blockquote></div><br clear="all"><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr">- DML • he/him<br></div></div></div>