Re: C language binding of P1888 operations, especially min and max
The k-ary "min" and "max" are convenient,
they are nice in compiler implementation.
However, they are not so nice in library implementation.
The macro approach supplies solution only for a few k.
The array and vararg variants of "min" and "max"
looks different than other operations.
So I suggest to drop k-ary "min" and "max" from the standard.
and to keep in the required operations only binary "min(x,y)" and "max(x,y)".
This doesn't forbid implementations to implement them
(as well as k-ary versions of other associative operations "add", "mul")
but this will make API of library implementations cleaner.
-Dima
----- Исходное сообщение -----
От: bill@xxxxxxxxxxx
Кому: fateman@xxxxxxxxxxxx
Копия: fateman@xxxxxxxxx, mhack@xxxxxxx, stds-1788@xxxxxxxxxxxxxxxxx
Отправленные: Вторник, 8 Октябрь 2013 г 1:08:14 GMT +04:00 Абу-Даби, Маскат
Тема: Re: C language binding of P1888 operations, especially min and max
The attached pages from Sun/Oracle's documentation for its Fortran
implementation of interval data types might be informative.
See below.
On 10/6/13 4:50 PM, Richard Fateman wrote:
> On 10/6/2013 1:03 PM, Michel Hack wrote:
>>> So for each "k", it is necessary 2^(k+1) variants.
>>> This is a combinatoric explosure.
>>> How can I bind this in C ?
>> Input arguments can be widened to the widest-supported type. This avoids
>> combinatorial explosion; you only need one function per target type.
>> Several functions, including min/max, don't involve rounding, so you can
>> generate a wide result and round it once to the target type.
>>
>> Functions like min/max are often expressed as macros in C, again
>> avoiding
>> type issues. Indeed, macros using the compile-time built-in typeof()
>> can
>> provide the appearance of polymorphism.
>>
>> Michel.
>> ---Sent: 2013-10-06 20:09:50 UTC
> I think it is a mistake to require min or max of k arguments except
> for k=2.
>
> Presumably the macro expansion that Michel suggests requires only
> max2(a,b), and
>
> max(a,b,c,d) would be expanded to max2(a,max2(b,max2(c,d))) etc.
>
> Some languages will support the k-ary version, but why should the
> standard
> require languages to do so? Perhaps thereby excluding FORTRANs that may
> still be in use.
The Sun/Oracle Fortran implementation supports both more than 2
arguments and array arguments.
>
> If it is used in the form x := max(a,b) and the types of a,b,x are
> all different,
> do we (in effect) convert them all to the type of x to do the comparison?
> Does it even matter unless there is overflow in conversion?
The Sun/Oracle Fortran implementation uses widest need expression
evaluation to fully support mixed interval type expressions, wherein
every non-interval is promoted to a containing interval with the highest
kind-type-parameter-value (ktpv) prior to interval evaluation of the
given expression.
>
> I would expect that if a,b are intervals, that
> the return value of max(a,b) is either the memory location where a is
> stored
> or where b is stored. Not another location where there is a
> conversion of a or b
> to the type of x. But frankly I don't know what is intended here.
Containment sets resolve any ambiguity about the mathematical definition
of what must be contained in the interval evaluation of any expression
or function.
>
> Equality has an issue too.
> If we compute max(A,B) where A and B are structures which are
> intervals, and
> they are of the same type and have equal components, and max returns
> a pointer
> to one of them, which one? I suspect this can affect the efficiency
> of (say)
> an implementation of heapsort. Also, if they are equal because they are
> stored in the same location, what does max say, even if A=B=NAI.
See the definition of a containment set and the assignment statement
operator.
>
>
>
> So there are two items in this message:
>
> 1. How about just max_of_two_arguments(x1,x2) etc for min
Unnecessarily limited. However, I strongly support a permissive
interval standard in which the *only* requirement is to not violate the
containment constraint. Thus, any language implementation should be
permitted to implement the interval syntax and semantics of the interval
evaluation of any standard function in any way, provided only that
containment not be violated.
This is so elegant and so simple. :)
>
> 2. What really is returned?
Any interval enclosure of the given function's containment set. Speed
and width are quality of implementation features.
>
> Apologies if I am missing something that is already resolved.
On the contrary, you raise important and fundamental questions.
Cheers,
Bill
>
> RJF
>