Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
I'm a beginner in java and our professor avoided discussing BinInteger and BigDecimal classes from java.math package.I wonder why.Are they not that useful?When exactly we must need to use BigInteger?
You don't need them particularly often, but when you do need them you really need them. You really only need them when you need to actually store arbitrary precision integers or real numbers. long goes up to 263-1, which is a pretty big number.
Always use the primitives when possible because:
They have operators rather than methods, so code is easier to read/write.
They are a lot more efficient.
long, the largest primitive integer type, has a maximum value of 9,223,372,036,854,775,807, or 2^63 - 1, and a minimum value of -2^63.
double, the most precise primitive floating point type, has 64 bits of precision, which is a lot.
However, if you really need an arbitrarily large/small integer or arbitrarily precise decimal number, the BigInteger and BigDecimal types are appropriate. Such scenarios aren't that common, however, which is probably why your professor didn't discuss these types.
Decimal data types are essential when dealing with currencies
The primitive types of int and long have a limited range of values they can represent. The same is true for the floating point primitives float and double. There however you also face the issue of a limited precision. For many cases this does not pose any problem however when larger numbers or exact precision is required (e.g. in a banking application you will want to be as precise as possible) you will use BigInteger and BigDecimal however.
BIGINT is always the product of two Ints.
Example 99X99 = 10000 upto twice as big.
Both of the libraries you mentioned has their uses, if they didn't they wouldn't exist. However, your teacher probably elected not to discuss them as you probably wont be using them in your specific course. (He has to put a limit somewhere, you cannot cover the entirety of Java libs in one course.)
Related
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 2 years ago.
Improve this question
when i try to get the longValueExact() :
BigDecimal bigDecimal = new BigDecimal(432.900).divide(new BigDecimal(1), 2, RoundingMode.FLOOR);
System.out.println(bigDecimal.longValueExact());
Exception in thread "main" java.lang.ArithmeticException: Rounding necessary
at java.math.BigDecimal.commonNeedIncrement(BigDecimal.java:4151)
at java.math.BigDecimal.needIncrement(BigDecimal.java:4207)
at java.math.BigDecimal.divideAndRound(BigDecimal.java:4115)
at java.math.BigDecimal.setScale(BigDecimal.java:2455)
at java.math.BigDecimal.longValueExact(BigDecimal.java:3093)
at com.tessi.bmd.specific.actil.utils.ActilUtils.main(ActilUtils.java:1281)
new BigDecimal(432.900)
This is a bad idea. 432.900 is a double literal and is therefore highly unlikely to actually represent 432.900. You're using BigDecimal, so presumably you know that there are only at most 2^64 numbers in existence that are exactly representable by a double. 432.900 is not one of them. Do not use this constructor - it has warnings all over it. Use new BigDecimal("432.9").
.divide(new BigDecimal(1),
Okay, divide by 1, not going to do anything. Also, use BigDecimal.ONE for this.
The value is still 432.899999999999434 or whatnot.
System.out.println(bigDecimal.longValueExact());
Of course that doesn't work - a long value can only hold integral values, and 432.9 (or something close to that) isn't.
Are you perhaps thinking that 432.900 is just a way of writing 432900 that is more readable to humans from certain locales where . is used as thousands separator?
. is the decimals separator. 432.900 is a double literal that represents the nearest representable double to the number 432 + 9/10ths. If that's your intend, remove the . - if you want to create some horizontal space for the yes, use _ which is legal in number literals and meaningless.
If that's not your problem and you really want 432.9 as an exact long - I guess, go back to square one and start learning java. Soon (as in, within a day or two, no doubt) you'll hit the part of the tutorial that explains the primitive data types. Pay extra attention to this section.
It is the normal behavior because the value you want to display as a long has decimal part (432.89, not 432.90 due to instatiating BigDecimal from a double) so is not an interger number. From the javadoc:
Converts this BigDecimal to a long, checking for lost information. If
this BigDecimal has a nonzero fractional part or is out of the
possible range for a long result then an ArithmeticException is
thrown.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
Why is the scale field of a BigDecimal not a BigInteger? I assume currently it makes maybe no sense because calculations with that many decimal places are likely never performed, but wouldn't it make sense for the future to rather use a BigInteger?
The scale of a BigDecimal is the number of digits it stores to the right of the decimal point. It is an amount of memory in that those digits are actually stored, and it is an amount of work in that most operations on a BigDecimal will have to do work on all of those digits.
It is never going to be a good idea to use a BigDecimal that takes an amount of memory or work that doesn't fit into an int, so an int is used for scale. That's the same reason int is used for string lengths and collection sizes, etc.
In the rare cases that a reasonable amount of memory or work doesn't fit into an int, it certainly fits into a long. Longs are used for file sizes and position, for example. A BigInteger is never required.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
Java designer's felt that unsigned integers were unnecessary. Specifically, they felt that the concept of unsigned was used mostly to specify the behavior of the high-order bit, which defines the sign of an integer value. Java manages the meaning of the high-order bit differently, by adding a special "Unsigned Right Shift Operator >>>". Thus, the need for an unsigned integer type was eliminated. Then, why Java 8 will have some support for unsigned integers.
Java 8 includes just some helper methods (static methods on java.lang.Integer and java.lang.Long) that implement commonly needed operations.
Most of them are quite trivial if you know http://en.wikipedia.org/wiki/Two%27s_complement, but as experience shows many programmers have struggled (as is evident by the number of related questions of SO) to arrive at those simple solutions for these operations.
There is no magical difference between a signed and an unsigned int, viewed as bit patterns signed and unsigned look the same. The difference lies in the interpretation of said patterns. Its relatively simple to emulate any unsigned operation using signed types, so unsigned types are not an absolutely necessary language element to perform unsigned arithmetic.
In short: There are no unsigned types in Java8 because it would be a huge effort to add them (if there were primitives it would require also large additions to the bytecode and JLS).
There are some helper methods because thats what is commonly needed and hard to get right (for the average joe developer).
For the first cut, I've favored keeping the code straightforward over
trickier but potentially faster algorithms. Tests need to be written
for the unsigned divide and remainder methods, but otherwise the
regression tests are fairly extensive.
To avoid the overhead of having to deal with boxed objects, the
unsigned functionality is implemented as static methods on Integer
and Long, etc. as opposed to introducing new types like
UnsignedInteger and UnsignedLong.
http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-January/008926.html
Also refer this : https://blogs.oracle.com/darcy/entry/unsigned_api
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
Though oracle technotes state that :
In Java SE 7 and later, any number of underscore characters (_) can
appear anywhere between digits in a numerical literal. This feature
enables you, for example, to separate groups of digits in numeric
literals, which can improve the readability of your code.
example : float pi = 3.14_15F;
is same as
float pi = 3.1415F;
But does it not become confusing to the developers working on code written by someone else?
Also does the use of underscore put any overhead on compiler or not?
But does it not become confusing to the developers working on code written by someone else?
Only if the developers don't understand the Java language! This construct has been been supported for long enough that every Java professional should recognize it ... even if they don't use it in their own code.
On the other hand, if your Java developers have not bothered to keep up to date with the new things in Java 7, they may be (temporarily) baffled. But the real solution is to educate your developers.
Also does the use of underscore put any overhead on compiler or not?
The overhead would be so small that it is impossible to measure.
There is no performance issue here.
The only time it would make any sense to use underscores is in a very large integer or with a binary integer. Like almost any bit of syntactical freedom the language provides, people are free to misuse it and write difficult to read code. I doubt this underscore thing will become a problem any more than the freedom to add extra white space is a problem.
The best example for when you would want to use this is with binary numbers where it is customary to place a space between every 4 bits.
For instance, compare:
int bitField = 0b110111011111;
int bitField2= 0b1101_1101_1111; //clearly more readable.
Other examples might include a credit card number or SSN as given in Oracle's documentation of this feature.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
What is the purpose of having methods converting one value into another value of a different type. For example a method that converts a string of digits into an int and another method converting an int into a string of digits? What exactly would be the advantages to doing one over the other? Is it there is no advantage and the methods for conversion exist only to provide compatible values for the arguments of the constructors of different classes?
Simply, it's because those different types exhibit different behaviors:
String str = "42";
System.out.println(str + 1);
System.out.println(Integer.parseInt(str) + 1);
421
43
You need to have methods like Integer.parseInt() if you want to perform normal addition as opposed to string concatenation, for example.
A tangible example of this can come up when you read a number as input from a user; more often than not you will want to treat this number as a number (double, int, etc.) as opposed to a string.
The different forms serve different purposes beyond providing compatible values for methods and constructors.
For the int type, mathematical operations are most easily performed on this type (and similar primitive types). User input is usually given in the form of a String, so to perform a mathematical operation on user input, one must convert it into an int (or a double, long, float, byte, or short as appropriate).
For converting to a String: This is how numerical output is displayed. We may code System.out.println(myInt);, but behind the scenes, Java is converting the number to a String for display purposes.
Since you used the "Java" tag, I'll answer you regarding java.
It is because, Java was written this way . There are languages that do not need types (lisp for example) and you can read a string (from Std. In) and raise it to a power (for example) if it is a number. But Java needs types. The compiler wants to know it ahead.
One useful advantage of being able to convert numbers to string is that you are able to use very large numbers, storing them as strings, instead of integers. However you cannot work with strings when you use the regular operators (+,-,*,/).
Another advantage: when you have a TextField and you read user input, it is given as a string. So you need to get a number out of it to work with it.