 2
Where as long can not handle factions/decimal numbers, but only whole numbers.
Given your example code x is a whole number of 1000.
It then automatically gets converted to a double when you declare y.
Now y is 1000.00, or something close to that because it's a double.
1000.00 cannot be converted to int without the loosing the decimal places. In doing so you may lose some precision.
This is somewhat related to this posting/blog entry
Does 1.0 equal 0.9999999999999999...?
Which attempts to explain some of the concerns with dealing to floating point numbers in regards to comparisons.
“The strongest of all warriors are these two — Time and Patience.” ― Leo Tolstoy, War and Peace
 2
What PL has said is the explanation for a basic language requirement: a double is regarded as a “wider” datatype that a long, so you can implicitly widen one way, but you cannot convert the other way without a cast. As PL has hinted, the cast will lose any fractional part of the number.
You can also get loss of precision the other way; it is possible to fit 1234567891011121314L into a long, but there is no guarantee that it can be exactly represented as a double.
1000 is one of the numbers that can be represented exactly as a double.
Pete Letkeman wrote:Please remember that a double can handle factions/decimal numbers for instance 3.141592654 as well as whole numbers.
Where as long can not handle factions/decimal numbers, but only whole numbers.
Given your example code x is a whole number of 1000.
It then automatically gets converted to a double when you declare y.
Now y is 1000.00, or something close to that because it's a double.
1000.00 cannot be converted to int without the loosing the decimal places. In doing so you may lose some precision.
...
Hi Pete,
thanks for the answer.
So double cannot get back to long because of the floating point, I mean the compiler thinks:" if there was decimal digits in double then the program would loose them. Let's advise of the possible lossy conversion!".
Campbell Ritchie wrote:You are not using the number as a long. 1_000 is an int literal, which requires conversion to a long before you can use it. The long form of the number is 1_000L.
I see.
But it's not a requirement. I mean I can use x without convert the literal to long:
Campbell Ritchie wrote:What PL has said is the explanation for a basic language requirement: a double is regarded as a “wider” datatype that a long, so you can implicitly widen one way, but you cannot convert the other way without a cast. As PL has hinted, the cast will lose any fractional part of the number.
OK
Campbell Ritchie wrote:You can also get loss of precision the other way; it is possible to fit 1234567891011121314L into a long, but there is no guarantee that it can be exactly represented as a double.
So why the compiler enables me to convert a long into double?
by the way, you are right:
I'm not a math wiz...What's the meaning of the last 'E18'?
"long" is an adjective  describing the implied noun (integer)
"double" is also an adjective  describing the implied noun float (floatingpoint number, to be precise)
In computer grammar terms, the "adjectives" are called modifiers.
So you have 2 different base types and therefore not only does precision vary, but so does the domain of the representable number set.
I'd have to check, but I think that Java is one of the languages that also supports the construct "long double". The implied noun here is float, since upconversion makes floats of integers, so "double" is the determining word.
An IDE is no substitute for an Intelligent Developer.
That code has an implicit cast it. You have an int expression to the right of the = sign and the JVM will interpret that asDaniele Barell wrote:. . . I mean I can use x without convert the literal to long:
long x = (long)(1_000);
Since the expression on the right is a constant expression, what many people call a compile‑time constant, the type conversion may be done by the compiler. If it is, it can be seen in the bytecode. You can view the bytecode with javap c LongDouble. If you look in the Java® Language Specification (=JLS), you will find that long→double is one of the 19 “widening primitive conversions”. These are specifically permitted by the language specification under all circumstances. If you scroll down, you will find that
If you scroll down a bit more, you will find there are also 22 “narrowing primitive conversions”. You will see from the example that they all require casts; if you attempt any of those conversions without a cast, the compiler must fail to accept the code, but the compiler error message about “possible loss of precision” isn't very clear.A widening primitive conversion from int to float, or from long to float, or from long to double, may result in loss of precision  that is, the result may lose some of the least significant bits of the value.
As it said earlier, “widening” conversions are always permitted.. . . So why the compiler enables me to convert a long into double? . . .
If you go back to the JLS link I gave above, you will see there are comments about range, saying that casting double→float may cause small values to degenerate to 0f and large values to degenerate to ∞. That suggests that a number datatype is regarded as “wider” if its range of permissible values is greater, meaning there are more values between the largest and the smallest. A double and a long each occupy 64 bits, and the long can exactly define every whole number in its range. But the double has a much larger range, so it must miss out some values. I learnt about that first from the Deitel and Deitel Java5 book. There are ten long values between 1234567891011121310L and 1234567891011121320L(exc), but there are not ten different double values in that range, so the nearest double has to be chosen. In fact the output you obtained suggests to me that there are no double values in that range, which is why it ends 141 not 13x.
Because you didn't specify any formatting, the output defaults to printing the fewest numbers necessary to identify the nearest distinct value. That turns out to be 1,234,567,890,101,114,100 but the default format is so‑called scientific format which on paper looks like 1.23456789101112141×10¹⁸, but older computers didn't have the pretty superscripts, so they write E18 instead of ×10¹⁸. Read that as meaning you move the decimal point 18 places to the right; in this case you will have to add a few 0s on the right.. . . What's the meaning of the last 'E18'?
If you are supposed to move the decimal point to the left, there will be a − after the E.
I am now going into hiding for embarrassment about how many posts I have
[edit]Additonal: I see that the 121314 at the right end of the number has turned into 14100 so the precision is worse than I thought. It also might mean that I have missed out a 0 at the right of the number I was discussing.
An integer is selfcontained and it is at its heart a unitary value. A floatingpoint number is not. Floats have an exponent part and a mantissa part. The exponent scales the mantissa value. The mantissa is considered as a binary fraction  that is, 0.1 would have a value of 1/2. Given that, an exponent of 1 (meaning 2**1) and a mantissa of 0.100000000... would have an integral value of 1.
The difference between float, double and long double is primarily in the available amount of bit positions. The total bit occupancy of a float is 32 bits, a double is 64 bits and a long double is 128 bits.
Although, if memory serves, the IEEE spec does allow some extra bits for exponent values as well (IBM's S/360 version always had 8 bits for exponent and everything else was mantissa).
For a given number of exponent bits, adding bits to the overall value length does not increase the range of the number, but rather its precision. (also known as epsilon.). So downscaling from a double to a float, for example, would be the equivalent of chopping the value 9.3333333333 down to 9.333333. The approximate values are the same, but obviously not their exact values. Since the mantissa is a binary fraction and not a decimal one, a lot of decimal fractions are crude to begin with. 0.5 and 0.25 are easy (precise), but 0.1 is not (irrational, if I've got my terminology correct).
In the event that your floatingpoint system allows differentsized exponent bit allocations, downscaling where the target exponent cannot hold the original exponent value can potentially blow the number out of range. But in general, that should not result in infinity, but in a NaN value, since it's not literally infinity. And, of course raise a range exception.
So you have 2 vulnerabilities. First, that you will lose precision  downwards for positive numbers, upwards for negative numbers, and the loss of precision is not related to the related (nearest) integer value.
Secondly, that you will exceed the range of the integral reach of the number (exponent size).
Loss of precision is annoying, but nonfatal. Unless you accumulate enough erosion to, say, destroy an interplanetary exploration vehicle or steal from someone's paycheck. Loss of exponent range, on the other hand is an immediate problem, since it puts an immediate end to all further computation.
An IDE is no substitute for an Intelligent Developer.
Anderson gave himself the promotion. So I gave myself this tiny ad:
Why should you try IntelliJ IDEA ?
https://coderanch.com/wiki/696337/IntelliJIDEA
