The `transient`

keyword in Java is used to indicate that a field should not be part of the serialization (which means saved, like to a file) process.

From the Java Language Specification, Java SE 7 Edition, Section 8.3.1.3. `transient`

Fields:

Variables may be marked `transient`

to
indicate that they are not part of the
persistent state of an object.

For example, you may have fields that are derived from other fields, and should only be done so programmatically, rather than having the state be persisted via serialization.

Here's a `GalleryImage`

class which contains an image and a thumbnail derived from the image:

```
class GalleryImage implements Serializable
{
private Image image;
private transient Image thumbnailImage;
private void generateThumbnail()
{
// Generate thumbnail.
}
private void readObject(ObjectInputStream inputStream)
throws IOException, ClassNotFoundException
{
inputStream.defaultReadObject();
generateThumbnail();
}
}
```

In this example, the `thumbnailImage`

is a thumbnail image that is generated by invoking the `generateThumbnail`

method.

The `thumbnailImage`

field is marked as `transient`

, so only the original `image`

is serialized rather than persisting both the original image and the thumbnail image. This means that less storage would be needed to save the serialized object. (Of course, this may or may not be desirable depending on the requirements of the system -- this is just an example.)

At the time of deserialization, the `readObject`

method is called to perform any operations necessary to restore the state of the object back to the state at which the serialization occurred. Here, the thumbnail needs to be generated, so the `readObject`

method is overridden so that the thumbnail will be generated by calling the `generateThumbnail`

method.

For additional information, the article Discover the secrets of the Java Serialization API (which was originally available on the Sun Developer Network) has a section which discusses the use of and presents a scenario where the `transient`

keyword is used to prevent serialization of certain fields.

Decimal numbers *can* be represented exactly, if you have enough space - just not by floating *binary* point numbers. If you use a floating *decimal* point type (e.g. `System.Decimal`

in .NET) then plenty of values which can't be represented exactly in binary floating point can be exactly represented.

Let's look at it another way - in base 10 which you're likely to be comfortable with, you can't express 1/3 exactly. It's 0.3333333... (recurring). The reason you can't represent 0.1 as a binary floating point number is for exactly the same reason. You can represent 3, and 9, and 27 exactly - but not 1/3, 1/9 or 1/27.

The problem is that 3 is a prime number which isn't a factor of 10. That's not an issue when you want to *multiply* a number by 3: you can always multiply by an integer without running into problems. But when you *divide* by a number which is prime and isn't a factor of your base, you can run into trouble (and *will* do so if you try to divide 1 by that number).

Although 0.1 is usually used as the simplest example of an exact decimal number which can't be represented exactly in binary floating point, arguably 0.2 is a simpler example as it's 1/5 - and 5 is the prime that causes problems between decimal and binary.

### Side note to deal with the problem of finite representations:

Some floating decimal point types have a fixed size like `System.Decimal`

others like `java.math.BigDecimal`

are "arbitrarily large" - but they'll hit a limit at some point, whether it's system memory or the theoretical maximum size of an array. This is an entirely separate point to the main one of this answer, however. Even if you had a genuinely arbitrarily large number of bits to play with, you still couldn't represent decimal 0.1 exactly in a floating binary point representation. Compare that with the other way round: given an arbitrary number of decimal digits, you *can* exactly represent any number which is exactly representable as a floating binary point.

## Best Solution

It will change the points at which the values are rounded, based on their magnitude. As an example of the

kindof thing that we're seeing, let's pretend that instead of binary floating point, we were using a decimal floating point type with 4 significant digits, where each addition is performed at "infinite" precision and then rounded to the nearest representable number. Here are two sums:We don't even need non-integers for this to be a problem:

This demonstrates possibly more clearly that the important part is that we have a limited number of

significant digits- not a limited number ofdecimal places. If we could always keep the same number of decimal places, then with addition and subtraction at least, we'd be fine (so long as the values didn't overflow). The problem is that when you get to bigger numbers, smaller information is lost - the 10001 being rounded to 10000 in this case. (This is an example of the problem that Eric Lippert noted in his answer.)It's important to note that the values on the first line of the right hand side are the same in all cases - so although it's important to understand that your decimal numbers (23.53, 5.88, 17.64) won't be represented exactly as

`double`

values, that's only a problem because of the problems shown above.