# Write better code: Day 1 - Highest Product

###
Arjun Rajkumar
*Updated on *
・1 min read

This post originally appeared on Arjun Rajkumar's blog. Arjun is a web developer based in Bangalore, India.

--

### Day 1: Question 2

Given an array of integers, find the highest product you can get from three of the integers.

The input array_of_ints will always have at least three integers.

If you want to follow along, feel free to post your answers below.

My answers are in the comments.

Classic DEV Post from Oct 31 '18

This was the logic:

## Examples:

[10, 7, 5, 8, 11, 9] -> 990 ;

[10, 7, 100] -> 7000 ;

[-10, 7, 100] -> -7000;

[-10, 7, 100, 1] -> 700;

Github

I feel like much less comparisons can be done by keeping track of the lowest number:

Sorry, I replaced one language I don't know with a similar language I don't know because I didn't want to install ruby.

Thanks Mihail. This looks much more neat. Will test it out later.

But did you test the case if two negative numbers are passed?

For e.g [-5, -4, 1, 3, 2] -> should give 60.

Yes, I see the problem.

So far I see three cases:

The biggest product is negative itself(!), which can happen in at least these two distinct cases:`[n,p,p]`

: There are only 3 inputs, one of them negative. For any length 3 input we should just return the input anyway, implicitly or explicitly.`[n,n,n...]`

: There are 3 or more inputs, none of which are positive. In this case we should return the 3 negative numbers closest to 0 (3 biggest numbers, same as the all-positive happy case)I'll post a fix later, let's see how messy.

Okay, I think I got it:

If we instead explicitly return the product of 3 inputs, this condition is no longer needed:

Another possible optimization, for input such as

`[...-100,-99,-98,-97,1,-96,-95,-94...]`

is to stop expecting the "all negatives" case. This can easily be done by resetting all negative maxes to 0, so that incoming negatives are always smaller:Just realised that my original attempt was wrong !

For two negative integers e.g [-5, -4, 1, 3, 2] the correct answer is 60.

But the code above gives 6.

So.. need to change.

Ended up doing this by checking if the product of current number with the previous stored two numbers is greater than the the current max.

Had to store 5 variables:

Then with each new number I check if the max product is greater than previous, and also update each. As there are negative numbers, the lowest product of two numbers can suddenly give the max product when multiplied with the current.

This is O[n] which is still better than sort which is O[nlogn]

Will you believe me if I tell you that I didn't see this comment thread until now (well after posting my fixed solution)?

Ofcourse :) Only then would you have tried solving it twice and with a different logic.