Wages not calculating correctly

[Simfonika Island]

Hi

My program is not calculating the wages correctly. Can somebody please
tell me why???

/*
* PayCheck Program
* This program computes an employee's wages for the week
*/
import java.util.Scanner;
import static java.lang.System.in;
import static java.lang.System.out;

class mainPayCheckProg
{
public static void main(String args[])
{
// create an instance of the class or object
payCheckMethods aWage = new payCheckMethods();

Scanner prompt_user = new Scanner(in);

double payRate;
double hours;
double wages;
int empNum;

double max_hours = 40.0;
double overtime = 1.5;

out.print("Enter Employee Number: ");
empNum = prompt_user.nextInt();
out.print("Enter Pay Rate: ");
payRate = prompt_user.nextDouble();
out.print("Enter Hours Worked: ");
hours = prompt_user.nextDouble();

if (hours > max_hours)
{
wages = (max_hours * payRate) + (hours - max_hours) * payRate *
overtime;
}
else
{
wages = max_hours * payRate;
}

out.print("Employee Number: ");
out.println(empNum);
out.print("Pay rate: ");
out.println(payRate);
out.print("Hours worked: ");
out.println(hours);
out.print("Wages: ");
out.println(wages);
}
}

[Gene Wirchenko]

On Wed, 18 Apr 2012 13:53:39 -0700 (PDT), Simfonika Island
<simf...@gmail.com> wrote:

>My program is not calculating the wages correctly. Can somebody please
>tell me why???

Yes, but you need to figure it out. I have given a big clue.

[snip]

>double overtime = 1.5;
^^^^^^^^
Bad name. It is an overtime *rate*.

[snip]

>wages = max_hours * payRate;

^^^^^^^^^
Why are using this variable here?

[snip]

If you are not indenting your code, you should.

Sincerely,

Gene Wirchenko

[Roedy Green]

On Wed, 18 Apr 2012 13:53:39 -0700 (PDT), Simfonika Island

<simf...@gmail.com> wrote, quoted or indirectly quoted someone who
said :

>My program is not calculating the wages correctly. Can somebody please
>tell me why???

See http://mindprod.com/jgloss/ide.html

If you single step trace you program, the problem should quickly
reveal itself.

If for some reason that is not possible, try running the program on
paper calculating each line as written. Look for anomalous results.
Make sure you compute what the program SAYS not what you intended.
--
Roedy Green Canadian Mind Products
http://mindprod.com
When you were a child, if you did your own experiment
to see if it was better to put to cocoa into your cup first
or the hot milk first, then you likely have the programmer gene..

[Leif Roar Moldskred]

Roedy Green <see_w...@mindprod.com.invalid> wrote:
> On Wed, 18 Apr 2012 13:53:39 -0700 (PDT), Simfonika Island
> <simf...@gmail.com> wrote, quoted or indirectly quoted someone who
> said :
>
>>My program is not calculating the wages correctly. Can somebody please
>>tell me why???
>
> See http://mindprod.com/jgloss/ide.html
>
> If you single step trace you program, the problem should quickly
> reveal itself.

That's a terrible piece of advice to give to a beginning
programmer. Interactive debuggers are useful tools, but you will waste
a lot of time with them if they're the first thing you reach for when
you find a bug.

_Think_ about the bug. What type of bug is it? What's the failure
modes? Is it consistent? Does it occur for all inputs, or just some?
Is it timing based? Does it involve databases, network access or third
party libraries? Read the logs (if you have them, and if not, put some
in). Read the code. Locate the bug: Where in the code does the bug
become visible? Where does it manifest? Where could it have been
introduced? Divide and conquer -- which parts of the code have
nothing to do with the bug, and which parts remain? Did it use to work
before? (Are you certain?) What has changed since then? Is the program
environment still the same? The build process? The dependencies?

Still don't know what causes the bug? Fine, _then_ you can fire up the
debugger. By now you should at least have a good idea of where the bug
_isn't_, so you can concentrate on the parts that remain.

--
Leif Roar Moldskred

[Lew]

Simfonika Island wrote:
> My program is not calculating the wages correctly. Can somebody please
> tell me why???
>
> /*
> * PayCheck Program
> * This program computes an employee's wages for the week
> */
> import java.util.Scanner;
> import static java.lang.System.in;

You don't need to specify the 'java.lang'.

Others have highlighted nicely the areas you ought to investigate closely. The
example apparently is an academic exercise, and as such the key word is
"exercise", meaning you actually have to work it yourself, and that's why the
responses were somewhat indirect. They are helping you. Rest assured that if
you follow through on their hints you will see the source of the difficulty.

This is the universal phenomenon of computer programming, and a skill you will
be glad you've mastered - that of digging to the root cause of what you observe.

In this case you will come to an understanding of how variables convey
information, or more precisely, data, or more precisely still for Java in
particular, pointers to data and some primitives. Gene Wirchenko even gave you
a starting point.

Roedy's advice to paper-fake the program is a foundational practice.

There's also precision of how you report an anomaly. There are useful
debugging strategies that move you quickly to enlightenment and good software.
The first is to report all observations surrounding the anomaly.

For example, you observed that the "program is not calculating the wages
correctly". OK. That's not a lot of analysis yet. What exactly is the program
calculating (copy and paste actual output)? What did you expect?

This is the heart of program testing - at its simplest, a pairing-up ("map")
of preconditions and results (inputs and outputs). You type in "blahblah", the
program prints "bleepbleep". You expected "bloopbloop". That begins to be
specific.

At that point, you see from the code how that "bleepbleep" got calculated as
you trace how the variables transform their referenced structures. Or in your
case, primitive 'double's.

By the way, you should declare the class 'public'.

Lastly, there are coding conventions. They differ, even to being opposite,
between computer languages. They cover naming, spelling, indentation, all that
boring (not really) crap. For Java they start with (and for a lot of folks,
end with)
<http://www.oracle.com/technetwork/java/codeconv-138413.html>

Some of the conventions, like declaring arrays with the brackets after the
type, or the variable, but not both, are in the Java Language Specification
(JLS) itself.
<http://docs.oracle.com/javase/specs/jls/se7/html/index.html>
<http://docs.oracle.com/javase/specs/jls/se7/html/jls-10.html#jls-10.2>
'We do not recommend "mixed notation" in an array variable declaration, where
brackets appear on both the type and in declarators.'

Generally you see the brackets on the type in Java code.

--
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg

[Roedy Green]

On Thu, 19 Apr 2012 00:58:34 -0500, Leif Roar Moldskred
<le...@dimnakorr.com> wrote, quoted or indirectly quoted someone who
said :

>That's a terrible piece of advice to give to a beginning
>programmer

I disagree for four reasons:

1. for a short piece of linear code, that is a very quick way to find
a bug.

2. It greatly helps a newbie to watch ANY program single stepping
away, to get a feel for how programs behave, where they spend their
time. You see thing that make you do a double take you would never
notice any other way. Resolving them, nearly always as benign
improves your intuition.

3. his problem is a logic error, not a coding error. Paper tracing
will uncover it, even if he is very weak in coding.

4. I think our student is just getting started. Throwing academic or
abstract concepts at him at this stage I think would be too
overwhelming.

[Jake Jarvis]

On 19.04.2012 10:43, wrote Roedy Green:
> On Thu, 19 Apr 2012 00:58:34 -0500, Leif Roar Moldskred
> <le...@dimnakorr.com> wrote, quoted or indirectly quoted someone who
> said :
>
>> That's a terrible piece of advice to give to a beginning
>> programmer
>
> I disagree for four reasons:
>
> 1. for a short piece of linear code, that is a very quick way to find
> a bug.
>
> 2. It greatly helps a newbie to watch ANY program single stepping
> away, to get a feel for how programs behave, where they spend their
> time. You see thing that make you do a double take you would never
> notice any other way. Resolving them, nearly always as benign
> improves your intuition.
>
> 3. his problem is a logic error, not a coding error. Paper tracing
> will uncover it, even if he is very weak in coding.
>
> 4. I think our student is just getting started. Throwing academic or
> abstract concepts at him at this stage I think would be too
> overwhelming.

You two are at cross-purposes.

--
Jake Jarvis

[Gene Wirchenko]

On Thu, 19 Apr 2012 01:43:09 -0700, Roedy Green
<see_w...@mindprod.com.invalid> wrote:

>On Thu, 19 Apr 2012 00:58:34 -0500, Leif Roar Moldskred
><le...@dimnakorr.com> wrote, quoted or indirectly quoted someone who
>said :
>
>>That's a terrible piece of advice to give to a beginning
>>programmer
>
>I disagree for four reasons:
>
>1. for a short piece of linear code, that is a very quick way to find
>a bug.

Far faster to run through it himself.

>2. It greatly helps a newbie to watch ANY program single stepping
>away, to get a feel for how programs behave, where they spend their
>time. You see thing that make you do a double take you would never
>notice any other way. Resolving them, nearly always as benign
>improves your intuition.

It greatly helps hand-executing them.

>3. his problem is a logic error, not a coding error. Paper tracing
>will uncover it, even if he is very weak in coding.

Yup.

>4. I think our student is just getting started. Throwing academic or
>abstract concepts at him at this stage I think would be too
>overwhelming.

He already has problems. Adding learning a debugger adds to
that.

Sincerely,

Gene Wirchenko