# Find the largest and the smallest number in an array

The task is very simple. Given an array containing only integers and strings, output the largest number and the smallest number.

### Test Cases

Input: [1, 2, 3, 4, 5, 6, 7, 8]
Output: 1, 8

Input: [5, 4, 2, 9, 1, 10, 5]
Output: 1, 10

Input: [7, 8, 10, "Hello", 5, 5]
Output: 5, 10


Numbers in strings are not considered integers:

Input: [1, 2, 3, 4, "5"]
Output: 1, 4


If there is only one integer, it is both the largest and smallest integer:

Input: [1]
Output: 1, 1

Input: ["1", "2", "3", "4", 5]
Output: 5, 5


### Rules

• You can assume that an array will always contains at least one integer.
• All integers are positive (greater than 0)
• The order of the output doesn't matter.
• This is , so the submission with the least amount of bytes wins!
• Strings can contain all printable ASCII characters (32 - 126) and are non-empty.
• How are strings that contain quote marks represented in the input? – feersum Feb 5 '16 at 11:23
• @feersum Wouldn't that depend on your language? – Martin Ender Feb 5 '16 at 11:25
• @feersum With escape characters probably, but if the language doesn't handle that, that's okay. – Adnan Feb 5 '16 at 11:25
• @MartinBüttner If input is taken from stdin, it should not depend on what language is used. – feersum Feb 5 '16 at 13:31
• @feersum That's new to me. Even from STDIN [1, 2, 3] 1 2 3 and {1; 2; 3} are all valid input formats, so I don't see why it should be any different for string literals received from STDIN. – Martin Ender Feb 5 '16 at 13:33

## Python 3, 65 bytes

Here's the obligatory example of how Python 3 is worse (for golfing) than Python 2, because it got rid of weird behaviours, like "you can compare ints and strings, and all ints are less than all strings".

def m(a):b=sorted(n for n in a if type(n)==int);return b[0],b[-1]


# C#, 71 bytes

(object[]z)=>{var a=z.OfType<int>();return new int[]{a.Max(),a.Min()};};


Simple lambda which returns the min and max as an int array.

# PARI/GP, 52 bytes

This is terrible -- there has to be a better way to check if something is a number than type. polcoeff(eval(x),0) is even worse, despite (ab)using the requirement that numbers are positive. iferr(O(x);1,E,0) is clever but a byte longer: E is required for some reason, and p-adic numbers like O(3) are falsy (i.e., O(3)==0) so the ;1 is needed.

v->v=[x|x<-v,type(x)=="t_INT"];[vecmin(v),vecmax(v)]


An alternate approach is just as long:

v->[f([x|x<-v,type(x)=="t_INT"])|f<-[vecmin,vecmax]]


## Hoon, 90 84 bytes

|*
*
=+
(sort (skip ((list @) +<) (curr test 0)) lte)
[(snag 0 -) (snag 0 (flop -))]


This uses a couple fun features of Hoon:

• I'm returning a wet gate instead of a dry one to prevent having to specify the type. This makes the caller typecheck the function instead of definition, which is perfectly fine.

• The function argument for |= is an unnamed arm, which is placed in the subject at +<. Specifying a/* and using a as the input is longer than just leaving it unnamed and using +< directly

• The same thing applies for =+ - it places the variable at the top of the subject at -, so I save the sorted list as an intermediate and can reference it the three times needed cheaply

• The input specifies "All integers are positive (greater than 0)", which along with the fact the string will never be empty helps immensely. I can then slam the input through the type verifier gate (list @), which converts all entries in the list that aren't a number into 0 and then get rid of all zeros.

Example of use:

> %.  (limo ~[1 2 "hello" 9 17])
|*
*
=+
(sort (skip ((list @) +<) (curr test 0)) lte)
[(snag 0 -) (snag 0 (flop -))]
[1 17]