On Wed, Nov 9, 2022 at 1:48 PM Jakub Jelinek <ja...@redhat.com> wrote: > > On Wed, Nov 09, 2022 at 08:07:57AM +0100, Aldy Hernandez wrote: > > The PLUS_EXPR was always meant to be a template for further > > development, since most of the binary operators will share a similar > > structure. This patch abstracts out the common bits into the default > > definition for range_operator_float::fold_range() and provides an > > rv_fold() to be implemented by the individual entries wishing to use > > the generic folder. This is akin to what we do with fold_range() and > > wi_fold() in the integer version of range-ops. > > Shouldn't foperator_mult be very similar to this (except that until > division is done op[12]_range can't be implemented), with the exception > that the invalid case isn't -INF + INF or INF + -INF, but > 0 * +/-INF or +/-INF * 0?
Multiplication and division are tricky because you have to keep track of signs to order the resulting range. It's the most annoying pattern we have for integers: // Multiplications, divisions and shifts are a bit tricky to handle, // depending on the mix of signs we have in the two ranges, we need to // operate on different values to get the minimum and maximum values // for the new range. One approach is to figure out all the // variations of range combinations and do the operations. // // However, this involves several calls to compare_values and it is // pretty convoluted. It's simpler to do the 4 operations (MIN0 OP // MIN1, MIN0 OP MAX1, MAX0 OP MIN1 and MAX0 OP MAX0 OP MAX1) and then // figure the smallest and largest values to form the new range. But if you have a simpler approach, have at it. I may have to bail on multiplication and division for this cycle, cause I'm running out of cycles :-/. Hmmm...even if we don't get to implement mult/div in this cycle, perhaps we could at least figure out if we'll NAN as you've suggested above. So, set [-INF,+INF] but without a NAN when applicable. Aldy
