My first machine independent program... isn't.
Christopher McKinstry
at the local community college. first assignment, write a program to find the all
the prime numbers less than 100. easy enough.
i went home and wrote it in 20 minutes for my win95 machine... then spend another
1/2 hour fiddling with it to make it faster/better. got it to take a command line
argument so i didn't have to hard code the 100... fine and dandy.
took it to class today. compiled it on a spark 5 and boom (okay, more like pop),
it fails. no matter what argument i give it it stops at 1.
so my very first machine independent program won't run on a sun system!
remarkable.
i suspect it's a command line problem with the runtime... any ideas?
chris.
the program follows:
class PrimesLessThan {
//usage from command line: java PrimesLessThan int
//eg: 'java PrimesLessThan 100' gives all primes less than 100
public static void main (String args[]) {
// init vars
String prime;
int x = 1, divcount = 0, tp = 0, t = 0;
float n = 1;
double a =0, r = 0;
// get main loop count from command line
t += Integer.parseInt(args[0]);
// main loop
do {
//prime test loop
do {
r = n / x;
a = Math.floor(r);
if (a == r) divcount++;
x++;
} while (x <= Math.sqrt(n));
if (divcount == 1)
{ System.out.println(n);
tp++; }
divcount = 0;
x = 0;
//skip even numbers after 2...
if (n >2 ) n++;
n++;
} while (n < t);
System.out.println();
System.out.println(tp + " Total Primes < " + t);
}
}
--
K. Christopher McKinstry
-All science is the study of perception.
-AI researchers, Win $10,000 http://www.clickable.com/mist.html
Frank Teusink
>okay... so i finally decided to start coding in java... signed up for a hands on
>at the local community college. first assignment, write a program to find the all
>the prime numbers less than 100. easy enough.
>i went home and wrote it in 20 minutes for my win95 machine... then spend another
>1/2 hour fiddling with it to make it faster/better. got it to take a command line
>argument so i didn't have to hard code the 100... fine and dandy.
>took it to class today. compiled it on a spark 5 and boom (okay, more like pop),
>it fails. no matter what argument i give it it stops at 1.
>so my very first machine independent program won't run on a sun system!
>remarkable.
>i suspect it's a command line problem with the runtime... any ideas?
Tried printing out args[]?
In unix, args[0] tends to be the name of the program itself.
How is this under M$??
Cheers,
Frank
--
Frank Teusink CWI
email: fra...@cwi.nl P.O.Box 94079
tel: +31 20 592 4075 1090 GB Amsterdam
fax +31 20 592 4199 The Netherlands
Roedy Green
Things don't change much. This reminds me of the errors my students made
back in the 60s in Fortran classes.
First some general advice:
Never use float to represent integers. A LINT program would likely flag (a
== r) as questionable. It is best to presume a few of the least
significant bits of any floating point number contain random values. You
are trying to determine if x divides n evenly, i.e. if the remainder of n
divided by x is zero. Look up the % operator for directly computing the
remainder.
Floating point ops are time consuming. You don't want to do sqrt in a loop
if you can possibly help it.
divcount = 0 and x=2 should occur only once in your program, just ahead of
the prime test loop. Your unstructured approach has has me wondering if
sometimes you divide by zero. It sounds plausible that different
environments might have different standard exception handlers.
You could track down whether command line args are the problem by
displaying t right after you get it off the command line. By the way why
the t += operator there?
Ask yourself these questions, and make sure you are consistent.
Which divisor do you really want to start with 0, 1 or 2? Does divcount
include 1? 2? How come you initialize x to 0 in one place but 1 in
another?
Ro...@bix.com <Roedy Green of Canadian Mind Products> contract programming
-30-
Peter van der Linden
>so my very first machine independent program won't run on a sun system!
I'll bet you dollars to doughnuts that your very first program won't
do what you think it's doing on a Windows95 machine either. It's not
a "command line problem with the runtime" though.
You have 2 major problems:
1. your algorithm for finding prime numbers is flawed.
You have many of the right statements, but they are put
down in the wrong order and with funny looping.
2. you mix in floating point numbers, which allows errors caused
by inexact arithmetic to jump in and smite you. You probably
don't want that. Don't use real numbers in this problem.
I stopped looking for more problems at that point.
Here's how to fix it.
1. Write down, in English words, the list of operations to check
if a single given number is prime, and return True/False.
2. Write that as a Java method.
3. Put println statements everywhere, showing values whenever
you change a variable.
To see what's wrong with your current code, put
if (a == r) { divcount++;
System.out.println("divisor found:" +r +","+n+","+x);
}
near line 22.
You will see:
java P 5
divisor found:1,1,1
1
divisor found:Inf,2,0
What is that "Inf" -- ask yourself why you got "Infinity"!
You basically need more practice with algorithms and debugging. We
all had to learn sometime. You'll waste a lot of time blaming it on
crazy theories involving runtimes if you don't eliminate your own
code as a source of errors first. BTW, check the Unix tool "indent"
-- it can be used on Java code, and does nice consistent indenting for you.
Peter van der Linden
>
>chris.
>
>the program follows:
>--
>K. Christopher McKinstry
>-All science is the study of perception.
>-AI researchers, Win $10,000 http://www.clickable.com/mist.html
--
\ Peter van der Linden lin...@eng.sun.com
\ No shoes, no shirt? No software.
\ http://www.best.com/~pvdl <---- Java powered.
Raksas Hang
: okay... so i finally decided to start coding in java... signed up for a hands on
: the prime numbers less than 100. easy enough.
: i went home and wrote it in 20 minutes for my win95 machine... then spend another
: 1/2 hour fiddling with it to make it faster/better. got it to take a command line
: argument so i didn't have to hard code the 100... fine and dandy.
: took it to class today. compiled it on a spark 5 and boom (okay, more like pop),
: it fails. no matter what argument i give it it stops at 1.
: so my very first machine independent program won't run on a sun system!
: remarkable.
: i suspect it's a command line problem with the runtime... any ideas?
: chris.
: the program follows:
:
:
: }
: }
Hmm.. it seems you're trying to compare two floating point numbers,
which I think is the problem. Instead of comparing to see if a is equal
to r, you can check to see if their absolute difference is small enough.
---------------------
<rak...@cse.ucsc.edu>
Larry Rau
>
> Christopher McKinstry <cmc...@clickable.com> writes:<<stuff removed>>
> >remarkable.
>
> >i suspect it's a command line problem with the runtime... any ideas?
>
> In unix, args[0] tends to be the name of the program itself.
> How is this under M$??
nope. In java args[0] is the first argument, not the program name.
Hist problem is he is dividing by 0.
: class PrimesLessThan {
: //usage from command line: java PrimesLessThan int
: //eg: 'java PrimesLessThan 100' gives all primes less than 100
: public static void main (String args[]) {
: // init vars
: String prime;
: int x = 1, divcount = 0, tp = 0, t = 0;
^-- this is why it works the first time!!!!!
: float n = 1;
^--- I made this an int because it don't need to be a
float, in fact if you do this first before my change below then you will
bomb out with a Divide by zero exception.
: double a =0, r = 0;
: // get main loop count from command line
: t += Integer.parseInt(args[0]);
: // main loop
: do {
: //prime test loop
: do {
: r = n / x;
: a = Math.floor(r);
at this point on Intel 'a' and 'r' are invalid floating point numbers, but
different. On Sparc they are invalid but the same so the following test
fails on Intel and passes on Sparc -- the program works by accident on intel.
: if (a == r) divcount++;
: x++;
: } while (x <= Math.sqrt(n));
: if (divcount == 1)
: { System.out.println(n);
: tp++; }
: divcount = 0;
: x = 0;
^-- this is the problem, don't set x to 0
set it to 1.
: //skip even numbers after 2...
: if (n >2 ) n++;
: n++;
: } while (n < t);
: System.out.println();
: System.out.println(tp + " Total Primes < " + t);
: }
: }
After I made the changes the code works on Win95 and Solaris Sparc.
.................larry
Larry W. Virden
I really am getting a chuckle out of this thread. See, several times
in the early days of Java I asked whether someone had considered collecting
info like this - places where java programmers need to be careful due to
incompatibilites between OSes/hardware/etc. Each time I was flamed by
folks 'informing' me (as if I were too stupid to have read Sun's press
releases) that the whole point of Java was to be machine indendant. Of
course that's the party line. But here is yet another case where the
theory and the practice are quite different.
Now, if I was doing full time daily Java programming, I would be
happy to jump in and volunteer for this project. However, I am
a casual Java user - I spend my extra time on a faq for a different
newsgroup right now, so I again ask if some of the Java full time folk
around here would consider organizing the incompatibility information
on a WWW page.
--
:s Larry W. Virden INET: lvi...@cas.org
:s <URL:http://www.teraform.com/%7Elvirden/> <*> O-
:s Unless explicitly stated to the contrary, nothing in this posting should
:s be construed as representing my employer's opinions.
Sean Russell
I really am getting a chuckle out of this thread. See, several times
in the early days of Java I asked whether someone had considered collecting
info like this - places where java programmers need to be careful due to
incompatibilites between OSes/hardware/etc. Each time I was flamed by
folks 'informing' me (as if I were too stupid to have read Sun's press
releases) that the whole point of Java was to be machine indendant. Of
course that's the party line. But here is yet another case where the
theory and the practice are quite different.
Now, if I was doing full time daily Java programming, I would be
happy to jump in and volunteer for this project. However, I am
a casual Java user - I spend my extra time on a faq for a different
newsgroup right now, so I again ask if some of the Java full time folk
around here would consider organizing the incompatibility information
on a WWW page.
Even within one language, on one platform, there are cases where the
same programming error can produce different results when run multiple
times.
It just seems rather silly to want an archive of programming errors.
--- SER
--
---
Sean Russell Software Engineer
s...@javalab.uoregon.edu Department of Physics
http://jersey.uoregon.edu/ser University of Oregon
D'Arcy Smith
> - places where java programmers need to be careful due to
> incompatibilites between OSes/hardware/etc.
>
> same programming error can produce different results when run multiple
> times.
He isn't talking about programming errors. He is talking about when
1 piece of bytecode is run on two different platforms and it produces
different results.
The code may be 100% correct but it just doesn't work the same on two
different platforms. An example of this is how DOS based systems handle
new-lines in files differently that Unix based systems - not all of the
File-type Classes handle this correctly... and we can't always use the
DataInput/OutputStream classes... :-(
More noticeable differences are withing the AWT - because the AWT uses
the native controls there are always going to be compatibility
differences. These are not "programming errors" instead they are
platform specific "special cases" that we should be aware of.
..darcy
D'Arcy Smith
Symantec
Sean Russell
> 1 piece of bytecode is run on two different platforms and it produces
> different results.
But he *is* talking about programming errors, he just doesn't know it.
In this particular case, the issue involved either
a) a division by zero
or
b) a floating point equality comparison
or
c) both.
Mathematics decree that the result of a division by zero is undefined.
Division by zero is therefore considered an error, and is normally
attributed to the programmer and lack of error checking. If you want
to nitpick, I agree that this is indeed a case of incompatability.
Similarly, using a floating point equality comparison is also
considered poor programming, due to everybody's use of the IEEE FP
standard, which is inherently inaccurate to a certain degree. Both of
these are issues of programming error.
I propose that this is A Silly thing to worry about; people should be
more concerned with producing correct code than how their bug-ridden
code functions incorrectly on different platforms.
There are other issues which may deserve to be in a Hall of
Incompatabilities. However, I believe that this is a case of poor
programming than Java interpreter incompatabilities.
Larry W. Virden
According to Sean Russell <s...@javalab.uoregon.edu>:
:> He isn't talking about programming errors. He is talking about when
:> 1 piece of bytecode is run on two different platforms and it produces
:> different results.
:
:But he *is* talking about programming errors, he just doesn't know it.
:
Let me speak for myself. What I really DO care about is how Java behaves
differently on different platforms. The head of this thread discussed the
fact that, in the case of a particular programming error, Java behaved
differently on two different platforms. I don't care to know how Java
treats divide by zero - I DO care to know the fact that Java on Windows
treats the exception event differently than Java on the SPARC. The programming
error itself is one of a matter of oversight or lack of training. The latter
is not the fault of the programmer trying to use Java, and if they have to
do things differently to catch exceptions on the two platforms, then it is
important to note that.
I am saying that having:
a way to learn specific programming techniques
to ensure that one's program runs as IDENTICALLY AS POSSIBLE
across platforms
AND
a way to learn when it is going to be impossible for that to occur,
are important things to have.