Describe this image as best as you can

>largest(2, 2, 3) returns [2, 2]

First, it should be called "most" instead of largest. Second, there's only 3 more returns than there needs to be, so it's not too bad. 7.5/10

sort([x,y,z], reverse=True])[0]

>returns two different types (string and list)
>elif when if will do, since it's all returns
>10x longer than it needs to be
>needlessly complicated
>only accepts 3 values instead of an arbitrary list
>if x = y, but z is larger, then it still returns [x,y]
>if x = z, but y is larger, then it still returns [x,z]
>if y = z, but x is larger, then it still returns [y,z]

Attached: 1519779464557.jpg (600x550, 81K)

No it doesn't. It returns [x, y] when z > x == y.

Pain
Agony

This is a pure functional program you utter retard

You don't get a list in that case.

>>> def largest(x,y,z):
l = max([x,y,z])
return [l] * [x,y,z].count(l)
...
>>> print(largest(3,2,3))
[3, 3]

Why?

Nothing came as close to the elegance of this in the /sci/ thread.

Wrong.
In Haskell,
largest x y z = max x (max y z)

Proper way to do this: (NB: always returning arrays to make it less retarded)

if(x == y) {
return y == z ? [x,y,z] : ( x > z ? [x,y] : [z])
} else if (x > y) {
return x == z ? [x,z] : (x > z ? [x] : [z])
} else {
return y == z ? [y,z] : (y > z ? [y] : [z])
}

Don't listen to him.
It makes it harder to read.

Ok, I suck. Time to study and left this place...

incorrect

x=5, y=5, z=10

result would be [5, 5]

someone needs to learn loop logic.

This. It returns either doubles or triples and if all numbers are unique it returns the largest value.

>not unrolling your loops completely for optimal performance

impossible if the number of iterations is determined at runtime

Will that return an array if multiple at the same, say 5, 5, 5?

>not coding exclusively in assembly for even better performance

Dynamic typing was a mistake

types are a social construct, don't be a bigot shitlord. an int can identify as a float if it wants to.

>coding in c+=

non-functional case tree

100% this

a programmer decides mentally what types each of their variables should be when they write code. throwing away that information by automatically deducing types at runtime is fucking stupid

>hurr hurr noobs will get confused if they have to declare types themselves! we should make the interpreter assign types automatically, making it harder to actually debug your code!
what a fucking mess. who thought this was a good idea?

and don't get me started on weak typing or the absolute abomination known as duck typing

>duck typing
the hell is that

difficult to debug and use since it fucking returns differently typed values.

Types : the training wheels of programming languages.

Stop posting this thread and fuck off back to /sci/

everyone says this until they have to maintain a 500k LOC python abomination with a variety of undocumented custom shit.

Your code completion engine could at least help you a little in strongly typed languages because they actually provide useful type information in the source code, but you're 100% fucked in dynamic languages

that's what docstrings are for though, really. I honestly haven't seen any major project with significant type issues.

>docstrings as a replacement for type information
i strongly dislike that idea, but it would work half decently if the programmers were extremely vigilant with including type information in their docstrings in the correct format, all the time.

But this unfortunately doesn't happen in industry, especially on a time crunch before a deadline

It returns variables that are the same value, or the one that is the largest.

I'd also add type checking at all public interface entry points of your modules. It assuages the issue to some degree.

>if it looks like a duck and quacks like a duck, then it's a duck

>i strongly dislike that idea

meh. it just comes with the territory in these shit langs like javascript, etc.

metatyping and shiet.

>if the programmers were extremely vigilant with including type information in their docstrings in the correct format, all the time.

literally what? if the shit doesn't return what is documented then there is a bug anyhow. this is literally a nonissue. the only real issue here is that someone's CI doesn't make sure the documentation has syntax errors.

>pajeet code
>functional
Whatever you say, Rajesh...

CompSci degree

[ $# -lt 1 ] && exit -1

max=$1
shift

for n in $@; do
if [ $n -eq $max ]; then
max=$n
let c++
elif [ $n -gt $max ]; then
max=$n
c=0
fi
done

for (( i=0; i

>Not knowing what he means when he says "functional"
Time to end your life

I don't think that word means what you think it means user.

Nice

Attached: 1423869553038.jpg (1200x797, 405K)

...

int ret = x;
if (y > ret)
ret = y;
if (z > ret)
ret = z;
return ret;

This should be a 2 argument function to reduce it to 3 checks, or take a list as argument. Not this garbage.

not him, that just returns the largest of 3 numbers. normal haskell would be
largest ls = filter (== maximum ls) ls

Guys.
>x > y > z
This doesn't actually work correctly, does it?

Look again.
largest(1, 1, 2) == [1, 1]

perfect

>cs grads

That doesn't do half of what the function is doing (returning a list with multiple values if it occurs multiple times).

function largest(x, y, z) {
let ret = [x];
for (const val of [y, z]) {
if (val === ret[0]) {
ret.push(val);
} else if (val > ret[0]) {
ret = [val];
}
}
return ret;
}

template
T largest(const std::vector& v) {
return std::max_element(v.begin(), v.end());
}

or any container that provide .begin() and .end(), or the pointer at the beginning of the array and a pointer one element past the last if you use C-style arrays

Or, naive method if you want to do it by hand
template T largest(std::vector a) {
auto res = a[0];
for(auto n : a)
if(n > res)
n = res;
return res;
}

And if you insist on the three integer arguments
int largest(int a, int b, int c) {
if(a > b)
return (a > c) ? a : c;
return (b > c) ? b : c;
}

int largest(int x, int y){
if(x > y){
return x;
}else if(y > x){
return y;
}else{
return x;
}
}

do largest(largest(x, y), z); to get result of 3 variables

Is this code from Yandere Simulator?

Attached: 1376605441822.jpg (1280x720, 209K)

You can save lines and speed by writing it like so:

int largest(int x, int y) {
if(x >= y) {
return x;
}
return y;
}

(or just if(x > y), it works too)

def largest(*args):
l = max(args)
return [l] * args.count(l)

You can make it unary if you wanted, but I wanted to keep the intent clear. Something as trivial as this shouldn't cause performance issues.

if (x > y)? return x : return y;

I mean ternary lol

Even better. I don't know that I've ever formatted the args in such a retarded way as the OP, so I didn't even think of doing it that way.

Yep indeed, and even shorten it even more
return (x > y) ? x : y;

But I see your point

Attached: file.png (676x317, 32K)

Thinking about it a little more, why the fuck would you need a list with 2/3 objects if they were "equal?" If they're primitives, it's even more pointless.

def largest(x, y, z):
values = [x, y, z].sort()
result = [ values[-1] ]
for i in results[:-1]:
if i == result[0]:
result.append(i)
# you could just return a list but whatever
if len(result) == 1:
return result[0]
return result

what in gods name are you trying to do here

Exactly what the function intends. But I admit is the most elegant and is the most efficient (although it doesn't do that retarded thing where it changes int to list if the value occurs more than once, but that's fixable without increasing complexity).

how can a functional advocate be this stupid?

you're just making it harder for the rest of us

/sci/ loves to shit all over CS and call it easy but couldn't program their way out of a paper bag

Actually I'm going to fix to make it exactly what OP wants and still be the most efficient, single-iteration algorithm:
def largest(x, y, z):
result = [ x ]
for val in [y, z]:
if val == result[0]:
result.append(val)
elif val > result[0]:
result = [ val ]
if len(result) == 1:
return result[0]
return result

beautiful

Post #66111431: 0.767340898514 usec
Post #66113263: 0.682909965515 usec
Post #66113455: 0.775645017624 usec

"Works but there is a simpler way".png

Sure, but does 2 iterations, one for max and one for count. From a purely CS algorithm-on-paper standpoint, is the best.

I like it
def largest(*args):
result = [ args[0] ]
for val in [args[1:]:
if val == result[0]:
result.append(val)
elif val > result[0]:
result = [ val ]
if len(result) == 1:
return result[0]
return result

From an algorithm-on-paper standpoint, your function is a nightmare hellscape compared to and . It's slower, more bloated (400% bigger!), more complicated to debug and modify, etc

Reinventing the wheel isn't a plus.

>It's slower, more bloated (400% bigger!), more complicated to debug and modify
All of these issues are language-dependent and have zero to do with specification. From an algorithmic standpoint, it's the best because it only iterates once. Both the other iterate twice.

Your concerns have to do with implementation. You don't seem to know what algorithm-on-paper means.

>All of these issues are language-dependent and have zero to do with specification
The problem in question is python. If you aren't going to use the features of python, why bother?

>From an algorithmic standpoint, it's the best because it only iterates once. Both the other iterate twice. Your concerns have to do with implementation. You don't seem to know what algorithm-on-paper means.
My concerns are with efficiency. Having less iterations is good, but not if the result is a slower, bloated, buggier piece of code.

just uh write a simple typesystem. like C but less retard. inside your code, get it?

There's a missing close bracket on line 3
for val in [args[1:]:

Also
>>> def largest(*args):
... result = [ args[0] ]
... for val in [args[1:]]:
... if val == result[0]:
... result.append(val)
... elif val > result[0]:
... result = [ val ]
... if len(result) == 1:
... return result[0]
... return result
...
>>> largest(1,2,3)
(2, 3)

>The problem in question is python.
I never said my solution was the most efficient in Python, I said it was the most efficient on-paper algorithm.

Algorithmia doesn't give 2 shits what language you're using. If you're here to argue that using sort(), max() and count() are easier ways and your boss at whatever consulting company you work for will be happier, and even that those others run faster, I'll agree. But I'm thinking about something I could ask my students to do. Like tell them the problem is solvable in 1 iteration without using built-in functions and ask them to come up with a solution.

But hey mate, if you're going to argue efficiency in terms of measurable runtime, I'm going to ask why are you even using Python in the first place.

>conditionally returns different data types based on the very same condition you're trying to test
python was a mistake

If you are teaching your students to do things in a more complicated, buggy way that isn't expandable and harder to debug, then you are the problem with modern programming.

Thanks, fixed. The result was on line 3, where args[1:] was being packed into another list, and the eval was basically comparing a list to an int.
def largest(*args):
result = [ args[0] ]
for val in args[1:]:
if val == result[0]:
result.append(val)
elif val > result[0]:
result = [ val ]
if len(result) == 1:
return result[0]
return result

>>>largest(1,2,3)
3
>>>print(largest(1,2,4,3,7,2,7)
[7, 7]

I'm teaching my students to create algorithms, not to create algorithms using Python. My algorithm is better, even if in this particular language it runs slower.
Also, you're using an input of size 3. If you're going to be a little bitch about runtime, give it something in the order of 10^4 that second iteration and tell me how that second iteration is working for you.

You should teach the cost of operations too and not get them blinded by the sole fact that it iterates once. There's a ton of ifs goddamnit, it's an unreadable, inefficient, overly complicated and utterly useless function. You should know from Python that there should ideally be one obvious way to do things, and yours isn't mate. Especially in a educational context.

Mate have you ever opened an algorithms book? Most of the ones we still use were written when Lisp was the big thing in CS. They never care about size as long as it provides the best efficiency, and they definitely don't care which language some codemonkey is going to implement it on.

>inefficient
Can't help but notice that you're still judging my algorithm's efficiency based on a size 3 input...
Go on, fire up /dev/random, fill an array with 10 million values and compare all 3 solutions. Because my solution is slower because max() and count() have C implementations and mine is basically pure python which is slower, but when you start dealing with larger inputs that gets less and less important.

No I'm judging it on the cost of branches and list insertions. The obvious way is to do a lt on each entry, keeping the highest number in one variable and incrementing a counter on identicals, reseting it to 1 on new max. Then return [max]*count if count isn't 1 otherwise max.

The len for arbitrarily large arrays is O(n) too, so that ain't good.