1

On a judge platform, I encountered this problem, which I had wrong answer in 3 out of the 18 tests:

In the simultaneous equations

ax+by=c

dc+ey=f

x and y are unknowns. The coefficients a, b, c, d, e and f are integers. Each of the coefficients ranges from -2000 to 2000.

Write a program to read in the coefficients and solve for the unknowns of the corresponding simultaneous equations.

INPUT

The first and the only line contains six integers a, b, c, d, e and f separated by spaces.

OUTPUT

If there is exactly one solution, the first and the only line contains two numbers x and y, separated by a space, so that when they are substituted to the original equations, the set of simultaneous equations hold. If the set of simultaneous equations has no solution, display no solution. If the set of simultaneous equations has more than one solution, display many solutions. Assume that x and y are always integers.

So, this is my code:

#include<bits/stdc++.h>
using namespace std;
int det(int a,int b,int c,int d){
    return a*d-b*c;
}
int main(){
    int a,b,c,d,e,f,det1,detx,dety;
    cin >> a >> b >> c >> d >> e >> f;
    det1=det(a,b,d,e);
    detx=det(c,b,f,e);
    dety=det(a,c,d,f);
    if(det1==0){
        if(detx==0){
            cout << "many solutions";
        }
        else{
            cout << "no solution";
        }
    }
    else{
        cout << detx/det1 << ' ' << dety/det1;
    }
}

Can someone help me to debug this code?

Culver Kwan
  • 111
  • 5
  • 1
    Whatever you do, *never* use "competition" or "judge" sites as a way to learn programming. All you really learn from such sites are *really bad habits*. Of which you showcase a few in the code shown to us. For example, one-letter variables without significant meaning in their names and no explanation about what they do. No comments about what the code is doing or why. [That `#include`](https://stackoverflow.com/questions/31816095/why-should-i-not-include-bits-stdc-h). [That `using`](https://stackoverflow.com/questions/1452721/why-is-using-namespace-std-considered-bad-practice). – Some programmer dude Jan 16 '21 at 05:11
  • Have you tried stepping through the code for one wrong example input to see where it goes wrong? You can do this either using a debugger, or by inserting print statements everywhere you do a calculation, or using pen and paper. – John Zwinck Jan 16 '21 at 05:11
  • As for debugging, that's one thing no such site will ever teach, even though it's such an important and integral part of programming. And many such sites makes it hard or even impossible to debug, as they don't show the input given to your program (which is needed to be able to debug). Same thing with testing, which such sites never teach and which is also important, and much more advanced and non-trivial than just running the program with a simple sets of input. – Some programmer dude Jan 16 '21 at 05:12
  • @JohnZwinck I tried the example tests, which are all fine. – Culver Kwan Jan 16 '21 at 05:12
  • 1
    `detx/det1` can produce real numbers (float numerics). Your result is floored int. – 273K Jan 16 '21 at 05:12
  • 1
    @CulverKwan: You will need to come up with an example which fails. Perhaps you can write a test function which, given the `x` and `y` values your code calculates, checks whether they actually produce equalities for both equations for a range of values. – John Zwinck Jan 16 '21 at 05:14
  • @Someprogrammerdude I am in my school's coding team (first year) and the trainer told us to type```#include``` and ```using namespace std``` first in the code. – Culver Kwan Jan 16 '21 at 05:19
  • You're going to find the examples inputs are close to useless. Hidden in the real input sets are all sorts of abusive tricks intended to edge cases you're not likely to think of until you deeply explore the problem. The one thing you will learn from these competition problems is users are total bastards. Unfortunately this is tempered by the fact that the inputs sets go out of their way to not crash your program with horribly invalid inputs. In the real world the users not dropping typos are probably deliberately attacking the program to hijack your computer. Trust no one, – user4581301 Jan 16 '21 at 05:20
  • 1
    `#include` is false economy. The time saved on typing is eaten up in the order of magnitude difference in the time needed to compile the entire ing Standard library every time you build. If your program works first time, every time, you might win, but after two or three rebuilds you lost. Plus it turns your code into a minefield of identifiers you aren't using. Combine that with `using namespace std;` pulling all of those identifiers into the `std` namespace where it easily collides with your code and the danger level goes way, way up. – user4581301 Jan 16 '21 at 05:24
  • @CulverKwan "*In the simultaneous equations ...*" Are those the actual equations, or a typo? – dxiv Jan 16 '21 at 05:27
  • Per @S.M. change `int det(....)` to `double det(....)` and the variables the results are assigned to. – doug Jan 16 '21 at 06:40

1 Answers1

2

My big guess is that I do not understand the question. A linear equation system with 2 unknown looks normally different.

If this is really the question, then we can do the following:

ax+by=c
dc+ey=f

ey = f-dc
y=(f-dc)/e

ax = c-by
   = c-b((f-dc)/e)
   = c-b(f-dc)/e
   = c-(bf+bcd)/e
   = c-bf/e+bcd/e
 
x = c/a-bf/(ae)+bcd/(ae)
  = c/a-bf/a/e+bcd/a/e

So except with "e" or "a" being 0 there is always one deterministic solution.

That is so trivial, that I am nearly persuaded that I do not understand the question.

Even with a linear dependency of a<->dc b<->e nothing would change. Mabye

ax+by=c
dx+ey=f

was intended?

A M
  • 14,694
  • 5
  • 19
  • 44