aspose file tools*
The moose likes Programmer Certification (SCJP/OCPJP) and the fly likes Confused with answers from (K&B) Chapter 6: Question 13 Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Programmer Certification (SCJP/OCPJP)
Bookmark "Confused with answers from (K&B) Chapter 6: Question 13" Watch "Confused with answers from (K&B) Chapter 6: Question 13" New topic
Author

Confused with answers from (K&B) Chapter 6: Question 13

sebastian tortschanoff
Ranch Hand

Joined: Mar 19, 2009
Posts: 68
Hello folks,

i need help.

I've tested the following example either in eclipse and with console (with javac and java).



According to the answers from K&B the output should look like this:

Answer D.
987.12346
987.123456

------------------------------
My output in eclipse:
987,12346
987123456

My output in javac/java:
987,12346
987123456
is exactly the same.


Now my confusion.
* Why does my output looks so different (the colon instead uf a dot and look at the parsed string s)? I'm shure i have not made any typing errors (at least in the code).
* Why is the output of this: 987,12346
i'd expected something like this: 987,12345

Power from within.

Failed SCJP 2 times :-(
Ryan Beckett
Ranch Hand

Joined: Feb 22, 2009
Posts: 192
1.



HALF_EVEN Rounding Mode

2.



I'm guessing that NumberFormat.setMaximumFractionDigits can only be applied to numbers. It explicitly says, "Numbers" in the API.
sebastian tortschanoff
Ranch Hand

Joined: Mar 19, 2009
Posts: 68
I'm guessing that NumberFormat.setMaximumFractionDigits can only be applied to numbers. It explicitly says, "Numbers" in the API.


But why schould work an strings, too?

My output contains no colon(,) or dot(.), but it seems that (from K&B) there should be at least a dot (because there is actually one in the string).

I think, that i will flop questions about NumberFormat and stringparsing, and i dont want to.
Ryan Beckett
Ranch Hand

Joined: Feb 22, 2009
Posts: 192
No comma's nor decimal symbols because its not a String. parse() returns java.lang.Number
A java.lang.Number is an abstract representation of a number. It's not floating point.
NagarajGoud uppala
Ranch Hand

Joined: Nov 13, 2008
Posts: 86
sebastian tortschanoff wrote:
Now my confusion.
* Why does my output looks so different (the colon instead uf a dot and look at the parsed string s)? I'm shure i have not made any typing errors (at least in the code).
* Why is the output of this: 987,12346
i'd expected something like this: 987,12345


Hi sebastian,
the above s.o.p statement will print 987.12346 because in the fractional part the 5th digit is rounding to 6.
as per basic mathematical rule


I know Life is very Tough...But I AM TOUGHER
SCJP 1.5
sebastian tortschanoff
Ranch Hand

Joined: Mar 19, 2009
Posts: 68
Hi sebastian,
the above s.o.p statement will print 987.12346 because in the fractional part the 5th digit is rounding to 6.
as per basic mathematical rule


Right, so far. I do understand.




I've tested it.
The number returned by will not contain an fraction-delimiter.
But the number returned by will not contain any fraction-delimiter.

This concludes, that answer D. can not be a correct answer, cause will not return 987.123456 but simply 987123456.
NagarajGoud uppala
Ranch Hand

Joined: Nov 13, 2008
Posts: 86
This concludes, that answer D. can not be a correct answer, cause will not return 987.123456 but simply 987123456.


where you are tested it?? if you tested it under command prompt you will definately get the 987.123456 even your using
sebastian tortschanoff
Ranch Hand

Joined: Mar 19, 2009
Posts: 68
where you are tested it?? if you tested it under command prompt you will definately get the 987.123456 even your using
view plaincopy to clipboardprint?

1. system.out.println((Number)nf.parse(s));



I've tested both, Eclipse and console. And the ouput of this is or this

is always this: 987123456 <-- no delimiters!!!
Wojciech Jamrozy
Greenhorn

Joined: Mar 30, 2009
Posts: 1
try in this way...
public class Slice {


public static void main(String[] args) {
String s = "987.123456";
double d = 987.123456d;

Locale inLocale = new Locale("EN");
NumberFormat nf = NumberFormat.getInstance(inLocale);
nf.setMaximumFractionDigits(5);
System.out.println(nf.format(d)+ " ");
try{
System.out.println(nf.parse(s));
}
catch (Exception ex){
System.out.println("got exc");
}

}

}

I think that the way that NumberFormat prints depend on Locale language settings
NagarajGoud uppala
Ranch Hand

Joined: Nov 13, 2008
Posts: 86
sebastian tortschanoff wrote:
is always this: 987123456 <-- no delimiters!!!

Hi sebastian,
but i am getting 987.123456 always when i run in jdeveloper as well as console.
which version of jdk your using? i am using 1.6.0
sebastian tortschanoff
Ranch Hand

Joined: Mar 19, 2009
Posts: 68
I think that the way that NumberFormat prints depend on Locale language settings


Hey Wojciech,

Excellent, this works.

It's sad, that in this case my german Locale behaves so strange. At least there should be a comma, cause this is the standard delimiter for numbers in germany.
Ryan Beckett
Ranch Hand

Joined: Feb 22, 2009
Posts: 192
Yeah, I had originally said that you should check the locale in my previous post, but I edited it. I guess I wasn't paying attention to the output. The API says -

getInstance()
Returns the default number format for the current default locale.
-

sebastian tortschanoff
Ranch Hand

Joined: Mar 19, 2009
Posts: 68
Sorry Ryan, i don't wanted to ignore you. It was not so clear to me, that you've posted it.
Douglas Boff Nandi
Ranch Hand

Joined: Feb 25, 2008
Posts: 34
Here in Brazil with operating system in Portuguese


Remember: NumberFormat.getInstance() returns a general-purpose number format for the current default locale.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Confused with answers from (K&B) Chapter 6: Question 13
 
Similar Threads
nit w/ chap.6 q.13 S&B
Discussing errata for K&B, SCJP 6
Question on NumberFormat
nit w/ chap.6 q.13 S&B
NuberFormat format and parse doubt