From baron@cattell.psych.upenn.edu  Fri Jan 31 19:24:02 2003
From: baron@cattell.psych.upenn.edu (Jonathan Baron)
Date: Fri Jan 31 19:24:02 2003
Subject: [Rd] minor error in documentation of pmax in base (PR#2513)
In-Reply-To: <3A822319EB35174CA3714066D590DCD534BC0F@usrymx25.merck.com>; from andy_liaw@merck.com on Fri, Jan 31, 2003 at 01:02:51PM -0500
References: <3A822319EB35174CA3714066D590DCD534BC0F@usrymx25.merck.com>
Message-ID: <20030131132010.A17691@cattell.psych.upenn.edu>

On 01/31/03 13:02, Liaw, Andy wrote:
>> From: Jonathan Baron [mailto:baron@cattell.psych.upenn.edu]
>> 
>> In a way it is not surprising, but some functions that operate on
>> vectors will coerce their outputs into vectors and others won't.
>> For example, try
>> 
>> m1 <- array(1:24,c(2,3,4))
>> sort(m1)
>> order(m1)
>
>Now that I think a bit more about this example, I'm not sure if I like pmax
>and pmin to work as they do now.  What if one does the following:
>
>a1 <- array(1:24, 2:4)
>a2 <- array(24:1, 4:2)
>pmax(a1, a2)
>pmin(a1, a2)

The mind boggles!

>I don't know if there's a "natural" way to dimension the result in this
>case.  Seen from this perspective, my preference would actually be what
>sort() and order() do: drop the attribute.  If array is what's intended,
>then the user can do that coercion explicitly.
>
>Just my $0.02...
>Andy

order() drops the attributes, sort() does not!

Although I see the problem, my own preference is to keep pmax and
pmin as they are, and document it.  It took me a while to trust
my ability to put arrays back together after they became
vectors.  I think novices might appreciate not having to do this.

Jon



[Rd] minor error in documentation of pmax in base (PR#2513)
Jonathan Baron