Peter Chase

Ranch Hand
+ Follow
since Oct 30, 2001
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
4
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Peter Chase

The simple answer is "you can't". A slightly longer answer is...

A "double" value is stored in binary. The idea of trailing decimal zeros, as in 106.4000, is meaningless in a "double" value.

A "double" value is also floating-point. This means it cannot store all decimal values (whole or fractions) with perfect accuracy. If you don't know about this stuff, Google for "floating point".
9 years ago

Originally posted by Vijay Arora:
coz i m learning Java



In that case, I would suggest moving on to the next topic in your Java education.
9 years ago

Originally posted by Jesper Young:
Solution: Don't call System.exit() in the other program



General Solution: don't call System.exit() ever
9 years ago
Using normal Java, you can't count the instances of arbitrary classes. You can count the instances of your own classes, if you code instance-counting into them.

The JVM has profiling and debugging interfaces that do allow you to count instances of classes. However, an ordinary application shouldn't, and possibly can't, use these interfaces.

Why do you want to count instances?
9 years ago

Originally posted by Campbell Ritchie:
Down-casting? Isn't it the other way round; byte to short is a widening conversion?



Yes, but the original poster said he wanted to convert a "byte array" to a "short", not to a "short array".

If converting to a short array, there is no risk of data loss, as you say.
9 years ago

Originally posted by Ulf Dittmer:
If you want "s" to be immutable, declare it "final" (which you can't do in this case because s is a local variable, but which would be possible if s was an instance variable).



Local variables can be "final", can't they? We don't do it often in Java, but it's legal, I think.
9 years ago
Java cannot magically unzip a file on a remote system, to which it does not have direct filesystem access. And I presume you do not have such access, or you would not have used FTP to upload the file.

Unix machines have various facilities for allowing remote systems to execute commands. For instance, "rsh". However, these are often disabled, due to the security risk.

Alternatively, if you can install software on the remote Unix system, you could install a Java program whose job is to do unzipping. You could send requests to it via a TCP socket (possibly via higher-level protocol like RMI, CORBA, Web service...).

If there's no built-in and enabled remote-execution service on the Unix machine, and you can't install your own on it, you're stuck.
9 years ago
I don't think that is done via reflection. Look at the Thread class, for how to get the stack trace.
9 years ago
In the general case, this is impossible. A byte array can contain any amount of data, whereas a short contains exactly 16 bits.

What's in the byte array?

And do you mean a short array, rather than a short?
9 years ago
Sorry, you've exceeded my experience now. I have not had to do post-mortem debugging of crashed C++ with embedded JVM.

Good luck!
9 years ago
Can you run your whole application from your C++ development environment (e.g. Visual Studio), with debugger? Or connect your C++ debugger before the crash?
9 years ago

Originally posted by Paul Clapham:
But debugging is used to find out why a program is not doing what you think it should be doing.



This certainly is a common use for the debugger, but is not the only one.

It is often productive to use the debugger to step through your new code, even when you do not have a specific bug to find. By doing so, you verify that variables really do have the values you think they should, and that the path through the code is what you expect.

You can't do this for every piece of code, but when you have written something short, but complicated, it can be invaluable.
9 years ago
Because Sun thought that would be a good idea, when balancing performance (which suggests using whole words for booleans) against storage requirements (which suggests using the smallest possible booleans).

A good thing about Java is that you are shielded from the differences between different platforms and JVMs. It is incredibly rare to need to know how big any particular data item is, in Java.

On the extremely rare occasions when you do need to know, there's no programmatic way to find out. You may get an answer from experiment or documentation, but it will be specific to one JVM implementation on one platform.
10 years ago

Originally posted by Rob Prime:
If you need decimal calculations this precise



Be careful about "precise" and "accurate".

The precision is the number of digits shown in the answer.

A rough definition of accuracy is the number of digits in the answer that are correct.

However, if floating-point arithmetic (double or float) has been used, then some of the digits may not be correct; the accuracy is often less than the precision. If many floating-point calculations are chained together carelessly, then most or all of the digits could be wrong!

BigDecimal can achieve almost unlimited precision and total accuracy; that is, all the digits are always correct. However, it is much slower, and uses much more storage than floating-point.

Note that BigDecimal can only do pow() with integer powers. There's no sqrt(), either. That's how it guarantees total accuracy.

Finally, note that Math.pow() is generally a bad way to compute integer powers, even when you are using floating-point. Unless your integer power is very large, you will likely get a better answer using multiplication. For example, for your z=x^12, you might do y=x*x*x, z=y*y*y*y.
[ June 23, 2008: Message edited by: Peter Chase ]
10 years ago
Please choose an appropriate forum. This is in no way an Advanced question.
10 years ago