Bug in "Stock Exchange Losses" puzzle?

I passed all of the unit tests for this puzzle. However, upon submission I failed one submission test:

The values were { 4 3 5 2 1 6 }
and I calculated the biggest loss to be -4.

However, the game says this is the wrong answer. It seems to me that 5, 2 creates the biggest loss at -4.

Could some one please explain what the answer to this submission test is–if it is not -4?

I haven’t done this puzzle in a while but surely a drop from 5 to 2 should be registered as -3, not -4 ?
In the examples there’s a drop from 5 to 1 marked -4.

Yes, my mistake, the drop from 5 to 1 should be -4. Then, why doesn’t that seem to get recognized by the tester?

I actually took my program and eliminated the reading in of input values. I set the values array to { 4 3 5 2 1 6 } and then ran my program. The answer was -4.

So although my program gives the correct answer in this case, the test validator does not match my results.

When you split your line into integers, do you get an erroneous last element ? We might have accidentally slipped in an invisible character at the end of that line. If not, feel free to send your code to coders@codingame.com so I can have a closer look at it.

As reported in main puzzle topic, first validation test input says there are 6 numbers but only 5 are given on the next line. I can confirm this behaviour as I was able to validate first test in PHP by:

  • outputting -$N + 2
  • outputting -count($numbers) + 1

So depending on the language and the algorithm, there might be indeed an erroneous last element because it doesn’t exist in input.

Why don’t you all simply ignore that?

Just put dump line read, then parse next line, strip it, get ints out of it, and go ahead for a solution.

Okay thanks everybody, I have corrected the validator. It should work properly now.
Keep me posted.

Julien.

I’m still seeing this issue. My code outputs a value of -4 for the first test, yet it’s still marked as incorrect even though clearly the max drop is 5 -> 1 == -4.

Can you share your code?
What language is it written in?

Are you sure no extra spaces are written?

What I eventually did was I submitted and the test failed. However, then I press the “Try Again” button and all of the tests pass. This was my solution.

I wrote my code in C++.

The solution was written in Java. I submitted it today without any changes and got a full 100% passed.

I have a problem with this puzzle in Go.
For ‘example 5’ the input seems to be empty, instead of the long list of big numbers expected.
In example 1 - 4 the input is there.

I’m not really familiar with go (yet) but maybe your issue is the same as this one Go issue puzlle ascii art

I don’t think it’s the same problem, since it works for example 1 - 4 with the same code.
The difference is that there’s a lot more data in example 5, so maybe it can’t handle that.

 fmt.Println(n)

When i do this on example 5, i get 99999, so the input is here.
Sometimes, when your code is to slow, you’ll see no output. Thatjust means that you got to speed up your code to not time out.

With this code to just print the input:

[code]package main

import “fmt”
import “os”
import “bufio”

func main() {
scanner := bufio.NewScanner(os.Stdin)

var n int
scanner.Scan()
fmt.Sscan(scanner.Text(),&n)
fmt.Fprintf(os.Stderr, "N: %d\n", n)

scanner.Scan()
input := scanner.Text()
fmt.Fprintf(os.Stderr, "Input: %s\n", input)

fmt.Println("answer") // Write answer to stdout

}[/code]

Output for example 1:
N: 6
Input: 3 2 4 2 1 5

Output for example 5:
N: 99999
Input:

So the logic to get the data should be fine, and since I don’t do any calculations or anything, the timeout problem should not be in my code.
For some reason the second line of input is never read properly.

ok so i tried again, and oddly, when i did this code:

func main() {
    scanner := bufio.NewScanner(os.Stdin)

    var n int
    scanner.Scan()
    fmt.Sscan(scanner.Text(),&n)
    
    scanner.Scan()
    vs := scanner.Text()
    
    fmt.Fprintln(os.Stderr, vs)
    scanner.Scan()
    mm := scanner.Text()
    
    fmt.Fprintln(os.Stderr, mm)
}

It worked for example 5. I dunno why but maybe it’s because you have to ignore the carriage return:

int main()
{
    int n;
    cin >> n; cin.ignore();
    string vs;
    getline(cin, vs);

    // Write an action using cout. DON'T FORGET THE "<< endl"
    // To debug: cerr << "Debug messages..." << endl;

    cout << "answer" << endl;
}

The important part here is cin.ignore();, is there an equivalent in Go?

I thought I tried making two scan calls to scanner, but apparently I made a mistake.
Your example get the text.
Well sort of, if you add fmt.Fprintln(os.Stderr, len(mm)) to your example you see that it only have 65536 characters. So there’s a 16-bit limitation somewhere here?

I’m pretty new to Go, so I can’t answer your question regarding cin.ignore.