Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2011/ch7 7a or

2011-12-03T03:43:07Z

Opevans: /* Currency Conversion */

Wiki Chapter: CSC/ECE 517 Fall 2011/ch7 7a or

''7a. Representing money. Skrien Chapter 6 gives an example of a class that can be used to represent money. But how is it done in real programs? Investigate, and report on the advantages and disadvantages of other approaches vs. Skrien's.''
__TOC__
==Introduction==
Money is very important to people worldwide and is something that often must be represented in computer programs. This raises the question of how money should be represented, which can vary from program to program. There is much to be considered such as string formatting, the way money is used, and the variety of different currencies in the world. In Chapter 6 of Skrien's ''Object-Oriented Design Using Java'', he suggests an implementation that represents money as a class, but there are other approaches that can be taken, each with their respective advantages and disadvantages.

==Properties of Money==
Money has certain properties and uses that must be considered in implementation.

===Responsibilities/Using Money===
The following are ways in which a representation of money should be able to be used: <ref name="lec20">http://courses.ncsu.edu/csc517/common/lectures/notes/lec20.pdf</ref>
*To represent a positive or negative amount of money.
*Possibly representing multiple components of a currency - i.e. dollars and cents.
*Possibly representing amounts of multiple currencies - i.e. a mix of US Dollars, euros, and yen.'
*To have a string formatting potentially including currency symbols like the dollar sign ($) and/or commas and/or decimal points.
*Addition, subtraction, multiplication, and division.
The degree to which of the above must be met will depend on the depth of the implementing project.

===Different Currencies===
Some applications may only handle only one currency such as the US Dollar, but more generally applied applications, such as banking, must be able to handle different kinds of currencies.

There are currently over 180 currencies in use around the world.<ref>http://en.wikipedia.org/wiki/List_of_circulating_currencies</ref>

Implementation must be aware of how to specifically represent each currency used. Some currencies use decimal points, such as how the US has 100 cents to a dollar, while others have no decimal, such as yen. Each currency also has a different sign symbol used such as $, €, or ¥. Different currencies also have different rules about how rounding values is handled.

Special consideration must be taken when using different currencies in conjunction with each other. Foreign exchange rates can be used to convert between different currencies, but the exchange rate often change, so attention must be paid to that. In some cases, it is also important to keep track of how much money the user has of more than one currency at a time, so that must be handled somehow. <ref>http://www.xencraft.com/resources/multi-currency.html</ref><ref name="lec20" />

===Immutable vs. Mutable===
Money values can be either mutable, meaning changeable, or immutable, meaning unchanging. Mutable money values are useful in that a new value does not need to be created for every change. However, mutable values cause problems for use in hash maps or with concurrency. The issue with concurrency is a read and write issue in a system with multiple users. With changing values, money not be what the user expects and lead to unpredictable behavior. Skrien feels this is a significant enough disadvantage to prefer an immutable representation for money.<ref name="lec20" />

==Possible Representations==
There are several possible ways to represent money in code.

===Floating Point Number===
Floating point numbers seem like an appealing option since they already include a fractional component, which lends itself straightforward to currencies like the US dollar which also have a fractional component. However, floating point numbers come with a drawback due to the way floats are formatted. Since floats are based on binary representation rather than a decimal representation, a value that would be exact in decimal notation can only be stored approximately in a floats point number. For instance, 9.48 is stored as 9.479999542236328125. Performing calculations with these approximated values can lead to inaccurate results. <ref name="dobbs">http://drdobbs.com/java/184405653</ref>

Another deficiency of floating point numbers is that they lose precision as the number gets larger. This is less of a problem when dealing with small amounts of currency, but when dealing with large amounts, on the order of the United States federal debt, the number of significant figures to the right of the decimal point decreases, again leading to possibly inaccurate results.<ref>Skrien, Dale. ''Object-Oriented Design Using Java''. McGraw Hill, 2009, p. 174.</ref>

===Two Integers===
For currencies with a fractional component, using two integers to represent one amount of money is an option. One integer to represent the main component and one to represent the fractional part. For US currency, this would mean an integer for dollars and an integer for cents. This representation makes displaying monetary values simple, as each component is already split out and accurate. Also, by using integers, calculations with money work out as they should, avoiding the loss of accuracy floating points have. However, code will need to be implemented to handle when the fraction component carries over. In the case of dollars and cents, if the cents exceed 100, the cents value should be decreased by 100 and the dollars increased by 1. This handling of carries adds overhead to calculations. Some drawbacks of this implementation are the added overhead and storage required<ref name="lec20" />. Another significant drawback is that such a system cannot represent fractions of a fundamental unit of currency. For example, in the United States, gasoline prices are typically represented with a precision of tenths of a cent per gallon. Another example is the stock market, where until early in the 21st century, stocks were traded in units of sixteenths of a dollar (6.25 cents.)<ref>http://www.infoplease.com/spot/stockdecimal1.html</ref>

===One Integer, Implied Decimal Point===
One integer can be used to represent money, even including the fractional component. The location of the decimal place is simply implied based on the currency. For instance, a single integer representation of $12.34 would be 1234. When dealing with US currency, this exploits the fact that the fundamental unit of currency in the US is actually the cent, not the dollar <ref name="dobbs"/>. A specialized print method would have to be constructed to display the monetary amount properly to the user, but all calculations work out properly. This approach has the same advantage that using two integers of maintaining accuracy, but does not have the added overhead or storage. In ''Object-Oriented Design Using Java'', Skrien considers this to be the best use of the primitive types for representing money.<ref name="lec20" />. This method shares the same deficiency of two integers in that it cannot represent fractions of a fundamental unit of money.

===BigDecimal===
Java offers a [http://docs.oracle.com/javase/6/docs/api/java/math/BigDecimal.html BigDecimal] class, which many people use for representing money. BigDecimal is capable of storing any size number since it stores each digit as an entry in an array, which grows as necessary. It also allows for specification of both the rounding method and the scale, the number of digits past the decimal place, for proper monetary calculations. <ref>http://www.javaranch.com/journal/2003/07/MoneyInJava.html</ref> On the downside, this specification for rounding and scale is required, which adds code to the implementation<ref name="dobbs" />. BigDecimal values are also immutable, which avoids read/write and write/write conflicts in applications. <ref>http://www.opentaps.org/docs/index.php/How_to_Use_Java_BigDecimal:_A_Tutorial</ref> While there are a lot of nice things about BigDecimal, there are some more issues with BigDecimal which can cause problems in representing money. BigDecimal cannot represent numbers with infinite digits such as 1/9 (.11111...) and throws an ArithmeticException on any calculation that would produce such number. To deal with this, hacks such as the following must be implemented:
BigDecimal bd1 = BigDecimal(1);
BigDecimal bd2 = BigDecimal(9);
try {
return bd1.divide(bd2);
} catch(ArithmaticException ae) {
return new BigDecimal(bd1.doubleValue() / bd2.doubleValue());
}
Also, since there isn't a BigDecimal equivalent for SQL databases, so storing BigDecimal values either requires conversion to a different format, which can affect accuracy and/or precision, or the value must be stored as a BLOB, which is cumbersome and inefficient. In general use, calculations with BigDecimal are significantly slower than with integers, and also take up more storage space. <ref>http://lemnik.wordpress.com/2011/03/25/bigdecimal-and-your-money/</ref>

===Class===
In ''Object-Oriented Design Using Java'', recommends using a class to represent money, rather than just using a long integer alone. He gives two reasons for using a class. The first is encapsulation - by encapsulating money into a class, all the operations specific to working with money can be implemented to work as desired in all cases, which also avoids code duplication. The second reason is that, in compiled languages like Java, the compiler is better able to detect coding errors, such as adding money to something that isn't money. <ref name="lec20" /> Implementing Money as a class is a generally good idea, but there are multiple ways to go about it.

====Abstract Class====
If multiple kinds of currencies are needed to be represented, one implementation is to create an abstract Money class and have each possible currency be a subclass of the abstract class. Since there are over 180 different currencies worldwide, it can be a challenge to implement subclasses for each one required.

The following is the abstract class proposed by Skrien in Object-Oriented Design Using Java:
public abstract class Money implements Comparable<Money> {
public long getAmount()
public String toString()
public int compareTo(Money m)
public boolean equals(Object o)
public int hashCode()
public Money plus(Money)
public Money minus(Money)
public Money times(double factor)
public Money dividedBy(double divisor)
public Money negate()
}
<ref name="skrien179">Skrien, Dale. Object-Oriented Design Using Java. McGraw Hill, 2009, p. 179-183.</ref>

====Single Class====
Rather than implementing a variety of subclasses for each currency, a single class can be used to represent money, with currency specified within. This is a good idea, since most modern currencies are decimal and as such can be calculated and treated in the same way. The only differences are in decimal locations and the symbols used to present them. Java has a [http://docs.oracle.com/javase/6/docs/api/java/util/Currency.html Currency class] which holds the information for a given currency.

This method is insufficient for representing a non-decimal currency, such as pre-1971 British currency (240 pence per pound sterling.)
The following is the Single Class implementation given by Skrien in ''Object-Oriented Design Using Java'':

public class Money implements Comparable<Money> {
private long amount;
private Currency currency;
public Money(long amount, Currency currency) {
this.amount = amount;
this.currency = currency;
}
public long getAmount() { return amount; }
public Currency getCurrency() {
return currency; }
public String toString() { ...above... }
public int compareTo(Money o) { ... }
public boolean equals(Object o) { ... }
public int hashCode() { ... }
public Money plus(Money) { ... }
public Money minus(Money) { ... }
public Money times(double factor) { ... }
public Money dividedBy(double divisor) { ... }
public Money negate() { ... }
}
<ref name="skrien179"/>

====Mixed Money====
When dealing with multiple currencies it might be necessary to keep track of money consisting of multiple currencies. Simply converting into one common currency is not a good approach, since exchange rates vary over time, so the amount of each currency should be kept track of. Skrien suggests using a MixedMoney class, which acts as a sort of wallet holding amounts of different currencies.

The following is Skrien's implementation of MixedMoney:
public class MixedMoney implements Money {
public MixedMoney() { ... }
public String toString() { ... }
public boolean equals(Object o) { ... }
public int hashCode() { ... }
public int compareTo(Money o) { ... }
public Money plus(Money) { ... }
public Money minus(Money) { ... }
public Money times(double factor) { ... }
public Money dividedBy(double divisor) { ... }
public Money negate() { ... }
public Collection getCurrencies() { ... }
public long getAmount(Currency currency) { ... }
}
<ref name="skrien179"/>

Since it uses a lot of the same methods as the regular Money class, Skrien renamed Money to SimpleMoney and created a common Money interface that is as follows:

public interface Money extends Comparable<Money> {
public int compareTo(Money o);
public Money plus(Money money);
public Money minus(Money money);
public Money times(double factor);
public Money dividedBy(double divisor);
public Money negate();
}
<ref name="skrien179"/>

The money within MixedMoney is suggested to be represented by either a hash map, a collection, or a tree structure. The hash map implementation is rejected for storage and calculation time issues. The tree structure is deemed the best approach as it is elegant and avoids checking classes.
<ref name="lec20" />

==Currency Conversion==
When dealing with multiple currencies, it is often necessary to convert from one to another.
Therefore some means for doing so must be implemented in any program that contains a representation of money. Skrien's implementation uses a MoneyConverter class that manages exchange rates and delegates the actual conversion and creation of a new money object denominated in the target currency to the Money class.

Skrien's implementation is as below:<ref name=skrien179/>
Public class MoneyConverter
{
public double getRate (Currency from, Currency to)
public void setRate (Currency from, Currency to, double rate)
public Money convertTo(Money money, Currency to) {
return money.convertTo(to, this);
}
}

==Money Implementations in Practice==
In practice, many decide similarly to Skrien to encapsulate Money as a class. The choice of underlying representation does vary, though, between types like int, double, or BigDecimal. I did not find any sources that used floats or two integers, which Skrien rejected. <ref name="dobbs" /><ref name="Representing Money">http://www.javapractices.com/topic/TopicAction.do?Id=13</ref> <ref name="C++">http://www.di-mare.com/adolfo/p/money.htm</ref> I found one source that addressed the issue of mixed money, which implemented a MoneyBag class that holds an array of Money. <ref name="testing">http://junit.sourceforge.net/doc/testinfected/testing.htm</ref>

There are also existing projects which seek to provide programmers with a library of classes to use for Money such as [http://timeandmoney.sourceforge.net/ Time and Money] and [http://joda-money.sourceforge.net/ Joda-Money].

==References==
<references />

CSC/ECE 517 Fall 2011/ch7 7a or

2011-12-03T03:29:06Z

Opevans: /* Two Integers */

Wiki Chapter: CSC/ECE 517 Fall 2011/ch7 7a or

''7a. Representing money. Skrien Chapter 6 gives an example of a class that can be used to represent money. But how is it done in real programs? Investigate, and report on the advantages and disadvantages of other approaches vs. Skrien's.''
__TOC__
==Introduction==
Money is very important to people worldwide and is something that often must be represented in computer programs. This raises the question of how money should be represented, which can vary from program to program. There is much to be considered such as string formatting, the way money is used, and the variety of different currencies in the world. In Chapter 6 of Skrien's ''Object-Oriented Design Using Java'', he suggests an implementation that represents money as a class, but there are other approaches that can be taken, each with their respective advantages and disadvantages.

==Properties of Money==
Money has certain properties and uses that must be considered in implementation.

===Responsibilities/Using Money===
The following are ways in which a representation of money should be able to be used: <ref name="lec20">http://courses.ncsu.edu/csc517/common/lectures/notes/lec20.pdf</ref>
*To represent a positive or negative amount of money.
*Possibly representing multiple components of a currency - i.e. dollars and cents.
*Possibly representing amounts of multiple currencies - i.e. a mix of US Dollars, euros, and yen.'
*To have a string formatting potentially including currency symbols like the dollar sign ($) and/or commas and/or decimal points.
*Addition, subtraction, multiplication, and division.
The degree to which of the above must be met will depend on the depth of the implementing project.

===Different Currencies===
Some applications may only handle only one currency such as the US Dollar, but more generally applied applications, such as banking, must be able to handle different kinds of currencies.

There are currently over 180 currencies in use around the world.<ref>http://en.wikipedia.org/wiki/List_of_circulating_currencies</ref>

Implementation must be aware of how to specifically represent each currency used. Some currencies use decimal points, such as how the US has 100 cents to a dollar, while others have no decimal, such as yen. Each currency also has a different sign symbol used such as $, €, or ¥. Different currencies also have different rules about how rounding values is handled.

Special consideration must be taken when using different currencies in conjunction with each other. Foreign exchange rates can be used to convert between different currencies, but the exchange rate often change, so attention must be paid to that. In some cases, it is also important to keep track of how much money the user has of more than one currency at a time, so that must be handled somehow. <ref>http://www.xencraft.com/resources/multi-currency.html</ref><ref name="lec20" />

===Immutable vs. Mutable===
Money values can be either mutable, meaning changeable, or immutable, meaning unchanging. Mutable money values are useful in that a new value does not need to be created for every change. However, mutable values cause problems for use in hash maps or with concurrency. The issue with concurrency is a read and write issue in a system with multiple users. With changing values, money not be what the user expects and lead to unpredictable behavior. Skrien feels this is a significant enough disadvantage to prefer an immutable representation for money.<ref name="lec20" />

==Possible Representations==
There are several possible ways to represent money in code.

===Floating Point Number===
Floating point numbers seem like an appealing option since they already include a fractional component, which lends itself straightforward to currencies like the US dollar which also have a fractional component. However, floating point numbers come with a drawback due to the way floats are formatted. Since floats are based on binary representation rather than a decimal representation, a value that would be exact in decimal notation can only be stored approximately in a floats point number. For instance, 9.48 is stored as 9.479999542236328125. Performing calculations with these approximated values can lead to inaccurate results. <ref name="dobbs">http://drdobbs.com/java/184405653</ref>

Another deficiency of floating point numbers is that they lose precision as the number gets larger. This is less of a problem when dealing with small amounts of currency, but when dealing with large amounts, on the order of the United States federal debt, the number of significant figures to the right of the decimal point decreases, again leading to possibly inaccurate results.<ref>Skrien, Dale. ''Object-Oriented Design Using Java''. McGraw Hill, 2009, p. 174.</ref>

===Two Integers===
For currencies with a fractional component, using two integers to represent one amount of money is an option. One integer to represent the main component and one to represent the fractional part. For US currency, this would mean an integer for dollars and an integer for cents. This representation makes displaying monetary values simple, as each component is already split out and accurate. Also, by using integers, calculations with money work out as they should, avoiding the loss of accuracy floating points have. However, code will need to be implemented to handle when the fraction component carries over. In the case of dollars and cents, if the cents exceed 100, the cents value should be decreased by 100 and the dollars increased by 1. This handling of carries adds overhead to calculations. Some drawbacks of this implementation are the added overhead and storage required<ref name="lec20" />. Another significant drawback is that such a system cannot represent fractions of a fundamental unit of currency. For example, in the United States, gasoline prices are typically represented with a precision of tenths of a cent per gallon. Another example is the stock market, where until early in the 21st century, stocks were traded in units of sixteenths of a dollar (6.25 cents.)<ref>http://www.infoplease.com/spot/stockdecimal1.html</ref>

===One Integer, Implied Decimal Point===
One integer can be used to represent money, even including the fractional component. The location of the decimal place is simply implied based on the currency. For instance, a single integer representation of $12.34 would be 1234. When dealing with US currency, this exploits the fact that the fundamental unit of currency in the US is actually the cent, not the dollar <ref name="dobbs"/>. A specialized print method would have to be constructed to display the monetary amount properly to the user, but all calculations work out properly. This approach has the same advantage that using two integers of maintaining accuracy, but does not have the added overhead or storage. In ''Object-Oriented Design Using Java'', Skrien considers this to be the best use of the primitive types for representing money.<ref name="lec20" />. This method shares the same deficiency of two integers in that it cannot represent fractions of a fundamental unit of money.

===BigDecimal===
Java offers a [http://docs.oracle.com/javase/6/docs/api/java/math/BigDecimal.html BigDecimal] class, which many people use for representing money. BigDecimal is capable of storing any size number since it stores each digit as an entry in an array, which grows as necessary. It also allows for specification of both the rounding method and the scale, the number of digits past the decimal place, for proper monetary calculations. <ref>http://www.javaranch.com/journal/2003/07/MoneyInJava.html</ref> On the downside, this specification for rounding and scale is required, which adds code to the implementation<ref name="dobbs" />. BigDecimal values are also immutable, which avoids read/write and write/write conflicts in applications. <ref>http://www.opentaps.org/docs/index.php/How_to_Use_Java_BigDecimal:_A_Tutorial</ref> While there are a lot of nice things about BigDecimal, there are some more issues with BigDecimal which can cause problems in representing money. BigDecimal cannot represent numbers with infinite digits such as 1/9 (.11111...) and throws an ArithmeticException on any calculation that would produce such number. To deal with this, hacks such as the following must be implemented:
BigDecimal bd1 = BigDecimal(1);
BigDecimal bd2 = BigDecimal(9);
try {
return bd1.divide(bd2);
} catch(ArithmaticException ae) {
return new BigDecimal(bd1.doubleValue() / bd2.doubleValue());
}
Also, since there isn't a BigDecimal equivalent for SQL databases, so storing BigDecimal values either requires conversion to a different format, which can affect accuracy and/or precision, or the value must be stored as a BLOB, which is cumbersome and inefficient. In general use, calculations with BigDecimal are significantly slower than with integers, and also take up more storage space. <ref>http://lemnik.wordpress.com/2011/03/25/bigdecimal-and-your-money/</ref>

===Class===
In ''Object-Oriented Design Using Java'', recommends using a class to represent money, rather than just using a long integer alone. He gives two reasons for using a class. The first is encapsulation - by encapsulating money into a class, all the operations specific to working with money can be implemented to work as desired in all cases, which also avoids code duplication. The second reason is that, in compiled languages like Java, the compiler is better able to detect coding errors, such as adding money to something that isn't money. <ref name="lec20" /> Implementing Money as a class is a generally good idea, but there are multiple ways to go about it.

====Abstract Class====
If multiple kinds of currencies are needed to be represented, one implementation is to create an abstract Money class and have each possible currency be a subclass of the abstract class. Since there are over 180 different currencies worldwide, it can be a challenge to implement subclasses for each one required.

The following is the abstract class proposed by Skrien in Object-Oriented Design Using Java:
public abstract class Money implements Comparable<Money> {
public long getAmount()
public String toString()
public int compareTo(Money m)
public boolean equals(Object o)
public int hashCode()
public Money plus(Money)
public Money minus(Money)
public Money times(double factor)
public Money dividedBy(double divisor)
public Money negate()
}
<ref name="skrien179">Skrien, Dale. Object-Oriented Design Using Java. McGraw Hill, 2009, p. 179-183.</ref>

====Single Class====
Rather than implementing a variety of subclasses for each currency, a single class can be used to represent money, with currency specified within. This is a good idea, since most modern currencies are decimal and as such can be calculated and treated in the same way. The only differences are in decimal locations and the symbols used to present them. Java has a [http://docs.oracle.com/javase/6/docs/api/java/util/Currency.html Currency class] which holds the information for a given currency.

This method is insufficient for representing a non-decimal currency, such as pre-1971 British currency (240 pence per pound sterling.)
The following is the Single Class implementation given by Skrien in ''Object-Oriented Design Using Java'':

public class Money implements Comparable<Money> {
private long amount;
private Currency currency;
public Money(long amount, Currency currency) {
this.amount = amount;
this.currency = currency;
}
public long getAmount() { return amount; }
public Currency getCurrency() {
return currency; }
public String toString() { ...above... }
public int compareTo(Money o) { ... }
public boolean equals(Object o) { ... }
public int hashCode() { ... }
public Money plus(Money) { ... }
public Money minus(Money) { ... }
public Money times(double factor) { ... }
public Money dividedBy(double divisor) { ... }
public Money negate() { ... }
}
<ref name="skrien179"/>

====Mixed Money====
When dealing with multiple currencies it might be necessary to keep track of money consisting of multiple currencies. Simply converting into one common currency is not a good approach, since exchange rates vary over time, so the amount of each currency should be kept track of. Skrien suggests using a MixedMoney class, which acts as a sort of wallet holding amounts of different currencies.

The following is Skrien's implementation of MixedMoney:
public class MixedMoney implements Money {
public MixedMoney() { ... }
public String toString() { ... }
public boolean equals(Object o) { ... }
public int hashCode() { ... }
public int compareTo(Money o) { ... }
public Money plus(Money) { ... }
public Money minus(Money) { ... }
public Money times(double factor) { ... }
public Money dividedBy(double divisor) { ... }
public Money negate() { ... }
public Collection getCurrencies() { ... }
public long getAmount(Currency currency) { ... }
}
<ref name="skrien179"/>

Since it uses a lot of the same methods as the regular Money class, Skrien renamed Money to SimpleMoney and created a common Money interface that is as follows:

public interface Money extends Comparable<Money> {
public int compareTo(Money o);
public Money plus(Money money);
public Money minus(Money money);
public Money times(double factor);
public Money dividedBy(double divisor);
public Money negate();
}
<ref name="skrien179"/>

The money within MixedMoney is suggested to be represented by either a hash map, a collection, or a tree structure. The hash map implementation is rejected for storage and calculation time issues. The tree structure is deemed the best approach as it is elegant and avoids checking classes.
<ref name="lec20" />

==Currency Conversion==
When dealing with multiple currencies, it is often necessary to convert from one to another.
Therefore some means for doing so must be implemented in any program that contains a representation of money. The best way to implement this is to create a member function of the money class that multiplies the amount by a conversion factor and returns a new money object denominated in the target currency.<ref name=skrien179/>

==Money Implementations in Practice==
In practice, many decide similarly to Skrien to encapsulate Money as a class. The choice of underlying representation does vary, though, between types like int, double, or BigDecimal. I did not find any sources that used floats or two integers, which Skrien rejected. <ref name="dobbs" /><ref name="Representing Money">http://www.javapractices.com/topic/TopicAction.do?Id=13</ref> <ref name="C++">http://www.di-mare.com/adolfo/p/money.htm</ref> I found one source that addressed the issue of mixed money, which implemented a MoneyBag class that holds an array of Money. <ref name="testing">http://junit.sourceforge.net/doc/testinfected/testing.htm</ref>

There are also existing projects which seek to provide programmers with a library of classes to use for Money such as [http://timeandmoney.sourceforge.net/ Time and Money] and [http://joda-money.sourceforge.net/ Joda-Money].

==References==
<references />

CSC/ECE 517 Fall 2011/ch7 7a or

2011-12-03T03:27:01Z

Opevans:

Wiki Chapter: CSC/ECE 517 Fall 2011/ch7 7a or

''7a. Representing money. Skrien Chapter 6 gives an example of a class that can be used to represent money. But how is it done in real programs? Investigate, and report on the advantages and disadvantages of other approaches vs. Skrien's.''
__TOC__
==Introduction==
Money is very important to people worldwide and is something that often must be represented in computer programs. This raises the question of how money should be represented, which can vary from program to program. There is much to be considered such as string formatting, the way money is used, and the variety of different currencies in the world. In Chapter 6 of Skrien's ''Object-Oriented Design Using Java'', he suggests an implementation that represents money as a class, but there are other approaches that can be taken, each with their respective advantages and disadvantages.

==Properties of Money==
Money has certain properties and uses that must be considered in implementation.

===Responsibilities/Using Money===
The following are ways in which a representation of money should be able to be used: <ref name="lec20">http://courses.ncsu.edu/csc517/common/lectures/notes/lec20.pdf</ref>
*To represent a positive or negative amount of money.
*Possibly representing multiple components of a currency - i.e. dollars and cents.
*Possibly representing amounts of multiple currencies - i.e. a mix of US Dollars, euros, and yen.'
*To have a string formatting potentially including currency symbols like the dollar sign ($) and/or commas and/or decimal points.
*Addition, subtraction, multiplication, and division.
The degree to which of the above must be met will depend on the depth of the implementing project.

===Different Currencies===
Some applications may only handle only one currency such as the US Dollar, but more generally applied applications, such as banking, must be able to handle different kinds of currencies.

There are currently over 180 currencies in use around the world.<ref>http://en.wikipedia.org/wiki/List_of_circulating_currencies</ref>

Implementation must be aware of how to specifically represent each currency used. Some currencies use decimal points, such as how the US has 100 cents to a dollar, while others have no decimal, such as yen. Each currency also has a different sign symbol used such as $, €, or ¥. Different currencies also have different rules about how rounding values is handled.

Special consideration must be taken when using different currencies in conjunction with each other. Foreign exchange rates can be used to convert between different currencies, but the exchange rate often change, so attention must be paid to that. In some cases, it is also important to keep track of how much money the user has of more than one currency at a time, so that must be handled somehow. <ref>http://www.xencraft.com/resources/multi-currency.html</ref><ref name="lec20" />

===Immutable vs. Mutable===
Money values can be either mutable, meaning changeable, or immutable, meaning unchanging. Mutable money values are useful in that a new value does not need to be created for every change. However, mutable values cause problems for use in hash maps or with concurrency. The issue with concurrency is a read and write issue in a system with multiple users. With changing values, money not be what the user expects and lead to unpredictable behavior. Skrien feels this is a significant enough disadvantage to prefer an immutable representation for money.<ref name="lec20" />

==Possible Representations==
There are several possible ways to represent money in code.

===Floating Point Number===
Floating point numbers seem like an appealing option since they already include a fractional component, which lends itself straightforward to currencies like the US dollar which also have a fractional component. However, floating point numbers come with a drawback due to the way floats are formatted. Since floats are based on binary representation rather than a decimal representation, a value that would be exact in decimal notation can only be stored approximately in a floats point number. For instance, 9.48 is stored as 9.479999542236328125. Performing calculations with these approximated values can lead to inaccurate results. <ref name="dobbs">http://drdobbs.com/java/184405653</ref>

Another deficiency of floating point numbers is that they lose precision as the number gets larger. This is less of a problem when dealing with small amounts of currency, but when dealing with large amounts, on the order of the United States federal debt, the number of significant figures to the right of the decimal point decreases, again leading to possibly inaccurate results.<ref>Skrien, Dale. ''Object-Oriented Design Using Java''. McGraw Hill, 2009, p. 174.</ref>

===Two Integers===
For currencies with a fractional component, using two integers to represent one amount of money is an option. One integer to represent the main component and one to represent the fractional part. For US currency, this would mean an integer for dollars and an integer for cents. This representation makes displaying monetary values simple, as each component is already split out and accurate. Also, by using integers, calculations with money work out as they should, avoiding the loss of accuracy floating points have. However, code will need to be implemented to handle when the fraction component carries over. In the case of dollars and cents, if the cents exceed 100, the cents value should be decreased by 100 and the dollars increased by 1. This handling of carries adds overhead to calculations. Some drawbacks of this implementation are the added overhead and storage required<ref name="lec20" />. Another significant drawback is that such a system cannot represent fractions of a fundamental unit of currencty. For example, in the United States, gasoline prices are typically represented with a precision of tenths of a cent per gallon. Another example is the stock market, where until early in the 21st century, stocks were traded in units of sixteenths of a dollar (6.25 cents.)<ref>http://www.infoplease.com/spot/stockdecimal1.html</ref>

===One Integer, Implied Decimal Point===
One integer can be used to represent money, even including the fractional component. The location of the decimal place is simply implied based on the currency. For instance, a single integer representation of $12.34 would be 1234. When dealing with US currency, this exploits the fact that the fundamental unit of currency in the US is actually the cent, not the dollar <ref name="dobbs"/>. A specialized print method would have to be constructed to display the monetary amount properly to the user, but all calculations work out properly. This approach has the same advantage that using two integers of maintaining accuracy, but does not have the added overhead or storage. In ''Object-Oriented Design Using Java'', Skrien considers this to be the best use of the primitive types for representing money.<ref name="lec20" />. This method shares the same deficiency of two integers in that it cannot represent fractions of a fundamental unit of money.

===BigDecimal===
Java offers a [http://docs.oracle.com/javase/6/docs/api/java/math/BigDecimal.html BigDecimal] class, which many people use for representing money. BigDecimal is capable of storing any size number since it stores each digit as an entry in an array, which grows as necessary. It also allows for specification of both the rounding method and the scale, the number of digits past the decimal place, for proper monetary calculations. <ref>http://www.javaranch.com/journal/2003/07/MoneyInJava.html</ref> On the downside, this specification for rounding and scale is required, which adds code to the implementation<ref name="dobbs" />. BigDecimal values are also immutable, which avoids read/write and write/write conflicts in applications. <ref>http://www.opentaps.org/docs/index.php/How_to_Use_Java_BigDecimal:_A_Tutorial</ref> While there are a lot of nice things about BigDecimal, there are some more issues with BigDecimal which can cause problems in representing money. BigDecimal cannot represent numbers with infinite digits such as 1/9 (.11111...) and throws an ArithmeticException on any calculation that would produce such number. To deal with this, hacks such as the following must be implemented:
BigDecimal bd1 = BigDecimal(1);
BigDecimal bd2 = BigDecimal(9);
try {
return bd1.divide(bd2);
} catch(ArithmaticException ae) {
return new BigDecimal(bd1.doubleValue() / bd2.doubleValue());
}
Also, since there isn't a BigDecimal equivalent for SQL databases, so storing BigDecimal values either requires conversion to a different format, which can affect accuracy and/or precision, or the value must be stored as a BLOB, which is cumbersome and inefficient. In general use, calculations with BigDecimal are significantly slower than with integers, and also take up more storage space. <ref>http://lemnik.wordpress.com/2011/03/25/bigdecimal-and-your-money/</ref>

===Class===
In ''Object-Oriented Design Using Java'', recommends using a class to represent money, rather than just using a long integer alone. He gives two reasons for using a class. The first is encapsulation - by encapsulating money into a class, all the operations specific to working with money can be implemented to work as desired in all cases, which also avoids code duplication. The second reason is that, in compiled languages like Java, the compiler is better able to detect coding errors, such as adding money to something that isn't money. <ref name="lec20" /> Implementing Money as a class is a generally good idea, but there are multiple ways to go about it.

====Abstract Class====
If multiple kinds of currencies are needed to be represented, one implementation is to create an abstract Money class and have each possible currency be a subclass of the abstract class. Since there are over 180 different currencies worldwide, it can be a challenge to implement subclasses for each one required.

The following is the abstract class proposed by Skrien in Object-Oriented Design Using Java:
public abstract class Money implements Comparable<Money> {
public long getAmount()
public String toString()
public int compareTo(Money m)
public boolean equals(Object o)
public int hashCode()
public Money plus(Money)
public Money minus(Money)
public Money times(double factor)
public Money dividedBy(double divisor)
public Money negate()
}
<ref name="skrien179">Skrien, Dale. Object-Oriented Design Using Java. McGraw Hill, 2009, p. 179-183.</ref>

====Single Class====
Rather than implementing a variety of subclasses for each currency, a single class can be used to represent money, with currency specified within. This is a good idea, since most modern currencies are decimal and as such can be calculated and treated in the same way. The only differences are in decimal locations and the symbols used to present them. Java has a [http://docs.oracle.com/javase/6/docs/api/java/util/Currency.html Currency class] which holds the information for a given currency.

This method is insufficient for representing a non-decimal currency, such as pre-1971 British currency (240 pence per pound sterling.)
The following is the Single Class implementation given by Skrien in ''Object-Oriented Design Using Java'':

public class Money implements Comparable<Money> {
private long amount;
private Currency currency;
public Money(long amount, Currency currency) {
this.amount = amount;
this.currency = currency;
}
public long getAmount() { return amount; }
public Currency getCurrency() {
return currency; }
public String toString() { ...above... }
public int compareTo(Money o) { ... }
public boolean equals(Object o) { ... }
public int hashCode() { ... }
public Money plus(Money) { ... }
public Money minus(Money) { ... }
public Money times(double factor) { ... }
public Money dividedBy(double divisor) { ... }
public Money negate() { ... }
}
<ref name="skrien179"/>

====Mixed Money====
When dealing with multiple currencies it might be necessary to keep track of money consisting of multiple currencies. Simply converting into one common currency is not a good approach, since exchange rates vary over time, so the amount of each currency should be kept track of. Skrien suggests using a MixedMoney class, which acts as a sort of wallet holding amounts of different currencies.

The following is Skrien's implementation of MixedMoney:
public class MixedMoney implements Money {
public MixedMoney() { ... }
public String toString() { ... }
public boolean equals(Object o) { ... }
public int hashCode() { ... }
public int compareTo(Money o) { ... }
public Money plus(Money) { ... }
public Money minus(Money) { ... }
public Money times(double factor) { ... }
public Money dividedBy(double divisor) { ... }
public Money negate() { ... }
public Collection getCurrencies() { ... }
public long getAmount(Currency currency) { ... }
}
<ref name="skrien179"/>

Since it uses a lot of the same methods as the regular Money class, Skrien renamed Money to SimpleMoney and created a common Money interface that is as follows:

public interface Money extends Comparable<Money> {
public int compareTo(Money o);
public Money plus(Money money);
public Money minus(Money money);
public Money times(double factor);
public Money dividedBy(double divisor);
public Money negate();
}
<ref name="skrien179"/>

The money within MixedMoney is suggested to be represented by either a hash map, a collection, or a tree structure. The hash map implementation is rejected for storage and calculation time issues. The tree structure is deemed the best approach as it is elegant and avoids checking classes.
<ref name="lec20" />

==Currency Conversion==
When dealing with multiple currencies, it is often necessary to convert from one to another.
Therefore some means for doing so must be implemented in any program that contains a representation of money. The best way to implement this is to create a member function of the money class that multiplies the amount by a conversion factor and returns a new money object denominated in the target currency.<ref name=skrien179/>

==Money Implementations in Practice==
In practice, many decide similarly to Skrien to encapsulate Money as a class. The choice of underlying representation does vary, though, between types like int, double, or BigDecimal. I did not find any sources that used floats or two integers, which Skrien rejected. <ref name="dobbs" /><ref name="Representing Money">http://www.javapractices.com/topic/TopicAction.do?Id=13</ref> <ref name="C++">http://www.di-mare.com/adolfo/p/money.htm</ref> I found one source that addressed the issue of mixed money, which implemented a MoneyBag class that holds an array of Money. <ref name="testing">http://junit.sourceforge.net/doc/testinfected/testing.htm</ref>

There are also existing projects which seek to provide programmers with a library of classes to use for Money such as [http://timeandmoney.sourceforge.net/ Time and Money] and [http://joda-money.sourceforge.net/ Joda-Money].

==References==
<references />

CSC/ECE 517 Fall 2011/ch7 7a or

2011-12-03T03:25:44Z

Opevans: /* Currency Conversion */

Wiki Chapter: CSC/ECE 517 Fall 2011/ch7 7a or

''7a. Representing money. Skrien Chapter 6 gives an example of a class that can be used to represent money. But how is it done in real programs? Investigate, and report on the advantages and disadvantages of other approaches vs. Skrien's.''
__TOC__
==Introduction==
Money is very important to people worldwide and is something that often must be represented in computer programs. This raises the question of how money should be represented, which can vary from program to program. There is much to be considered such as string formatting, the way money is used, and the variety of different currencies in the world. In Chapter 6 of Skrien's ''Object-Oriented Design Using Java'', he suggests an implementation that represents money as a class, but there are other approaches that can be taken, each with their respective advantages and disadvantages.

==Properties of Money==
Money has certain properties and uses that must be considered in implementation.

===Responsibilities/Using Money===
The following are ways in which a representation of money should be able to be used: <ref name="lec20">http://courses.ncsu.edu/csc517/common/lectures/notes/lec20.pdf</ref>
*To represent a positive or negative amount of money.
*Possibly representing multiple components of a currency - i.e. dollars and cents.
*Possibly representing amounts of multiple currencies - i.e. a mix of US Dollars, euros, and yen.'
*To have a string formatting potentially including currency symbols like the dollar sign ($) and/or commas and/or decimal points.
*Addition, subtraction, multiplication, and division.
The degree to which of the above must be met will depend on the depth of the implementing project.

===Different Currencies===
Some applications may only handle only one currency such as the US Dollar, but more generally applied applications, such as banking, must be able to handle different kinds of currencies.

There are currently over 180 currencies in use around the world.<ref>http://en.wikipedia.org/wiki/List_of_circulating_currencies</ref>

Implementation must be aware of how to specifically represent each currency used. Some currencies use decimal points, such as how the US has 100 cents to a dollar, while others have no decimal, such as yen. Each currency also has a different sign symbol used such as $, €, or ¥. Different currencies also have different rules about how rounding values is handled.

Special consideration must be taken when using different currencies in conjunction with each other. Foreign exchange rates can be used to convert between different currencies, but the exchange rate often change, so attention must be paid to that. In some cases, it is also important to keep track of how much money the user has of more than one currency at a time, so that must be handled somehow. <ref>http://www.xencraft.com/resources/multi-currency.html</ref><ref name="lec20" />

===Immutable vs. Mutable===
Money values can be either mutable, meaning changeable, or immutable, meaning unchanging. Mutable money values are useful in that a new value does not need to be created for every change. However, mutable values cause problems for use in hash maps or with concurrency. The issue with concurrency is a read and write issue in a system with multiple users. With changing values, money not be what the user expects and lead to unpredictable behavior. Skrien feels this is a significant enough disadvantage to prefer an immutable representation for money.<ref name="lec20" />

==Possible Representations==
There are several possible ways to represent money in code.

===Floating Point Number===
Floating point numbers seem like an appealing option since they already include a fractional component, which lends itself straightforward to currencies like the US dollar which also have a fractional component. However, floating point numbers come with a drawback due to the way floats are formatted. Since floats are based on binary representation rather than a decimal representation, a value that would be exact in decimal notation can only be stored approximately in a floats point number. For instance, 9.48 is stored as 9.479999542236328125. Performing calculations with these approximated values can lead to inaccurate results. <ref name="dobbs">http://drdobbs.com/java/184405653</ref>

Another deficiency of floating point numbers is that they lose precision as the number gets larger. This is less of a problem when dealing with small amounts of currency, but when dealing with large amounts, on the order of the United States federal debt, the number of significant figures to the right of the decimal point decreases, again leading to possibly inaccurate results.<ref>Skrien, Dale. ''Object-Oriented Design Using Java''. McGraw Hill, 2009, p. 174.</ref>

===Two Integers===
For currencies with a fractional component, using two integers to represent one amount of money is an option. One integer to represent the main component and one to represent the fractional part. For US currency, this would mean an integer for dollars and an integer for cents. This representation makes displaying monetary values simple, as each component is already split out and accurate. Also, by using integers, calculations with money work out as they should, avoiding the loss of accuracy floating points have. However, code will need to be implemented to handle when the fraction component carries over. In the case of dollars and cents, if the cents exceed 100, the cents value should be decreased by 100 and the dollars increased by 1. This handling of carries adds overhead to calculations. Some drawbacks of this implementation are the added overhead and storage required<ref name="lec20" />. Another significant drawback is that such a system cannot represent fractions of a fundamental unit of currencty. For example, in the United States, gasoline prices are typically represented with a precision of tenths of a cent per gallon. Another example is the stock market, where until early in the 21st century, stocks were traded in units of sixteenths of a dollar (6.25 cents.)<ref>http://www.infoplease.com/spot/stockdecimal1.html</ref>

===One Integer, Implied Decimal Point===
One integer can be used to represent money, even including the fractional component. The location of the decimal place is simply implied based on the currency. For instance, a single integer representation of $12.34 would be 1234. When dealing with US currency, this exploits the fact that the fundamental unit of currency in the US is actually the cent, not the dollar <ref name="dobbs"/>. A specialized print method would have to be constructed to display the monetary amount properly to the user, but all calculations work out properly. This approach has the same advantage that using two integers of maintaining accuracy, but does not have the added overhead or storage. In ''Object-Oriented Design Using Java'', Skrien considers this to be the best use of the primitive types for representing money.<ref name="lec20" />. This method shares the same deficiency of two integers in that it cannot represent fractions of a fundamental unit of money.

===BigDecimal===
Java offers a [http://docs.oracle.com/javase/6/docs/api/java/math/BigDecimal.html BigDecimal] class, which many people use for representing money. BigDecimal is capable of storing any size number since it stores each digit as an entry in an array, which grows as necessary. It also allows for specification of both the rounding method and the scale, the number of digits past the decimal place, for proper monetary calculations. <ref>http://www.javaranch.com/journal/2003/07/MoneyInJava.html</ref> On the downside, this specification for rounding and scale is required, which adds code to the implementation<ref name="dobbs" />. BigDecimal values are also immutable, which avoids read/write and write/write conflicts in applications. <ref>http://www.opentaps.org/docs/index.php/How_to_Use_Java_BigDecimal:_A_Tutorial</ref> While there are a lot of nice things about BigDecimal, there are some more issues with BigDecimal which can cause problems in representing money. BigDecimal cannot represent numbers with infinite digits such as 1/9 (.11111...) and throws an ArithmeticException on any calculation that would produce such number. To deal with this, hacks such as the following must be implemented:
BigDecimal bd1 = BigDecimal(1);
BigDecimal bd2 = BigDecimal(9);
try {
return bd1.divide(bd2);
} catch(ArithmaticException ae) {
return new BigDecimal(bd1.doubleValue() / bd2.doubleValue());
}
Also, since there isn't a BigDecimal equivalent for SQL databases, so storing BigDecimal values either requires conversion to a different format, which can affect accuracy and/or precision, or the value must be stored as a BLOB, which is cumbersome and inefficient. In general use, calculations with BigDecimal are significantly slower than with integers, and also take up more storage space. <ref>http://lemnik.wordpress.com/2011/03/25/bigdecimal-and-your-money/</ref>

===Class===
In ''Object-Oriented Design Using Java'', recommends using a class to represent money, rather than just using a long integer alone. He gives two reasons for using a class. The first is encapsulation - by encapsulating money into a class, all the operations specific to working with money can be implemented to work as desired in all cases, which also avoids code duplication. The second reason is that, in compiled languages like Java, the compiler is better able to detect coding errors, such as adding money to something that isn't money. <ref name="lec20" /> Implementing Money as a class is a generally good idea, but there are multiple ways to go about it.

====Abstract Class====
If multiple kinds of currencies are needed to be represented, one implementation is to create an abstract Money class and have each possible currency be a subclass of the abstract class. Since there are over 180 different currencies worldwide, it can be a challenge to implement subclasses for each one required.

The following is the abstract class proposed by Skrien in Object-Oriented Design Using Java:
public abstract class Money implements Comparable<Money> {
public long getAmount()
public String toString()
public int compareTo(Money m)
public boolean equals(Object o)
public int hashCode()
public Money plus(Money)
public Money minus(Money)
public Money times(double factor)
public Money dividedBy(double divisor)
public Money negate()
}
<ref name="skrien179">Skrien, Dale. Object-Oriented Design Using Java. McGraw Hill, 2009, p. 179-183.</ref>

====Single Class====
Rather than implementing a variety of subclasses for each currency, a single class can be used to represent money, with currency specified within. This is a good idea, since most modern currencies are decimal and as such can be calculated and treated in the same way. The only differences are in decimal locations and the symbols used to present them. Java has a [http://docs.oracle.com/javase/6/docs/api/java/util/Currency.html Currency class] which holds the information for a given currency.

This method is insufficient for representing a non-decimal currency, such as pre-1971 British currency (240 pence per pound sterling.)
The following is the Single Class implementation given by Skrien in ''Object-Oriented Design Using Java'':

public class Money implements Comparable<Money> {
private long amount;
private Currency currency;
public Money(long amount, Currency currency) {
this.amount = amount;
this.currency = currency;
}
public long getAmount() { return amount; }
public Currency getCurrency() {
return currency; }
public String toString() { ...above... }
public int compareTo(Money o) { ... }
public boolean equals(Object o) { ... }
public int hashCode() { ... }
public Money plus(Money) { ... }
public Money minus(Money) { ... }
public Money times(double factor) { ... }
public Money dividedBy(double divisor) { ... }
public Money negate() { ... }
}
<ref name="skrien179"/>

====Mixed Money====
When dealing with multiple currencies it might be necessary to keep track of money consisting of multiple currencies. Simply converting into one common currency is not a good approach, since exchange rates vary over time, so the amount of each currency should be kept track of. Skrien suggests using a MixedMoney class, which acts as a sort of wallet holding amounts of different currencies.

The following is Skrien's implementation of MixedMoney:
public class MixedMoney implements Money {
public MixedMoney() { ... }
public String toString() { ... }
public boolean equals(Object o) { ... }
public int hashCode() { ... }
public int compareTo(Money o) { ... }
public Money plus(Money) { ... }
public Money minus(Money) { ... }
public Money times(double factor) { ... }
public Money dividedBy(double divisor) { ... }
public Money negate() { ... }
public Collection getCurrencies() { ... }
public long getAmount(Currency currency) { ... }
}
<ref name="skrien179"/>

Since it uses a lot of the same methods as the regular Money class, Skrien renamed Money to SimpleMoney and created a common Money interface that is as follows:

public interface Money extends Comparable<Money> {
public int compareTo(Money o);
public Money plus(Money money);
public Money minus(Money money);
public Money times(double factor);
public Money dividedBy(double divisor);
public Money negate();
}
<ref name="skrien179"/>

The money within MixedMoney is suggested to be represented by either a hash map, a collection, or a tree structure. The hash map implementation is rejected for storage and calculation time issues. The tree structure is deemed the best approach as it is elegant and avoids checking classes.
<ref name="lec20" />

==Currency Conversion==
When dealing with multiple currencies, it is often necessary to convert from one to another.
Therefore some means for doing so must be implemented in any program that contains a representation of money. The best way to implement this is to create a member function of the money class that multiplies the amount by a conversion factor and returns a new money object denominated in the target currency. <ref name=skrien179>

==Money Implementations in Practice==
In practice, many decide similarly to Skrien to encapsulate Money as a class. The choice of underlying representation does vary, though, between types like int, double, or BigDecimal. I did not find any sources that used floats or two integers, which Skrien rejected. <ref name="dobbs" /><ref name="Representing Money">http://www.javapractices.com/topic/TopicAction.do?Id=13</ref> <ref name="C++">http://www.di-mare.com/adolfo/p/money.htm</ref> I found one source that addressed the issue of mixed money, which implemented a MoneyBag class that holds an array of Money. <ref name="testing">http://junit.sourceforge.net/doc/testinfected/testing.htm</ref>

There are also existing projects which seek to provide programmers with a library of classes to use for Money such as [http://timeandmoney.sourceforge.net/ Time and Money] and [http://joda-money.sourceforge.net/ Joda-Money].

==References==
<references />

CSC/ECE 517 Fall 2011/ch7 7a or

2011-12-02T05:03:48Z

Opevans:

Wiki Chapter: CSC/ECE 517 Fall 2011/ch7 7a or

''7a. Representing money. Skrien Chapter 6 gives an example of a class that can be used to represent money. But how is it done in real programs? Investigate, and report on the advantages and disadvantages of other approaches vs. Skrien's.''
__TOC__
==Introduction==
Money is very important to people worldwide and is something that often must be represented in computer programs. This raises the question of how money should be represented, which can vary from program to program. There is much to be considered such as string formatting, the way money is used, and the variety of different currencies in the world. In Chapter 6 of Skrien's ''Object-Oriented Design Using Java'', he suggests an implementation that represents money as a class, but there are other approaches that can be taken, each with their respective advantages and disadvantages.

==Properties of Money==
Money has certain properties and uses that must be considered in implementation.

===Responsibilities/Using Money===
The following are ways in which a representation of money should be able to be used: <ref name="lec20">http://courses.ncsu.edu/csc517/common/lectures/notes/lec20.pdf</ref>
*To represent a positive or negative amount of money.
*Possibly representing multiple components of a currency - i.e. dollars and cents.
*Possibly representing amounts of multiple currencies - i.e. a mix of US Dollars, euros, and yen.'
*To have a string formatting potentially including currency symbols like the dollar sign ($) and/or commas and/or decimal points.
*Addition, subtraction, multiplication, and division.
The degree to which of the above must be met will depend on the depth of the implementing project.

===Different Currencies===
Some applications may only handle only one currency such as the US Dollar, but more generally applied applications, such as banking, must be able to handle different kinds of currencies.

There are currently over 180 currencies in use around the world.<ref>http://en.wikipedia.org/wiki/List_of_circulating_currencies</ref>

Implementation must be aware of how to specifically represent each currency used. Some currencies use decimal points, such as how the US has 100 cents to a dollar, while others have no decimal, such as yen. Each currency also has a different sign symbol used such as $, €, or ¥. Different currencies also have different rules about how rounding values is handled.

Special consideration must be taken when using different currencies in conjunction with each other. Foreign exchange rates can be used to convert between different currencies, but the exchange rate often change, so attention must be paid to that. In some cases, it is also important to keep track of how much money the user has of more than one currency at a time, so that must be handled somehow. <ref>http://www.xencraft.com/resources/multi-currency.html</ref><ref name="lec20" />

===Immutable vs. Mutable===
Money values can be either mutable, meaning changeable, or immutable, meaning unchanging. Mutable money values are useful in that a new value does not need to be created for every change. However, mutable values cause problems for use in hash maps or with concurrency. The issue with concurrency is a read and write issue in a system with multiple users. With changing values, money not be what the user expects and lead to unpredictable behavior. Skrien feels this is a significant enough disadvantage to prefer an immutable representation for money.<ref name="lec20" />

==Possible Representations==
There are several possible ways to represent money in code.

===Floating Point Number===
Floating point numbers seem like an appealing option since they already include a fractional component, which lends itself straightforward to currencies like the US dollar which also have a fractional component. However, floating point numbers come with a drawback due to the way floats are formatted. Since floats are based on binary representation rather than a decimal representation, a value that would be exact in decimal notation can only be stored approximately in a floats point number. For instance, 9.48 is stored as 9.479999542236328125. Performing calculations with these approximated values can lead to inaccurate results. <ref name="dobbs">http://drdobbs.com/java/184405653</ref>

Another deficiency of floating point numbers is that they lose precision as the number gets larger. This is less of a problem when dealing with small amounts of currency, but when dealing with large amounts, on the order of the United States federal debt, the number of significant figures to the right of the decimal point decreases, again leading to possibly inaccurate results.<ref>Skrien, Dale. ''Object-Oriented Design Using Java''. McGraw Hill, 2009, p. 174.</ref>

===Two Integers===
For currencies with a fractional component, using two integers to represent one amount of money is an option. One integer to represent the main component and one to represent the fractional part. For US currency, this would mean an integer for dollars and an integer for cents. This representation makes displaying monetary values simple, as each component is already split out and accurate. Also, by using integers, calculations with money work out as they should, avoiding the loss of accuracy floating points have. However, code will need to be implemented to handle when the fraction component carries over. In the case of dollars and cents, if the cents exceed 100, the cents value should be decreased by 100 and the dollars increased by 1. This handling of carries adds overhead to calculations. Some drawbacks of this implementation are the added overhead and storage required<ref name="lec20" />. Another significant drawback is that such a system cannot represent fractions of a fundamental unit of currencty. For example, in the United States, gasoline prices are typically represented with a precision of tenths of a cent per gallon. Another example is the stock market, where until early in the 21st century, stocks were traded in units of sixteenths of a dollar (6.25 cents.)<ref>http://www.infoplease.com/spot/stockdecimal1.html</ref>

===One Integer, Implied Decimal Point===
One integer can be used to represent money, even including the fractional component. The location of the decimal place is simply implied based on the currency. For instance, a single integer representation of $12.34 would be 1234. When dealing with US currency, this exploits the fact that the fundamental unit of currency in the US is actually the cent, not the dollar <ref name="dobbs"/>. A specialized print method would have to be constructed to display the monetary amount properly to the user, but all calculations work out properly. This approach has the same advantage that using two integers of maintaining accuracy, but does not have the added overhead or storage. In ''Object-Oriented Design Using Java'', Skrien considers this to be the best use of the primitive types for representing money.<ref name="lec20" />. This method shares the same deficiency of two integers in that it cannot represent fractions of a fundamental unit of money.

===BigDecimal===
Java offers a [http://docs.oracle.com/javase/6/docs/api/java/math/BigDecimal.html BigDecimal] class, which many people use for representing money. BigDecimal is capable of storing any size number since it stores each digit as an entry in an array, which grows as necessary. It also allows for specification of both the rounding method and the scale, the number of digits past the decimal place, for proper monetary calculations. <ref>http://www.javaranch.com/journal/2003/07/MoneyInJava.html</ref> On the downside, this specification for rounding and scale is required, which adds code to the implementation<ref name="dobbs" />. BigDecimal values are also immutable, which avoids read/write and write/write conflicts in applications. <ref>http://www.opentaps.org/docs/index.php/How_to_Use_Java_BigDecimal:_A_Tutorial</ref> While there are a lot of nice things about BigDecimal, there are some more issues with BigDecimal which can cause problems in representing money. BigDecimal cannot represent numbers with infinite digits such as 1/9 (.11111...) and throws an ArithmeticException on any calculation that would produce such number. To deal with this, hacks such as the following must be implemented:
BigDecimal bd1 = BigDecimal(1);
BigDecimal bd2 = BigDecimal(9);
try {
return bd1.divide(bd2);
} catch(ArithmaticException ae) {
return new BigDecimal(bd1.doubleValue() / bd2.doubleValue());
}
Also, since there isn't a BigDecimal equivalent for SQL databases, so storing BigDecimal values either requires conversion to a different format, which can affect accuracy and/or precision, or the value must be stored as a BLOB, which is cumbersome and inefficient. In general use, calculations with BigDecimal are significantly slower than with integers, and also take up more storage space. <ref>http://lemnik.wordpress.com/2011/03/25/bigdecimal-and-your-money/</ref>

===Class===
In ''Object-Oriented Design Using Java'', recommends using a class to represent money, rather than just using a long integer alone. He gives two reasons for using a class. The first is encapsulation - by encapsulating money into a class, all the operations specific to working with money can be implemented to work as desired in all cases, which also avoids code duplication. The second reason is that, in compiled languages like Java, the compiler is better able to detect coding errors, such as adding money to something that isn't money. <ref name="lec20" /> Implementing Money as a class is a generally good idea, but there are multiple ways to go about it.

====Abstract Class====
If multiple kinds of currencies are needed to be represented, one implementation is to create an abstract Money class and have each possible currency be a subclass of the abstract class. Since there are over 180 different currencies worldwide, it can be a challenge to implement subclasses for each one required.

The following is the abstract class proposed by Skrien in Object-Oriented Design Using Java:
public abstract class Money implements Comparable<Money> {
public long getAmount()
public String toString()
public int compareTo(Money m)
public boolean equals(Object o)
public int hashCode()
public Money plus(Money)
public Money minus(Money)
public Money times(double factor)
public Money dividedBy(double divisor)
public Money negate()
}
<ref name="skrien179">Skrien, Dale. Object-Oriented Design Using Java. McGraw Hill, 2009, p. 179-183.</ref>

====Single Class====
Rather than implementing a variety of subclasses for each currency, a single class can be used to represent money, with currency specified within. This is a good idea, since most modern currencies are decimal and as such can be calculated and treated in the same way. The only differences are in decimal locations and the symbols used to present them. Java has a [http://docs.oracle.com/javase/6/docs/api/java/util/Currency.html Currency class] which holds the information for a given currency.

This method is insufficient for representing a non-decimal currency, such as pre-1971 British currency (240 pence per pound sterling.)
The following is the Single Class implementation given by Skrien in ''Object-Oriented Design Using Java'':

public class Money implements Comparable<Money> {
private long amount;
private Currency currency;
public Money(long amount, Currency currency) {
this.amount = amount;
this.currency = currency;
}
public long getAmount() { return amount; }
public Currency getCurrency() {
return currency; }
public String toString() { ...above... }
public int compareTo(Money o) { ... }
public boolean equals(Object o) { ... }
public int hashCode() { ... }
public Money plus(Money) { ... }
public Money minus(Money) { ... }
public Money times(double factor) { ... }
public Money dividedBy(double divisor) { ... }
public Money negate() { ... }
}
<ref name="skrien179"/>

====Mixed Money====
When dealing with multiple currencies it might be necessary to keep track of money consisting of multiple currencies. Simply converting into one common currency is not a good approach, since exchange rates vary over time, so the amount of each currency should be kept track of. Skrien suggests using a MixedMoney class, which acts as a sort of wallet holding amounts of different currencies.

The following is Skrien's implementation of MixedMoney:
public class MixedMoney implements Money {
public MixedMoney() { ... }
public String toString() { ... }
public boolean equals(Object o) { ... }
public int hashCode() { ... }
public int compareTo(Money o) { ... }
public Money plus(Money) { ... }
public Money minus(Money) { ... }
public Money times(double factor) { ... }
public Money dividedBy(double divisor) { ... }
public Money negate() { ... }
public Collection getCurrencies() { ... }
public long getAmount(Currency currency) { ... }
}
<ref name="skrien179"/>

Since it uses a lot of the same methods as the regular Money class, Skrien renamed Money to SimpleMoney and created a common Money interface that is as follows:

public interface Money extends Comparable<Money> {
public int compareTo(Money o);
public Money plus(Money money);
public Money minus(Money money);
public Money times(double factor);
public Money dividedBy(double divisor);
public Money negate();
}
<ref name="skrien179"/>

The money within MixedMoney is suggested to be represented by either a hash map, a collection, or a tree structure. The hash map implementation is rejected for storage and calculation time issues. The tree structure is deemed the best approach as it is elegant and avoids checking classes.
<ref name="lec20" />

==Currency Conversion==
Owen to insert useful section here by 12/2

==Money Implementations in Practice==
In practice, many decide similarly to Skrien to encapsulate Money as a class. The choice of underlying representation does vary, though, between types like int, double, or BigDecimal. I did not find any sources that used floats or two integers, which Skrien rejected. <ref name="dobbs" /><ref name="Representing Money">http://www.javapractices.com/topic/TopicAction.do?Id=13</ref> <ref name="C++">http://www.di-mare.com/adolfo/p/money.htm</ref> I found one source that addressed the issue of mixed money, which implemented a MoneyBag class that holds an array of Money. <ref name="testing">http://junit.sourceforge.net/doc/testinfected/testing.htm</ref>

There are also existing projects which seek to provide programmers with a library of classes to use for Money such as [http://timeandmoney.sourceforge.net/ Time and Money] and [http://joda-money.sourceforge.net/ Joda-Money].

==References==
<references />

CSC/ECE 517 Fall 2011/ch7 7a or

2011-12-02T04:47:24Z

Opevans: /* Single Class */

Wiki Chapter: CSC/ECE 517 Fall 2011/ch7 7a or

''7a. Representing money. Skrien Chapter 6 gives an example of a class that can be used to represent money. But how is it done in real programs? Investigate, and report on the advantages and disadvantages of other approaches vs. Skrien's.''
__TOC__
==Introduction==
Money is very important to people worldwide and is something that often must be represented in computer programs. This raises the question of how money should be represented, which can vary from program to program. There is much to be considered such as string formatting, the way money is used, and the variety of different currencies in the world. In Chapter 6 of Skrien's ''Object-Oriented Design Using Java'', he suggests an implementation that represents money as a class, but there are other approaches that can be taken, each with their respective advantages and disadvantages.

==Properties of Money==
Money has certain properties and uses that must be considered in implementation.

===Responsibilities/Using Money===
The following are ways in which a representation of money should be able to be used: <ref name="lec20">http://courses.ncsu.edu/csc517/common/lectures/notes/lec20.pdf</ref>
*To represent a positive or negative amount of money.
*Possibly representing multiple components of a currency - i.e. dollars and cents.
*Possibly representing amounts of multiple currencies - i.e. a mix of US Dollars, euros, and yen.'
*To have a string formatting potentially including currency symbols like the dollar sign ($) and/or commas and/or decimal points.
*Addition, subtraction, multiplication, and division.
The degree to which of the above must be met will depend on the depth of the implementing project.

===Different Currencies===
Some applications may only handle only one currency such as the US Dollar, but more generally applied applications, such as banking, must be able to handle different kinds of currencies.

There are currently over 180 currencies in use around the world.<ref>http://en.wikipedia.org/wiki/List_of_circulating_currencies</ref>

Implementation must be aware of how to specifically represent each currency used. Some currencies use decimal points, such as how the US has 100 cents to a dollar, while others have no decimal, such as yen. Each currency also has a different sign symbol used such as $, €, or ¥. Different currencies also have different rules about how rounding values is handled.

Special consideration must be taken when using different currencies in conjunction with each other. Foreign exchange rates can be used to convert between different currencies, but the exchange rate often change, so attention must be paid to that. In some cases, it is also important to keep track of how much money the user has of more than one currency at a time, so that must be handled somehow. <ref>http://www.xencraft.com/resources/multi-currency.html</ref><ref name="lec20" />

===Immutable vs. Mutable===
Money values can be either mutable, meaning changeable, or immutable, meaning unchanging. Mutable money values are useful in that a new value does not need to be created for every change. However, mutable values cause problems for use in hash maps or with concurrency. The issue with concurrency is a read and write issue in a system with multiple users. With changing values, money not be what the user expects and lead to unpredictable behavior. Skrien feels this is a significant enough disadvantage to prefer an immutable representation for money.<ref name="lec20" />

==Possible Representations==
There are several possible ways to represent money in code.

===Floating Point Number===
Floating point numbers seem like an appealing option since they already include a fractional component, which lends itself straightforward to currencies like the US dollar which also have a fractional component. However, floating point numbers come with a drawback due to the way floats are formatted. Since floats are based on binary representation rather than a decimal representation, a value that would be exact in decimal notation can only be stored approximately in a floats point number. For instance, 9.48 is stored as 9.479999542236328125. Performing calculations with these approximated values can lead to inaccurate results. <ref name="dobbs">http://drdobbs.com/java/184405653</ref>

Another deficiency of floating point numbers is that they lose precision as the number gets larger. This is less of a problem when dealing with small amounts of currency, but when dealing with large amounts, on the order of the United States federal debt, the number of significant figures to the right of the decimal point decreases, again leading to possibly inaccurate results.<ref>Skrien, Dale. ''Object-Oriented Design Using Java''. McGraw Hill, 2009, p. 174.</ref>

===Two Integers===
For currencies with a fractional component, using two integers to represent one amount of money is an option. One integer to represent the main component and one to represent the fractional part. For US currency, this would mean an integer for dollars and an integer for cents. This representation makes displaying monetary values simple, as each component is already split out and accurate. Also, by using integers, calculations with money work out as they should, avoiding the loss of accuracy floating points have. However, code will need to be implemented to handle when the fraction component carries over. In the case of dollars and cents, if the cents exceed 100, the cents value should be decreased by 100 and the dollars increased by 1. This handling of carries adds overhead to calculations. Some drawbacks of this implementation are the added overhead and storage required<ref name="lec20" />. Another significant drawback is that such a system cannot represent fractions of a fundamental unit of currencty. For example, in the United States, gasoline prices are typically represented with a precision of tenths of a cent per gallon. Another example is the stock market, where until early in the 21st century, stocks were traded in units of sixteenths of a dollar (6.25 cents.)<ref>http://www.infoplease.com/spot/stockdecimal1.html</ref>

===One Integer, Implied Decimal Point===
One integer can be used to represent money, even including the fractional component. The location of the decimal place is simply implied based on the currency. For instance, a single integer representation of $12.34 would be 1234. When dealing with US currency, this exploits the fact that the fundamental unit of currency in the US is actually the cent, not the dollar <ref name="dobbs"/>. A specialized print method would have to be constructed to display the monetary amount properly to the user, but all calculations work out properly. This approach has the same advantage that using two integers of maintaining accuracy, but does not have the added overhead or storage. In ''Object-Oriented Design Using Java'', Skrien considers this to be the best use of the primitive types for representing money.<ref name="lec20" />. This method shares the same deficiency of two integers in that it cannot represent fractions of a fundamental unit of money.

===BigDecimal===
Java offers a [http://docs.oracle.com/javase/6/docs/api/java/math/BigDecimal.html BigDecimal] class, which many people use for representing money. BigDecimal is capable of storing any size number since it stores each digit as an entry in an array, which grows as necessary. It also allows for specification of both the rounding method and the scale, the number of digits past the decimal place, for proper monetary calculations. <ref>http://www.javaranch.com/journal/2003/07/MoneyInJava.html</ref> On the downside, this specification for rounding and scale is required, which adds code to the implementation<ref name="dobbs" />. BigDecimal values are also immutable, which avoids read/write and write/write conflicts in applications. <ref>http://www.opentaps.org/docs/index.php/How_to_Use_Java_BigDecimal:_A_Tutorial</ref> While there are a lot of nice things about BigDecimal, there are some more issues with BigDecimal which can cause problems in representing money. BigDecimal cannot represent numbers with infinite digits such as 1/9 (.11111...) and throws an ArithmeticException on any calculation that would produce such number. To deal with this, hacks such as the following must be implemented:
BigDecimal bd1 = BigDecimal(1);
BigDecimal bd2 = BigDecimal(9);
try {
return bd1.divide(bd2);
} catch(ArithmaticException ae) {
return new BigDecimal(bd1.doubleValue() / bd2.doubleValue());
}
Also, since there isn't a BigDecimal equivalent for SQL databases, so storing BigDecimal values either requires conversion to a different format, which can affect accuracy and/or precision, or the value must be stored as a BLOB, which is cumbersome and inefficient. In general use, calculations with BigDecimal are significantly slower than with integers, and also take up more storage space. <ref>http://lemnik.wordpress.com/2011/03/25/bigdecimal-and-your-money/</ref>

===Class===
In ''Object-Oriented Design Using Java'', recommends using a class to represent money, rather than just using a long integer alone. He gives two reasons for using a class. The first is encapsulation - by encapsulating money into a class, all the operations specific to working with money can be implemented to work as desired in all cases, which also avoids code duplication. The second reason is that, in compiled languages like Java, the compiler is better able to detect coding errors, such as adding money to something that isn't money. <ref name="lec20" /> Implementing Money as a class is a generally good idea, but there are multiple ways to go about it.

====Abstract Class====
If multiple kinds of currencies are needed to be represented, one implementation is to create an abstract Money class and have each possible currency be a subclass of the abstract class. Since there are over 180 different currencies worldwide, it can be a challenge to implement subclasses for each one required.

The following is the abstract class proposed by Skrien in Object-Oriented Design Using Java:
public abstract class Money implements Comparable<Money> {
public long getAmount()
public String toString()
public int compareTo(Money m)
public boolean equals(Object o)
public int hashCode()
public Money plus(Money)
public Money minus(Money)
public Money times(double factor)
public Money dividedBy(double divisor)
public Money negate()
}
<ref name="skrien179">Skrien, Dale. Object-Oriented Design Using Java. McGraw Hill, 2009, p. 179-183.</ref>

====Single Class====
Rather than implementing a variety of subclasses for each currency, a single class can be used to represent money, with currency specified within. This is a good idea, since most modern currencies are decimal and as such can be calculated and treated in the same way. The only differences are in decimal locations and the symbols used to present them. Java has a [http://docs.oracle.com/javase/6/docs/api/java/util/Currency.html Currency class] which holds the information for a given currency.

This method is insufficient for representing a non-decimal currency, such as pre-1971 British currency (240 pence per pound sterling.)
The following is the Single Class implementation given by Skrien in ''Object-Oriented Design Using Java'':

public class Money implements Comparable<Money> {
private long amount;
private Currency currency;
public Money(long amount, Currency currency) {
this.amount = amount;
this.currency = currency;
}
public long getAmount() { return amount; }
public Currency getCurrency() {
return currency; }
public String toString() { ...above... }
public int compareTo(Money o) { ... }
public boolean equals(Object o) { ... }
public int hashCode() { ... }
public Money plus(Money) { ... }
public Money minus(Money) { ... }
public Money times(double factor) { ... }
public Money dividedBy(double divisor) { ... }
public Money negate() { ... }
}
<ref name="skrien179"/>

====Mixed Money====
When dealing with multiple currencies it might be necessary to keep track of money consisting of multiple currencies. Simply converting into one common currency is not a good approach, since exchange rates vary over time, so the amount of each currency should be kept track of. Skrien suggests using a MixedMoney class, which acts as a sort of wallet holding amounts of different currencies.

The following is Skrien's implementation of MixedMoney:
public class MixedMoney implements Money {
public MixedMoney() { ... }
public String toString() { ... }
public boolean equals(Object o) { ... }
public int hashCode() { ... }
public int compareTo(Money o) { ... }
public Money plus(Money) { ... }
public Money minus(Money) { ... }
public Money times(double factor) { ... }
public Money dividedBy(double divisor) { ... }
public Money negate() { ... }
public Collection getCurrencies() { ... }
public long getAmount(Currency currency) { ... }
}
<ref name="skrien179"/>

Since it uses a lot of the same methods as the regular Money class, Skrien renamed Money to SimpleMoney and created a common Money interface that is as follows:

public interface Money extends Comparable<Money> {
public int compareTo(Money o);
public Money plus(Money money);
public Money minus(Money money);
public Money times(double factor);
public Money dividedBy(double divisor);
public Money negate();
}
<ref name="skrien179"/>

The money within MixedMoney is suggested to be represented by either a hash map, a collection, or a tree structure. The hash map implementation is rejected for storage and calculation time issues. The tree structure is deemed the best approach as it is elegant and avoids checking classes.
<ref name="lec20" />

==Money Implementations in Practice==
In practice, many decide similarly to Skrien to encapsulate Money as a class. The choice of underlying representation does vary, though, between types like int, double, or BigDecimal. I did not find any sources that used floats or two integers, which Skrien rejected. <ref name="dobbs" /><ref name="Representing Money">http://www.javapractices.com/topic/TopicAction.do?Id=13</ref> <ref name="C++">http://www.di-mare.com/adolfo/p/money.htm</ref> I found one source that addressed the issue of mixed money, which implemented a MoneyBag class that holds an array of Money. <ref name="testing">http://junit.sourceforge.net/doc/testinfected/testing.htm</ref>

There are also existing projects which seek to provide programmers with a library of classes to use for Money such as [http://timeandmoney.sourceforge.net/ Time and Money] and [http://joda-money.sourceforge.net/ Joda-Money].

==References==
<references />

CSC/ECE 517 Fall 2011/ch7 7a or

2011-12-02T04:35:44Z

Opevans: /* Class */

Wiki Chapter: CSC/ECE 517 Fall 2011/ch7 7a or

''7a. Representing money. Skrien Chapter 6 gives an example of a class that can be used to represent money. But how is it done in real programs? Investigate, and report on the advantages and disadvantages of other approaches vs. Skrien's.''
__TOC__
==Introduction==
Money is very important to people worldwide and is something that often must be represented in computer programs. This raises the question of how money should be represented, which can vary from program to program. There is much to be considered such as string formatting, the way money is used, and the variety of different currencies in the world. In Chapter 6 of Skrien's ''Object-Oriented Design Using Java'', he suggests an implementation that represents money as a class, but there are other approaches that can be taken, each with their respective advantages and disadvantages.

==Properties of Money==
Money has certain properties and uses that must be considered in implementation.

===Responsibilities/Using Money===
The following are ways in which a representation of money should be able to be used: <ref name="lec20">http://courses.ncsu.edu/csc517/common/lectures/notes/lec20.pdf</ref>
*To represent a positive or negative amount of money.
*Possibly representing multiple components of a currency - i.e. dollars and cents.
*Possibly representing amounts of multiple currencies - i.e. a mix of US Dollars, euros, and yen.'
*To have a string formatting potentially including currency symbols like the dollar sign ($) and/or commas and/or decimal points.
*Addition, subtraction, multiplication, and division.
The degree to which of the above must be met will depend on the depth of the implementing project.

===Different Currencies===
Some applications may only handle only one currency such as the US Dollar, but more generally applied applications, such as banking, must be able to handle different kinds of currencies.

There are currently over 180 currencies in use around the world.<ref>http://en.wikipedia.org/wiki/List_of_circulating_currencies</ref>

Implementation must be aware of how to specifically represent each currency used. Some currencies use decimal points, such as how the US has 100 cents to a dollar, while others have no decimal, such as yen. Each currency also has a different sign symbol used such as $, €, or ¥. Different currencies also have different rules about how rounding values is handled.

Special consideration must be taken when using different currencies in conjunction with each other. Foreign exchange rates can be used to convert between different currencies, but the exchange rate often change, so attention must be paid to that. In some cases, it is also important to keep track of how much money the user has of more than one currency at a time, so that must be handled somehow. <ref>http://www.xencraft.com/resources/multi-currency.html</ref><ref name="lec20" />

===Immutable vs. Mutable===
Money values can be either mutable, meaning changeable, or immutable, meaning unchanging. Mutable money values are useful in that a new value does not need to be created for every change. However, mutable values cause problems for use in hash maps or with concurrency. The issue with concurrency is a read and write issue in a system with multiple users. With changing values, money not be what the user expects and lead to unpredictable behavior. Skrien feels this is a significant enough disadvantage to prefer an immutable representation for money.<ref name="lec20" />

==Possible Representations==
There are several possible ways to represent money in code.

===Floating Point Number===
Floating point numbers seem like an appealing option since they already include a fractional component, which lends itself straightforward to currencies like the US dollar which also have a fractional component. However, floating point numbers come with a drawback due to the way floats are formatted. Since floats are based on binary representation rather than a decimal representation, a value that would be exact in decimal notation can only be stored approximately in a floats point number. For instance, 9.48 is stored as 9.479999542236328125. Performing calculations with these approximated values can lead to inaccurate results. <ref name="dobbs">http://drdobbs.com/java/184405653</ref>

Another deficiency of floating point numbers is that they lose precision as the number gets larger. This is less of a problem when dealing with small amounts of currency, but when dealing with large amounts, on the order of the United States federal debt, the number of significant figures to the right of the decimal point decreases, again leading to possibly inaccurate results.<ref>Skrien, Dale. ''Object-Oriented Design Using Java''. McGraw Hill, 2009, p. 174.</ref>

===Two Integers===
For currencies with a fractional component, using two integers to represent one amount of money is an option. One integer to represent the main component and one to represent the fractional part. For US currency, this would mean an integer for dollars and an integer for cents. This representation makes displaying monetary values simple, as each component is already split out and accurate. Also, by using integers, calculations with money work out as they should, avoiding the loss of accuracy floating points have. However, code will need to be implemented to handle when the fraction component carries over. In the case of dollars and cents, if the cents exceed 100, the cents value should be decreased by 100 and the dollars increased by 1. This handling of carries adds overhead to calculations. Some drawbacks of this implementation are the added overhead and storage required<ref name="lec20" />. Another significant drawback is that such a system cannot represent fractions of a fundamental unit of currencty. For example, in the United States, gasoline prices are typically represented with a precision of tenths of a cent per gallon. Another example is the stock market, where until early in the 21st century, stocks were traded in units of sixteenths of a dollar (6.25 cents.)<ref>http://www.infoplease.com/spot/stockdecimal1.html</ref>

===One Integer, Implied Decimal Point===
One integer can be used to represent money, even including the fractional component. The location of the decimal place is simply implied based on the currency. For instance, a single integer representation of $12.34 would be 1234. When dealing with US currency, this exploits the fact that the fundamental unit of currency in the US is actually the cent, not the dollar <ref name="dobbs"/>. A specialized print method would have to be constructed to display the monetary amount properly to the user, but all calculations work out properly. This approach has the same advantage that using two integers of maintaining accuracy, but does not have the added overhead or storage. In ''Object-Oriented Design Using Java'', Skrien considers this to be the best use of the primitive types for representing money.<ref name="lec20" />. This method shares the same deficiency of two integers in that it cannot represent fractions of a fundamental unit of money.

===BigDecimal===
Java offers a [http://docs.oracle.com/javase/6/docs/api/java/math/BigDecimal.html BigDecimal] class, which many people use for representing money. BigDecimal is capable of storing any size number since it stores each digit as an entry in an array, which grows as necessary. It also allows for specification of both the rounding method and the scale, the number of digits past the decimal place, for proper monetary calculations. <ref>http://www.javaranch.com/journal/2003/07/MoneyInJava.html</ref> On the downside, this specification for rounding and scale is required, which adds code to the implementation<ref name="dobbs" />. BigDecimal values are also immutable, which avoids read/write and write/write conflicts in applications. <ref>http://www.opentaps.org/docs/index.php/How_to_Use_Java_BigDecimal:_A_Tutorial</ref> While there are a lot of nice things about BigDecimal, there are some more issues with BigDecimal which can cause problems in representing money. BigDecimal cannot represent numbers with infinite digits such as 1/9 (.11111...) and throws an ArithmeticException on any calculation that would produce such number. To deal with this, hacks such as the following must be implemented:
BigDecimal bd1 = BigDecimal(1);
BigDecimal bd2 = BigDecimal(9);
try {
return bd1.divide(bd2);
} catch(ArithmaticException ae) {
return new BigDecimal(bd1.doubleValue() / bd2.doubleValue());
}
Also, since there isn't a BigDecimal equivalent for SQL databases, so storing BigDecimal values either requires conversion to a different format, which can affect accuracy and/or precision, or the value must be stored as a BLOB, which is cumbersome and inefficient. In general use, calculations with BigDecimal are significantly slower than with integers, and also take up more storage space. <ref>http://lemnik.wordpress.com/2011/03/25/bigdecimal-and-your-money/</ref>

===Class===
In ''Object-Oriented Design Using Java'', recommends using a class to represent money, rather than just using a long integer alone. He gives two reasons for using a class. The first is encapsulation - by encapsulating money into a class, all the operations specific to working with money can be implemented to work as desired in all cases, which also avoids code duplication. The second reason is that, in compiled languages like Java, the compiler is better able to detect coding errors, such as adding money to something that isn't money. <ref name="lec20" /> Implementing Money as a class is a generally good idea, but there are multiple ways to go about it.

====Abstract Class====
If multiple kinds of currencies are needed to be represented, one implementation is to create an abstract Money class and have each possible currency be a subclass of the abstract class. Since there are over 180 different currencies worldwide, it can be a challenge to implement subclasses for each one required.

The following is the abstract class proposed by Skrien in Object-Oriented Design Using Java:
public abstract class Money implements Comparable<Money> {
public long getAmount()
public String toString()
public int compareTo(Money m)
public boolean equals(Object o)
public int hashCode()
public Money plus(Money)
public Money minus(Money)
public Money times(double factor)
public Money dividedBy(double divisor)
public Money negate()
}
<ref name="skrien179">Skrien, Dale. Object-Oriented Design Using Java. McGraw Hill, 2009, p. 179-183.</ref>

====Single Class====
Rather than implementing a variety of subclasses for each currency, a single class can be used to represent money, with currency specified within. This is a good idea, since most modern currencies are base-10 and as such can be calculated and treated in the same way. The only differences are in decimal locations and the symbols used to present them. Java has a [http://docs.oracle.com/javase/6/docs/api/java/util/Currency.html Currency class] which holds the information for a given currency.

This is insufficient for representing a non-base 10 currency, such as British currency prior to 1971 (240 pence per pound sterling.)
The following is the Single Class implementation given by Skrien in ''Object-Oriented Design Using Java'':

public class Money implements Comparable<Money> {
private long amount;
private Currency currency;
public Money(long amount, Currency currency) {
this.amount = amount;
this.currency = currency;
}
public long getAmount() { return amount; }
public Currency getCurrency() {
return currency; }
public String toString() { ...above... }
public int compareTo(Money o) { ... }
public boolean equals(Object o) { ... }
public int hashCode() { ... }
public Money plus(Money) { ... }
public Money minus(Money) { ... }
public Money times(double factor) { ... }
public Money dividedBy(double divisor) { ... }
public Money negate() { ... }
}
<ref name="skrien179"/>

====Mixed Money====
When dealing with multiple currencies it might be necessary to keep track of money consisting of multiple currencies. Simply converting into one common currency is not a good approach, since exchange rates vary over time, so the amount of each currency should be kept track of. Skrien suggests using a MixedMoney class, which acts as a sort of wallet holding amounts of different currencies.

The following is Skrien's implementation of MixedMoney:
public class MixedMoney implements Money {
public MixedMoney() { ... }
public String toString() { ... }
public boolean equals(Object o) { ... }
public int hashCode() { ... }
public int compareTo(Money o) { ... }
public Money plus(Money) { ... }
public Money minus(Money) { ... }
public Money times(double factor) { ... }
public Money dividedBy(double divisor) { ... }
public Money negate() { ... }
public Collection getCurrencies() { ... }
public long getAmount(Currency currency) { ... }
}
<ref name="skrien179"/>

Since it uses a lot of the same methods as the regular Money class, Skrien renamed Money to SimpleMoney and created a common Money interface that is as follows:

public interface Money extends Comparable<Money> {
public int compareTo(Money o);
public Money plus(Money money);
public Money minus(Money money);
public Money times(double factor);
public Money dividedBy(double divisor);
public Money negate();
}
<ref name="skrien179"/>

The money within MixedMoney is suggested to be represented by either a hash map, a collection, or a tree structure. The hash map implementation is rejected for storage and calculation time issues. The tree structure is deemed the best approach as it is elegant and avoids checking classes.
<ref name="lec20" />

==Money Implementations in Practice==
In practice, many decide similarly to Skrien to encapsulate Money as a class. The choice of underlying representation does vary, though, between types like int, double, or BigDecimal. I did not find any sources that used floats or two integers, which Skrien rejected. <ref name="dobbs" /><ref name="Representing Money">http://www.javapractices.com/topic/TopicAction.do?Id=13</ref> <ref name="C++">http://www.di-mare.com/adolfo/p/money.htm</ref> I found one source that addressed the issue of mixed money, which implemented a MoneyBag class that holds an array of Money. <ref name="testing">http://junit.sourceforge.net/doc/testinfected/testing.htm</ref>

There are also existing projects which seek to provide programmers with a library of classes to use for Money such as [http://timeandmoney.sourceforge.net/ Time and Money] and [http://joda-money.sourceforge.net/ Joda-Money].

==References==
<references />

CSC/ECE 517 Fall 2011/ch7 7a or

2011-12-02T04:13:05Z

Opevans:

Wiki Chapter: CSC/ECE 517 Fall 2011/ch7 7a or

''7a. Representing money. Skrien Chapter 6 gives an example of a class that can be used to represent money. But how is it done in real programs? Investigate, and report on the advantages and disadvantages of other approaches vs. Skrien's.''
__TOC__
==Introduction==
Money is very important to people worldwide and is something that often must be represented in computer programs. This raises the question of how money should be represented, which can vary from program to program. There is much to be considered such as string formatting, the way money is used, and the variety of different currencies in the world. In Chapter 6 of Skrien's ''Object-Oriented Design Using Java'', he suggests an implementation that represents money as a class, but there are other approaches that can be taken, each with their respective advantages and disadvantages.

==Properties of Money==
Money has certain properties and uses that must be considered in implementation.

===Responsibilities/Using Money===
The following are ways in which a representation of money should be able to be used: <ref name="lec20">http://courses.ncsu.edu/csc517/common/lectures/notes/lec20.pdf</ref>
*To represent a positive or negative amount of money.
*Possibly representing multiple components of a currency - i.e. dollars and cents.
*Possibly representing amounts of multiple currencies - i.e. a mix of US Dollars, euros, and yen.'
*To have a string formatting potentially including currency symbols like the dollar sign ($) and/or commas and/or decimal points.
*Addition, subtraction, multiplication, and division.
The degree to which of the above must be met will depend on the depth of the implementing project.

===Different Currencies===
Some applications may only handle only one currency such as the US Dollar, but more generally applied applications, such as banking, must be able to handle different kinds of currencies.

There are currently over 180 currencies in use around the world.<ref>http://en.wikipedia.org/wiki/List_of_circulating_currencies</ref>

Implementation must be aware of how to specifically represent each currency used. Some currencies use decimal points, such as how the US has 100 cents to a dollar, while others have no decimal, such as yen. Each currency also has a different sign symbol used such as $, €, or ¥. Different currencies also have different rules about how rounding values is handled.

Special consideration must be taken when using different currencies in conjunction with each other. Foreign exchange rates can be used to convert between different currencies, but the exchange rate often change, so attention must be paid to that. In some cases, it is also important to keep track of how much money the user has of more than one currency at a time, so that must be handled somehow. <ref>http://www.xencraft.com/resources/multi-currency.html</ref><ref name="lec20" />

===Immutable vs. Mutable===
Money values can be either mutable, meaning changeable, or immutable, meaning unchanging. Mutable money values are useful in that a new value does not need to be created for every change. However, mutable values cause problems for use in hash maps or with concurrency. The issue with concurrency is a read and write issue in a system with multiple users. With changing values, money not be what the user expects and lead to unpredictable behavior. Skrien feels this is a significant enough disadvantage to prefer an immutable representation for money.<ref name="lec20" />

==Possible Representations==
There are several possible ways to represent money in code.

===Floating Point Number===
Floating point numbers seem like an appealing option since they already include a fractional component, which lends itself straightforward to currencies like the US dollar which also have a fractional component. However, floating point numbers come with a drawback due to the way floats are formatted. Since floats are based on binary representation rather than a decimal representation, a value that would be exact in decimal notation can only be stored approximately in a floats point number. For instance, 9.48 is stored as 9.479999542236328125. Performing calculations with these approximated values can lead to inaccurate results. <ref name="dobbs">http://drdobbs.com/java/184405653</ref>

Another deficiency of floating point numbers is that they lose precision as the number gets larger. This is less of a problem when dealing with small amounts of currency, but when dealing with large amounts, on the order of the United States federal debt, the number of significant figures to the right of the decimal point decreases, again leading to possibly inaccurate results.<ref>Skrien, Dale. ''Object-Oriented Design Using Java''. McGraw Hill, 2009, p. 174.</ref>

===Two Integers===
For currencies with a fractional component, using two integers to represent one amount of money is an option. One integer to represent the main component and one to represent the fractional part. For US currency, this would mean an integer for dollars and an integer for cents. This representation makes displaying monetary values simple, as each component is already split out and accurate. Also, by using integers, calculations with money work out as they should, avoiding the loss of accuracy floating points have. However, code will need to be implemented to handle when the fraction component carries over. In the case of dollars and cents, if the cents exceed 100, the cents value should be decreased by 100 and the dollars increased by 1. This handling of carries adds overhead to calculations. Some drawbacks of this implementation are the added overhead and storage required<ref name="lec20" />. Another significant drawback is that such a system cannot represent fractions of a fundamental unit of currencty. For example, in the United States, gasoline prices are typically represented with a precision of tenths of a cent per gallon. Another example is the stock market, where until early in the 21st century, stocks were traded in units of sixteenths of a dollar (6.25 cents.)<ref>http://www.infoplease.com/spot/stockdecimal1.html</ref>

===One Integer, Implied Decimal Point===
One integer can be used to represent money, even including the fractional component. The location of the decimal place is simply implied based on the currency. For instance, a single integer representation of $12.34 would be 1234. When dealing with US currency, this exploits the fact that the fundamental unit of currency in the US is actually the cent, not the dollar <ref name="dobbs"/>. A specialized print method would have to be constructed to display the monetary amount properly to the user, but all calculations work out properly. This approach has the same advantage that using two integers of maintaining accuracy, but does not have the added overhead or storage. In ''Object-Oriented Design Using Java'', Skrien considers this to be the best use of the primitive types for representing money.<ref name="lec20" />. This method shares the same deficiency of two integers in that it cannot represent fractions of a fundamental unit of money.

===BigDecimal===
Java offers a [http://docs.oracle.com/javase/6/docs/api/java/math/BigDecimal.html BigDecimal] class, which many people use for representing money. BigDecimal is capable of storing any size number since it stores each digit as an entry in an array, which grows as necessary. It also allows for specification of both the rounding method and the scale, the number of digits past the decimal place, for proper monetary calculations. <ref>http://www.javaranch.com/journal/2003/07/MoneyInJava.html</ref> On the downside, this specification for rounding and scale is required, which adds code to the implementation<ref name="dobbs" />. BigDecimal values are also immutable, which avoids read/write and write/write conflicts in applications. <ref>http://www.opentaps.org/docs/index.php/How_to_Use_Java_BigDecimal:_A_Tutorial</ref> While there are a lot of nice things about BigDecimal, there are some more issues with BigDecimal which can cause problems in representing money. BigDecimal cannot represent numbers with infinite digits such as 1/9 (.11111...) and throws an ArithmeticException on any calculation that would produce such number. To deal with this, hacks such as the following must be implemented:
BigDecimal bd1 = BigDecimal(1);
BigDecimal bd2 = BigDecimal(9);
try {
return bd1.divide(bd2);
} catch(ArithmaticException ae) {
return new BigDecimal(bd1.doubleValue() / bd2.doubleValue());
}
Also, since there isn't a BigDecimal equivalent for SQL databases, so storing BigDecimal values either requires conversion to a different format, which can affect accuracy and/or precision, or the value must be stored as a BLOB, which is cumbersome and inefficient. In general use, calculations with BigDecimal are significantly slower than with integers, and also take up more storage space. <ref>http://lemnik.wordpress.com/2011/03/25/bigdecimal-and-your-money/</ref>

===Class===
In ''Object-Oriented Design Using Java'', recommends using a class to represent money, rather than just using a long integer alone. He gives two reasons for using a class. The first is encapsulation - by encapsulating money into a class, all the operations specific to working with money can be implemented to work as desired in all cases, which also avoids code duplication. The second reason is that the compiler is better able to detect coding errors, such as adding money to something that isn't money. <ref name="lec20" /> Implementing Money as a class is a generally good idea, but there are multiple ways to go about it.

====Abstract Class====
If multiple kinds of currencies are needed to be represented, one implementation is to create an abstract Money class and have each possible currency be a subclass of the abstract class. Since there are over 180 different currencies worldwide, it can be a challenge to implement subclasses for each one required.

The following is the abstract class proposed by Skrien in Object-Oriented Design Using Java:
public abstract class Money implements Comparable<Money> {
public long getAmount()
public String toString()
public int compareTo(Money m)
public boolean equals(Object o)
public int hashCode()
public Money plus(Money)
public Money minus(Money)
public Money times(double factor)
public Money dividedBy(double divisor)
public Money negate()
}
<ref name="skrien179">Skrien, Dale. Object-Oriented Design Using Java. McGraw Hill, 2009, p. 179-183.</ref>

====Single Class====
Rather than implementing a variety of subclasses for each currency, a single class can be used to represent money, with currency specified within. This is a good idea, since currencies basically operate the same calculation-wise, but have variations in decimal locations and the symbols used to present them. Java has a [http://docs.oracle.com/javase/6/docs/api/java/util/Currency.html Currency class] which holds the information for a given currency.

The following is the Single Class implementation given by Skrien in ''Object-Oriented Design Using Java'':

public class Money implements Comparable<Money> {
private long amount;
private Currency currency;
public Money(long amount, Currency currency) {
this.amount = amount;
this.currency = currency;
}
public long getAmount() { return amount; }
public Currency getCurrency() {
return currency; }
public String toString() { ...above... }
public int compareTo(Money o) { ... }
public boolean equals(Object o) { ... }
public int hashCode() { ... }
public Money plus(Money) { ... }
public Money minus(Money) { ... }
public Money times(double factor) { ... }
public Money dividedBy(double divisor) { ... }
public Money negate() { ... }
}
<ref name="skrien179"/>

====Mixed Money====
When dealing with multiple currencies it might be necessary to keep track of money consisting of multiple currencies. Simply converting into one common currency is not a good approach, since exchange rates vary over time, so the amount of each currency should be kept track of. Skrien suggests using a MixedMoney class, which acts as a sort of wallet holding amounts of different currencies.

The following is Skrien's implementation of MixedMoney:
public class MixedMoney implements Money {
public MixedMoney() { ... }
public String toString() { ... }
public boolean equals(Object o) { ... }
public int hashCode() { ... }
public int compareTo(Money o) { ... }
public Money plus(Money) { ... }
public Money minus(Money) { ... }
public Money times(double factor) { ... }
public Money dividedBy(double divisor) { ... }
public Money negate() { ... }
public Collection getCurrencies() { ... }
public long getAmount(Currency currency) { ... }
}
<ref name="skrien179"/>

Since it uses a lot of the same methods as the regular Money class, Skrien renamed Money to SimpleMoney and created a common Money interface that is as follows:

public interface Money extends Comparable<Money> {
public int compareTo(Money o);
public Money plus(Money money);
public Money minus(Money money);
public Money times(double factor);
public Money dividedBy(double divisor);
public Money negate();
}
<ref name="skrien179"/>

The money within MixedMoney is suggested to be represented by either a hash map, a collection, or a tree structure. The hash map implementation is rejected for storage and calculation time issues. The tree structure is deemed the best approach as it is elegant and avoids checking classes.
<ref name="lec20" />

==Money Implementations in Practice==
In practice, many decide similarly to Skrien to encapsulate Money as a class. The choice of underlying representation does vary, though, between types like int, double, or BigDecimal. I did not find any sources that used floats or two integers, which Skrien rejected. <ref name="dobbs" /><ref name="Representing Money">http://www.javapractices.com/topic/TopicAction.do?Id=13</ref> <ref name="C++">http://www.di-mare.com/adolfo/p/money.htm</ref> I found one source that addressed the issue of mixed money, which implemented a MoneyBag class that holds an array of Money. <ref name="testing">http://junit.sourceforge.net/doc/testinfected/testing.htm</ref>

There are also existing projects which seek to provide programmers with a library of classes to use for Money such as [http://timeandmoney.sourceforge.net/ Time and Money] and [http://joda-money.sourceforge.net/ Joda-Money].

==References==
<references />

CSC/ECE 517 Fall 2011/ch7 7a or

2011-12-01T04:09:37Z

Opevans: /* One Integer, Implied Decimal Point */

Wiki Chapter: CSC/ECE 517 Fall 2011/ch7 7a or

''7a. Representing money. Skrien Chapter 6 gives an example of a class that can be used to represent money. But how is it done in real programs? Investigate, and report on the advantages and disadvantages of other approaches vs. Skrien's.''
__TOC__
==Introduction==
Money is very important to people worldwide and is something that often must be represented in computer programs. This raises the question of how money should be represented, which can vary from program to program. There is much to be considered such as string formatting, the way money is used, and the variety of different currencies in the world. In Chapter 6 of Skrien's ''Object-Oriented Design Using Java'', he suggests an implementation that represents money as a class, but there are other approaches that can be taken, each with their respective advantages and disadvantages.

==Properties of Money==
Money has certain properties and uses that must be considered in implementation.

===Responsibilities/Using Money===
The following are ways in which a representation of money should be able to be used: <ref name="lec20">http://courses.ncsu.edu/csc517/common/lectures/notes/lec20.pdf</ref>
*To represent a positive or negative amount of money.
*Possibly representing multiple components of a currency - i.e. dollars and cents.
*Possibly representing amounts of multiple currencies - i.e. a mix of US Dollars, euros, and yen.'
*To have a string formatting potentially including currency symbols like the dollar sign ($) and/or commas and/or decimal points.
*Addition, subtraction, multiplication, and division.
The degree to which of the above must be met will depend on the depth of the implementing project.

===Different Currencies===
Some applications may only handle only one currency such as the US Dollar, but more generally applied applications, such as banking, must be able to handle different kinds of currencies.

There are currently over 180 currencies in use around the world.<ref>http://en.wikipedia.org/wiki/List_of_circulating_currencies</ref>

Implementation must be aware of how to specifically represent each currency used. Some currencies use decimal points, such as how the US has 100 cents to a dollar, while others have no decimal, such as yen. Each currency also has a different sign symbol used such as $, €, or ¥. Different currencies also have different rules about how rounding values is handled.

Special consideration must be taken when using different currencies in conjunction with each other. Foreign exchange rates can be used to convert between different currencies, but the exchange rate often change, so attention must be paid to that. In some cases, it is also important to keep track of how much money the user has of more than one currency at a time, so that must be handled somehow. <ref>http://www.xencraft.com/resources/multi-currency.html</ref><ref name="lec20" />

===Immutable vs. Mutable===
Money values can be either mutable, meaning changeable, or immutable, meaning unchanging. Mutable money values are useful in that a new value does not need to be created for every change. However, mutable values cause problems for use in hash maps or with concurrency. The issue with concurrency is a read and write issue in a system with multiple users. With changing values, money not be what the user expects and lead to unpredictable behavior. Skrien feels this is a significant enough disadvantage to prefer an immutable representation for money.<ref name="lec20" />

==Possible Representations==
There are several possible ways to represent money in code.

===Floating Point Number===
Floating point numbers seem like an appealing option since they already include a fractional component, which lends itself straightforward to currencies like the US dollar which also have a fractional component. However, floating point numbers come with a drawback due to the way floats are formatted. Since floats are based on binary representation rather than a decimal representation, a value that would be exact in decimal notation can only be stored approximately in a floats point number. For instance, 9.48 is stored as 9.479999542236328125. Performing calculations with these approximated values can lead to inaccurate results. <ref name="dobbs">http://drdobbs.com/java/184405653</ref>

Another deficiency of floating point numbers is that they lose precision as the number gets larger. This is less of a problem when dealing with small amounts of currency, but when dealing with large amounts, on the order of the United States federal debt, the number of significant figures to the right of the decimal point decreases, again leading to possibly inaccurate results.<ref>Skrien, Dale. ''Object-Oriented Design Using Java''. McGraw Hill, 2009, p. 174.</ref>

===Two Integers===
For currencies with a fractional component, using two integers to represent one amount of money is an option. One integer to represent the main component and one to represent the fractional part. For US currency, this would mean an integer for dollars and an integer for cents. This representation makes displaying monetary values simple, as each component is already split out and accurate. Also, by using integers, calculations with money work out as they should, avoiding the loss of accuracy floating points have. However, code will need to be implemented to handle when the fraction component carries over. In the case of dollars and cents, if the cents exceed 100, the cents value should be decreased by 100 and the dollars increased by 1. This handling of carries adds overhead to calculations. Some drawbacks of this implementation are the added overhead and storage required<ref name="lec20" />. Another significant drawback is that such a system cannot represent fractions of a fundamental unit of currencty. For example, in the United States, gasoline prices are typically represented with a precision of tenths of a cent per gallon. Another example is the stock market, where until early in the 21st century, stocks were traded in units of sixteenths of a dollar (6.25 cents.)<ref>http://www.infoplease.com/spot/stockdecimal1.html</ref>

===One Integer, Implied Decimal Point===
One integer can be used to represent money, even including the fractional component. The location of the decimal place is simply implied based on the currency. For instance, a single integer representation of $12.34 would be 1234. When dealing with US currency, this exploits the fact that the fundamental unit of currency in the US is actually the cent, not the dollar <ref name="dobbs"/>. A specialized print method would have to be constructed to display the monetary amount properly to the user, but all calculations work out properly. This approach has the same advantage that using two integers of maintaining accuracy, but does not have the added overhead or storage. In ''Object-Oriented Design Using Java'', Skrien considers this to be the best use of the primitive types for representing money.<ref name="lec20" />. This method shares the same deficiency of two integers in that it cannot represent fractions of a fundamental unit of money.

===BigDecimal===
Java offers a [http://docs.oracle.com/javase/6/docs/api/java/math/BigDecimal.html BigDecimal] class, which many people use for representing money. BigDecimal is capable of storing any size number since it stores each digit as an entry in an array, which grows as necessary. It also allows for specification of both the rounding method and the scale, the number of digits past the decimal place, for proper monetary calculations. <ref>http://www.javaranch.com/journal/2003/07/MoneyInJava.html</ref> On the downside, this specification for rounding and scale is required, which adds code to the implementation<ref name="dobbs" />. BigDecimal values are also immutable, which avoids read/write and write/write conflicts in applications. <ref>http://www.opentaps.org/docs/index.php/How_to_Use_Java_BigDecimal:_A_Tutorial</ref> While there are a lot of nice things about BigDecimal, there are some more issues with BigDecimal which can cause problems in representing money. BigDecimal cannot represent numbers with infinite digits such as 1/9 (.11111...) and throws an ArithmeticException on any calculation that would produce such number. To deal with this, hacks such as the following must be implemented:
BigDecimal bd1 = BigDecimal(1);
BigDecimal bd2 = BigDecimal(9);
try {
return bd1.divide(bd2);
} catch(ArithmaticException ae) {
return new BigDecimal(bd1.doubleValue() / bd2.doubleValue());
}
Also, since there isn't a BigDecimal equivalent for SQL databases, so storing BigDecimal values either requires conversion to a different format, which can affect accuracy and/or precision, or the value must be stored as a BLOB, which is cumbersome and inefficient. In general use, calculations with BigDecimal are significantly slower than with integers, and also take up more storage space. <ref>http://lemnik.wordpress.com/2011/03/25/bigdecimal-and-your-money/</ref>

===Class===
In ''Object-Oriented Design Using Java'', recommends using a class to represent money, rather than just using a long integer alone. He gives two reasons for using a class. The first is encapsulation - by encapsulating money into a class, all the operations specific to working with money can be implemented to work as desired in all cases, which also avoids code duplication. The second reason is that the compiler is better able to detect coding errors, such as adding money to something that isn't money. <ref name="lec20" /> Implementing Money as a class is a generally good idea, but there are multiple ways to go about it.

====Abstract Class====
If multiple kinds of currencies are needed to be represented, one implementation is to create an abstract Money class and have each possible currency be a subclass of the abstract class. Since there are over 180 different currencies worldwide, it can be a challenge to implement subclasses for each one required.

The following is the abstract class proposed by Skrien in Object-Oriented Design Using Java:
public abstract class Money implements Comparable<Money> {
public long getAmount()
public String toString()
public int compareTo(Money m)
public boolean equals(Object o)
public int hashCode()
public Money plus(Money)
public Money minus(Money)
public Money times(double factor)
public Money dividedBy(double divisor)
public Money negate()
}
<ref name="lec20" />

====Single Class====
Rather than implementing a variety of subclasses for each currency, a single class can be used to represent money, with currency specified within. This is a good idea, since currencies basically operate the same calculation-wise, but have variations in decimal locations and the symbols used to present them. Java has a [http://docs.oracle.com/javase/6/docs/api/java/util/Currency.html Currency class] which holds the information for a given currency.

The following is the Single Class implementation given by Skrien in ''Object-Oriented Design Using Java'':

public class Money implements Comparable<Money> {
private long amount;
private Currency currency;
public Money(long amount, Currency currency) {
this.amount = amount;
this.currency = currency;
}
public long getAmount() { return amount; }
public Currency getCurrency() {
return currency; }
public String toString() { ...above... }
public int compareTo(Money o) { ... }
public boolean equals(Object o) { ... }
public int hashCode() { ... }
public Money plus(Money) { ... }
public Money minus(Money) { ... }
public Money times(double factor) { ... }
public Money dividedBy(double divisor) { ... }
public Money negate() { ... }
}
<ref name="lec20" />

====Mixed Money====

====Using an Interface====

==Resources==
*Need to go through these for information
**[http://courses.ncsu.edu/csc517//common/lectures/notes/lec20.pdf PDF from class lecture]
**[http://docs.oracle.com/javase/1.4.2/docs/api/java/util/Currency.html Java's Currency class docs]
**[http://drdobbs.com/java/184405653 A standalone class to tackle the problem (in Java)]
**[http://www.javapractices.com/topic/TopicAction.do?Id=13 Representing money (Java)]
**[http://www.javaranch.com/journal/2003/07/MoneyInJava.html Working with money in Java]
**[http://timeandmoney.sourceforge.net/ Time and Money Java project - doesn't seem to have much documentation, though]
**[http://joda-money.sourceforge.net/ Joda Money class library for Java]
**[http://lemnik.wordpress.com/2011/03/25/bigdecimal-and-your-money/ BigDecimal and Your Money (a criticism of using BigDecimal format)]
**[http://www.opentaps.org/docs/index.php/How_to_Use_Java_BigDecimal:_A_Tutorial Tutorial on using BigDecimal]
**[http://junit.sourceforge.net/doc/testinfected/testing.htm JUnit Test Infected: Programmers Love Writing Tests (has a Money class example]
**[http://www.xencraft.com/resources/multi-currency.html Currency Internationalization (i18n), Multiple Currencies and Foreign Exchange (FX)] -nothing programming-wise, but a good overview of the considerations for currency
**[http://www.di-mare.com/adolfo/p/money.htm Yet Another C++ Money Class ]
**[http://edenti.deis.unibo.it/utils/Java-tips/Currency%20representation.txt Representing currencies (txt document with example and details)]

==References==
<references />

CSC/ECE 517 Fall 2011/ch7 7a or

2011-12-01T04:08:55Z

Opevans: /* Two Integers */

Wiki Chapter: CSC/ECE 517 Fall 2011/ch7 7a or

''7a. Representing money. Skrien Chapter 6 gives an example of a class that can be used to represent money. But how is it done in real programs? Investigate, and report on the advantages and disadvantages of other approaches vs. Skrien's.''
__TOC__
==Introduction==
Money is very important to people worldwide and is something that often must be represented in computer programs. This raises the question of how money should be represented, which can vary from program to program. There is much to be considered such as string formatting, the way money is used, and the variety of different currencies in the world. In Chapter 6 of Skrien's ''Object-Oriented Design Using Java'', he suggests an implementation that represents money as a class, but there are other approaches that can be taken, each with their respective advantages and disadvantages.

==Properties of Money==
Money has certain properties and uses that must be considered in implementation.

===Responsibilities/Using Money===
The following are ways in which a representation of money should be able to be used: <ref name="lec20">http://courses.ncsu.edu/csc517/common/lectures/notes/lec20.pdf</ref>
*To represent a positive or negative amount of money.
*Possibly representing multiple components of a currency - i.e. dollars and cents.
*Possibly representing amounts of multiple currencies - i.e. a mix of US Dollars, euros, and yen.'
*To have a string formatting potentially including currency symbols like the dollar sign ($) and/or commas and/or decimal points.
*Addition, subtraction, multiplication, and division.
The degree to which of the above must be met will depend on the depth of the implementing project.

===Different Currencies===
Some applications may only handle only one currency such as the US Dollar, but more generally applied applications, such as banking, must be able to handle different kinds of currencies.

There are currently over 180 currencies in use around the world.<ref>http://en.wikipedia.org/wiki/List_of_circulating_currencies</ref>

Implementation must be aware of how to specifically represent each currency used. Some currencies use decimal points, such as how the US has 100 cents to a dollar, while others have no decimal, such as yen. Each currency also has a different sign symbol used such as $, €, or ¥. Different currencies also have different rules about how rounding values is handled.

Special consideration must be taken when using different currencies in conjunction with each other. Foreign exchange rates can be used to convert between different currencies, but the exchange rate often change, so attention must be paid to that. In some cases, it is also important to keep track of how much money the user has of more than one currency at a time, so that must be handled somehow. <ref>http://www.xencraft.com/resources/multi-currency.html</ref><ref name="lec20" />

===Immutable vs. Mutable===
Money values can be either mutable, meaning changeable, or immutable, meaning unchanging. Mutable money values are useful in that a new value does not need to be created for every change. However, mutable values cause problems for use in hash maps or with concurrency. The issue with concurrency is a read and write issue in a system with multiple users. With changing values, money not be what the user expects and lead to unpredictable behavior. Skrien feels this is a significant enough disadvantage to prefer an immutable representation for money.<ref name="lec20" />

==Possible Representations==
There are several possible ways to represent money in code.

===Floating Point Number===
Floating point numbers seem like an appealing option since they already include a fractional component, which lends itself straightforward to currencies like the US dollar which also have a fractional component. However, floating point numbers come with a drawback due to the way floats are formatted. Since floats are based on binary representation rather than a decimal representation, a value that would be exact in decimal notation can only be stored approximately in a floats point number. For instance, 9.48 is stored as 9.479999542236328125. Performing calculations with these approximated values can lead to inaccurate results. <ref name="dobbs">http://drdobbs.com/java/184405653</ref>

Another deficiency of floating point numbers is that they lose precision as the number gets larger. This is less of a problem when dealing with small amounts of currency, but when dealing with large amounts, on the order of the United States federal debt, the number of significant figures to the right of the decimal point decreases, again leading to possibly inaccurate results.<ref>Skrien, Dale. ''Object-Oriented Design Using Java''. McGraw Hill, 2009, p. 174.</ref>

===Two Integers===
For currencies with a fractional component, using two integers to represent one amount of money is an option. One integer to represent the main component and one to represent the fractional part. For US currency, this would mean an integer for dollars and an integer for cents. This representation makes displaying monetary values simple, as each component is already split out and accurate. Also, by using integers, calculations with money work out as they should, avoiding the loss of accuracy floating points have. However, code will need to be implemented to handle when the fraction component carries over. In the case of dollars and cents, if the cents exceed 100, the cents value should be decreased by 100 and the dollars increased by 1. This handling of carries adds overhead to calculations. Some drawbacks of this implementation are the added overhead and storage required<ref name="lec20" />. Another significant drawback is that such a system cannot represent fractions of a fundamental unit of currencty. For example, in the United States, gasoline prices are typically represented with a precision of tenths of a cent per gallon. Another example is the stock market, where until early in the 21st century, stocks were traded in units of sixteenths of a dollar (6.25 cents.)<ref>http://www.infoplease.com/spot/stockdecimal1.html</ref>

===One Integer, Implied Decimal Point===
One integer can be used to represent money, even including the fractional component. The location of the decimal place is simply implied based on the currency. For instance, a single integer representation of $12.34 would be 1234. When dealing with US currency, this exploits the fact that the fundamental unit of currency in the US is actually the cent, not the dollar <ref name="dobbs"/>. A specialized print method would have to be constructed to display the monetary amount properly to the user, but all calculations work out properly. This approach has the same advantage that using two integers of maintaining accuracy, but does not have the added overhead or storage. In ''Object-Oriented Design Using Java'', Skrien considers this to be the best use of the primitive types for representing money.<ref name="lec20" />

===BigDecimal===
Java offers a [http://docs.oracle.com/javase/6/docs/api/java/math/BigDecimal.html BigDecimal] class, which many people use for representing money. BigDecimal is capable of storing any size number since it stores each digit as an entry in an array, which grows as necessary. It also allows for specification of both the rounding method and the scale, the number of digits past the decimal place, for proper monetary calculations. <ref>http://www.javaranch.com/journal/2003/07/MoneyInJava.html</ref> On the downside, this specification for rounding and scale is required, which adds code to the implementation<ref name="dobbs" />. BigDecimal values are also immutable, which avoids read/write and write/write conflicts in applications. <ref>http://www.opentaps.org/docs/index.php/How_to_Use_Java_BigDecimal:_A_Tutorial</ref> While there are a lot of nice things about BigDecimal, there are some more issues with BigDecimal which can cause problems in representing money. BigDecimal cannot represent numbers with infinite digits such as 1/9 (.11111...) and throws an ArithmeticException on any calculation that would produce such number. To deal with this, hacks such as the following must be implemented:
BigDecimal bd1 = BigDecimal(1);
BigDecimal bd2 = BigDecimal(9);
try {
return bd1.divide(bd2);
} catch(ArithmaticException ae) {
return new BigDecimal(bd1.doubleValue() / bd2.doubleValue());
}
Also, since there isn't a BigDecimal equivalent for SQL databases, so storing BigDecimal values either requires conversion to a different format, which can affect accuracy and/or precision, or the value must be stored as a BLOB, which is cumbersome and inefficient. In general use, calculations with BigDecimal are significantly slower than with integers, and also take up more storage space. <ref>http://lemnik.wordpress.com/2011/03/25/bigdecimal-and-your-money/</ref>

===Class===
In ''Object-Oriented Design Using Java'', recommends using a class to represent money, rather than just using a long integer alone. He gives two reasons for using a class. The first is encapsulation - by encapsulating money into a class, all the operations specific to working with money can be implemented to work as desired in all cases, which also avoids code duplication. The second reason is that the compiler is better able to detect coding errors, such as adding money to something that isn't money. <ref name="lec20" /> Implementing Money as a class is a generally good idea, but there are multiple ways to go about it.

====Abstract Class====
If multiple kinds of currencies are needed to be represented, one implementation is to create an abstract Money class and have each possible currency be a subclass of the abstract class. Since there are over 180 different currencies worldwide, it can be a challenge to implement subclasses for each one required.

The following is the abstract class proposed by Skrien in Object-Oriented Design Using Java:
public abstract class Money implements Comparable<Money> {
public long getAmount()
public String toString()
public int compareTo(Money m)
public boolean equals(Object o)
public int hashCode()
public Money plus(Money)
public Money minus(Money)
public Money times(double factor)
public Money dividedBy(double divisor)
public Money negate()
}
<ref name="lec20" />

====Single Class====
Rather than implementing a variety of subclasses for each currency, a single class can be used to represent money, with currency specified within. This is a good idea, since currencies basically operate the same calculation-wise, but have variations in decimal locations and the symbols used to present them. Java has a [http://docs.oracle.com/javase/6/docs/api/java/util/Currency.html Currency class] which holds the information for a given currency.

The following is the Single Class implementation given by Skrien in ''Object-Oriented Design Using Java'':

public class Money implements Comparable<Money> {
private long amount;
private Currency currency;
public Money(long amount, Currency currency) {
this.amount = amount;
this.currency = currency;
}
public long getAmount() { return amount; }
public Currency getCurrency() {
return currency; }
public String toString() { ...above... }
public int compareTo(Money o) { ... }
public boolean equals(Object o) { ... }
public int hashCode() { ... }
public Money plus(Money) { ... }
public Money minus(Money) { ... }
public Money times(double factor) { ... }
public Money dividedBy(double divisor) { ... }
public Money negate() { ... }
}
<ref name="lec20" />

====Mixed Money====

====Using an Interface====

==Resources==
*Need to go through these for information
**[http://courses.ncsu.edu/csc517//common/lectures/notes/lec20.pdf PDF from class lecture]
**[http://docs.oracle.com/javase/1.4.2/docs/api/java/util/Currency.html Java's Currency class docs]
**[http://drdobbs.com/java/184405653 A standalone class to tackle the problem (in Java)]
**[http://www.javapractices.com/topic/TopicAction.do?Id=13 Representing money (Java)]
**[http://www.javaranch.com/journal/2003/07/MoneyInJava.html Working with money in Java]
**[http://timeandmoney.sourceforge.net/ Time and Money Java project - doesn't seem to have much documentation, though]
**[http://joda-money.sourceforge.net/ Joda Money class library for Java]
**[http://lemnik.wordpress.com/2011/03/25/bigdecimal-and-your-money/ BigDecimal and Your Money (a criticism of using BigDecimal format)]
**[http://www.opentaps.org/docs/index.php/How_to_Use_Java_BigDecimal:_A_Tutorial Tutorial on using BigDecimal]
**[http://junit.sourceforge.net/doc/testinfected/testing.htm JUnit Test Infected: Programmers Love Writing Tests (has a Money class example]
**[http://www.xencraft.com/resources/multi-currency.html Currency Internationalization (i18n), Multiple Currencies and Foreign Exchange (FX)] -nothing programming-wise, but a good overview of the considerations for currency
**[http://www.di-mare.com/adolfo/p/money.htm Yet Another C++ Money Class ]
**[http://edenti.deis.unibo.it/utils/Java-tips/Currency%20representation.txt Representing currencies (txt document with example and details)]

==References==
<references />

CSC/ECE 517 Fall 2011/ch7 7a or

2011-12-01T03:25:53Z

Opevans: /* BigDecimal */

Wiki Chapter: CSC/ECE 517 Fall 2011/ch7 7a or

''7a. Representing money. Skrien Chapter 6 gives an example of a class that can be used to represent money. But how is it done in real programs? Investigate, and report on the advantages and disadvantages of other approaches vs. Skrien's.''
__TOC__
==Introduction==
Money is very important to people worldwide and is something that often must be represented in computer programs. This raises the question of how money should be represented, which can vary from program to program. There is much to be considered such as string formatting, the way money is used, and the variety of different currencies in the world. In Chapter 6 of Skrien's ''Object-Oriented Design Using Java'', he suggests an implementation that represents money as a class, but there are other approaches that can be taken, each with their respective advantages and disadvantages.

==Properties of Money==
Money has certain properties and uses that must be considered in implementation.

===Responsibilities/Using Money===
The following are ways in which a representation of money should be able to be used: <ref name="lec20">http://courses.ncsu.edu/csc517/common/lectures/notes/lec20.pdf</ref>
*To represent a positive or negative amount of money.
*Possibly representing multiple components of a currency - i.e. dollars and cents.
*Possibly representing amounts of multiple currencies - i.e. a mix of US Dollars, euros, and yen.'
*To have a string formatting potentially including currency symbols like the dollar sign ($) and/or commas and/or decimal points.
*Addition, subtraction, multiplication, and division.
The degree to which of the above must be met will depend on the depth of the implementing project.

===Different Currencies===
Some applications may only handle only one currency such as the US Dollar, but more generally applied applications, such as banking, must be able to handle different kinds of currencies.

There are currently over 180 currencies in use around the world.<ref>http://en.wikipedia.org/wiki/List_of_circulating_currencies</ref>

Implementation must be aware of how to specifically represent each currency used. Some currencies use decimal points, such as how the US has 100 cents to a dollar, while others have no decimal, such as yen. Each currency also has a different sign symbol used such as $, €, or ¥. Different currencies also have different rules about how rounding values is handled.

Special consideration must be taken when using different currencies in conjunction with each other. Foreign exchange rates can be used to convert between different currencies, but the exchange rate often change, so attention must be paid to that. In some cases, it is also important to keep track of how much money the user has of more than one currency at a time, so that must be handled somehow. <ref>http://www.xencraft.com/resources/multi-currency.html</ref><ref name="lec20" />

===Immutable vs. Mutable===
Money values can be either mutable, meaning changeable, or immutable, meaning unchanging. Mutable money values are useful in that a new value does not need to be created for every change. However, mutable values cause problems for use in hash maps or with concurrency. The issue with concurrency is a read and write issue in a system with multiple users. With changing values, money not be what the user expects and lead to unpredictable behavior. Skrien feels this is a significant enough disadvantage to prefer an immutable representation for money.<ref name="lec20" />

==Possible Representations==
There are several possible ways to represent money in code.

===Floating Point Number===
Floating point numbers seem like an appealing option since they already include a fractional component, which lends itself straightforward to currencies like the US dollar which also have a fractional component. However, floating point numbers come with a drawback due to the way floats are formatted. Since floats are based on binary representation rather than a decimal representation, a value that would be exact in decimal notation can only be stored approximately in a floats point number. For instance, 9.48 is stored as 9.479999542236328125. Performing calculations with these approximated values can lead to inaccurate results. <ref name="dobbs">http://drdobbs.com/java/184405653</ref>

Another deficiency of floating point numbers is that they lose precision as the number gets larger. This is less of a problem when dealing with small amounts of currency, but when dealing with large amounts, on the order of the United States federal debt, the number of significant figures to the right of the decimal point decreases, again leading to possibly inaccurate results.<ref>Skrien, Dale. ''Object-Oriented Design Using Java''. McGraw Hill, 2009, p. 174.</ref>

===Two Integers===
For currencies with a fractional component, using two integers to represent one amount of money is an option. One integer to represent the main component and one to represent the fractional part. For US currency, this would mean an integer for dollars and an integer for cents. This representation makes displaying monetary values simple, as each component is already split out and accurate. Also, by using integers, calculations with money work out as they should, avoiding the loss of accuracy floating points have. However, code will need to be implemented to handle when the fraction component carries over. In the case of dollars and cents, if the cents exceed 100, the cents value should be decreased by 100 and the dollars increased by 1. This handling of carries adds overhead to calculations. The main drawbacks of this implementation is the added overhead and storage required. <ref name="lec20" />

===One Integer, Implied Decimal Point===
One integer can be used to represent money, even including the fractional component. The location of the decimal place is simply implied based on the currency. For instance, a single integer representation of $12.34 would be 1234. When dealing with US currency, this exploits the fact that the fundamental unit of currency in the US is actually the cent, not the dollar <ref name="dobbs"/>. A specialized print method would have to be constructed to display the monetary amount properly to the user, but all calculations work out properly. This approach has the same advantage that using two integers of maintaining accuracy, but does not have the added overhead or storage. In ''Object-Oriented Design Using Java'', Skrien considers this to be the best use of the primitive types for representing money.<ref name="lec20" />

===BigDecimal===
Java offers a [http://docs.oracle.com/javase/6/docs/api/java/math/BigDecimal.html BigDecimal] class, which many people use for representing money. BigDecimal is capable of storing any size number since it stores each digit as an entry in an array, which grows as necessary. It also allows for specification of both the rounding method and the scale, the number of digits past the decimal place, for proper monetary calculations. <ref>http://www.javaranch.com/journal/2003/07/MoneyInJava.html</ref> On the downside, this specification for rounding and scale is required, which adds code to the implementation<ref name="dobbs" />. BigDecimal values are also immutable, which avoids read/write and write/write conflicts in applications. <ref>http://www.opentaps.org/docs/index.php/How_to_Use_Java_BigDecimal:_A_Tutorial</ref> While there are a lot of nice things about BigDecimal, there are some more issues with BigDecimal which can cause problems in representing money. BigDecimal cannot represent numbers with infinite digits such as 1/9 (.11111...) and throws an ArithmeticException on any calculation that would produce such number. To deal with this, hacks such as the following must be implemented:
BigDecimal bd1 = BigDecimal(1);
BigDecimal bd2 = BigDecimal(9);
try {
return bd1.divide(bd2);
} catch(ArithmaticException ae) {
return new BigDecimal(bd1.doubleValue() / bd2.doubleValue());
}
Also, since there isn't a BigDecimal equivalent for SQL databases, so storing BigDecimal values either requires conversion to a different format, which can affect accuracy and/or precision, or the value must be stored as a BLOB, which is cumbersome and inefficient. In general use, calculations with BigDecimal are significantly slower than with integers, and also take up more storage space. <ref>http://lemnik.wordpress.com/2011/03/25/bigdecimal-and-your-money/</ref>

===Class===
In ''Object-Oriented Design Using Java'', recommends using a class to represent money, rather than just using a long integer alone. He gives two reasons for using a class. The first is encapsulation - by encapsulating money into a class, all the operations specific to working with money can be implemented to work as desired in all cases, which also avoids code duplication. The second reason is that the compiler is better able to detect coding errors, such as adding money to something that isn't money. <ref name="lec20" /> Implementing Money as a class is a generally good idea, but there are multiple ways to go about it.

====Abstract Class====
If multiple kinds of currencies are needed to be represented, one implementation is to create an abstract Money class and have each possible currency be a subclass of the abstract class. Since there are over 180 different currencies worldwide, it can be a challenge to implement subclasses for each one required.

The following is the abstract class proposed by Skrien in Object-Oriented Design Using Java:
public abstract class Money implements Comparable<Money> {
public long getAmount()
public String toString()
public int compareTo(Money m)
public boolean equals(Object o)
public int hashCode()
public Money plus(Money)
public Money minus(Money)
public Money times(double factor)
public Money dividedBy(double divisor)
public Money negate()
}
<ref name="lec20" />

====Single Class====
Rather than implementing a variety of subclasses for each currency, a single class can be used to represent money, with currency specified within. This is a good idea, since currencies basically operate the same calculation-wise, but have variations in decimal locations and the symbols used to present them. Java has a [http://docs.oracle.com/javase/6/docs/api/java/util/Currency.html Currency class] which holds the information for a given currency.

The following is the Single Class implementation given by Skrien in ''Object-Oriented Design Using Java'':

public class Money implements Comparable<Money> {
private long amount;
private Currency currency;
public Money(long amount, Currency currency) {
this.amount = amount;
this.currency = currency;
}
public long getAmount() { return amount; }
public Currency getCurrency() {
return currency; }
public String toString() { ...above... }
public int compareTo(Money o) { ... }
public boolean equals(Object o) { ... }
public int hashCode() { ... }
public Money plus(Money) { ... }
public Money minus(Money) { ... }
public Money times(double factor) { ... }
public Money dividedBy(double divisor) { ... }
public Money negate() { ... }
}
<ref name="lec20" />

====Mixed Money====

====Using an Interface====

==Resources==
*Need to go through these for information
**[http://courses.ncsu.edu/csc517//common/lectures/notes/lec20.pdf PDF from class lecture]
**[http://docs.oracle.com/javase/1.4.2/docs/api/java/util/Currency.html Java's Currency class docs]
**[http://drdobbs.com/java/184405653 A standalone class to tackle the problem (in Java)]
**[http://www.javapractices.com/topic/TopicAction.do?Id=13 Representing money (Java)]
**[http://www.javaranch.com/journal/2003/07/MoneyInJava.html Working with money in Java]
**[http://timeandmoney.sourceforge.net/ Time and Money Java project - doesn't seem to have much documentation, though]
**[http://joda-money.sourceforge.net/ Joda Money class library for Java]
**[http://lemnik.wordpress.com/2011/03/25/bigdecimal-and-your-money/ BigDecimal and Your Money (a criticism of using BigDecimal format)]
**[http://www.opentaps.org/docs/index.php/How_to_Use_Java_BigDecimal:_A_Tutorial Tutorial on using BigDecimal]
**[http://junit.sourceforge.net/doc/testinfected/testing.htm JUnit Test Infected: Programmers Love Writing Tests (has a Money class example]
**[http://www.xencraft.com/resources/multi-currency.html Currency Internationalization (i18n), Multiple Currencies and Foreign Exchange (FX)] -nothing programming-wise, but a good overview of the considerations for currency
**[http://www.di-mare.com/adolfo/p/money.htm Yet Another C++ Money Class ]
**[http://edenti.deis.unibo.it/utils/Java-tips/Currency%20representation.txt Representing currencies (txt document with example and details)]

==References==
<references />

CSC/ECE 517 Fall 2011/ch7 7a or

2011-12-01T03:25:07Z

Opevans: /* BigDecimal */

Wiki Chapter: CSC/ECE 517 Fall 2011/ch7 7a or

''7a. Representing money. Skrien Chapter 6 gives an example of a class that can be used to represent money. But how is it done in real programs? Investigate, and report on the advantages and disadvantages of other approaches vs. Skrien's.''
__TOC__
==Introduction==
Money is very important to people worldwide and is something that often must be represented in computer programs. This raises the question of how money should be represented, which can vary from program to program. There is much to be considered such as string formatting, the way money is used, and the variety of different currencies in the world. In Chapter 6 of Skrien's ''Object-Oriented Design Using Java'', he suggests an implementation that represents money as a class, but there are other approaches that can be taken, each with their respective advantages and disadvantages.

==Properties of Money==
Money has certain properties and uses that must be considered in implementation.

===Responsibilities/Using Money===
The following are ways in which a representation of money should be able to be used: <ref name="lec20">http://courses.ncsu.edu/csc517/common/lectures/notes/lec20.pdf</ref>
*To represent a positive or negative amount of money.
*Possibly representing multiple components of a currency - i.e. dollars and cents.
*Possibly representing amounts of multiple currencies - i.e. a mix of US Dollars, euros, and yen.'
*To have a string formatting potentially including currency symbols like the dollar sign ($) and/or commas and/or decimal points.
*Addition, subtraction, multiplication, and division.
The degree to which of the above must be met will depend on the depth of the implementing project.

===Different Currencies===
Some applications may only handle only one currency such as the US Dollar, but more generally applied applications, such as banking, must be able to handle different kinds of currencies.

There are currently over 180 currencies in use around the world.<ref>http://en.wikipedia.org/wiki/List_of_circulating_currencies</ref>

Implementation must be aware of how to specifically represent each currency used. Some currencies use decimal points, such as how the US has 100 cents to a dollar, while others have no decimal, such as yen. Each currency also has a different sign symbol used such as $, €, or ¥. Different currencies also have different rules about how rounding values is handled.

Special consideration must be taken when using different currencies in conjunction with each other. Foreign exchange rates can be used to convert between different currencies, but the exchange rate often change, so attention must be paid to that. In some cases, it is also important to keep track of how much money the user has of more than one currency at a time, so that must be handled somehow. <ref>http://www.xencraft.com/resources/multi-currency.html</ref><ref name="lec20" />

===Immutable vs. Mutable===
Money values can be either mutable, meaning changeable, or immutable, meaning unchanging. Mutable money values are useful in that a new value does not need to be created for every change. However, mutable values cause problems for use in hash maps or with concurrency. The issue with concurrency is a read and write issue in a system with multiple users. With changing values, money not be what the user expects and lead to unpredictable behavior. Skrien feels this is a significant enough disadvantage to prefer an immutable representation for money.<ref name="lec20" />

==Possible Representations==
There are several possible ways to represent money in code.

===Floating Point Number===
Floating point numbers seem like an appealing option since they already include a fractional component, which lends itself straightforward to currencies like the US dollar which also have a fractional component. However, floating point numbers come with a drawback due to the way floats are formatted. Since floats are based on binary representation rather than a decimal representation, a value that would be exact in decimal notation can only be stored approximately in a floats point number. For instance, 9.48 is stored as 9.479999542236328125. Performing calculations with these approximated values can lead to inaccurate results. <ref name="dobbs">http://drdobbs.com/java/184405653</ref>

Another deficiency of floating point numbers is that they lose precision as the number gets larger. This is less of a problem when dealing with small amounts of currency, but when dealing with large amounts, on the order of the United States federal debt, the number of significant figures to the right of the decimal point decreases, again leading to possibly inaccurate results.<ref>Skrien, Dale. ''Object-Oriented Design Using Java''. McGraw Hill, 2009, p. 174.</ref>

===Two Integers===
For currencies with a fractional component, using two integers to represent one amount of money is an option. One integer to represent the main component and one to represent the fractional part. For US currency, this would mean an integer for dollars and an integer for cents. This representation makes displaying monetary values simple, as each component is already split out and accurate. Also, by using integers, calculations with money work out as they should, avoiding the loss of accuracy floating points have. However, code will need to be implemented to handle when the fraction component carries over. In the case of dollars and cents, if the cents exceed 100, the cents value should be decreased by 100 and the dollars increased by 1. This handling of carries adds overhead to calculations. The main drawbacks of this implementation is the added overhead and storage required. <ref name="lec20" />

===One Integer, Implied Decimal Point===
One integer can be used to represent money, even including the fractional component. The location of the decimal place is simply implied based on the currency. For instance, a single integer representation of $12.34 would be 1234. When dealing with US currency, this exploits the fact that the fundamental unit of currency in the US is actually the cent, not the dollar <ref name="dobbs"/>. A specialized print method would have to be constructed to display the monetary amount properly to the user, but all calculations work out properly. This approach has the same advantage that using two integers of maintaining accuracy, but does not have the added overhead or storage. In ''Object-Oriented Design Using Java'', Skrien considers this to be the best use of the primitive types for representing money.<ref name="lec20" />

===BigDecimal===
Java offers a [http://docs.oracle.com/javase/6/docs/api/java/math/BigDecimal.html BigDecimal] class, which many people use for representing money. BigDecimal is capable of storing any size number since it stores each digit as an entry in an array, which grows as necessary. It also allows for specification of both the rounding method and the scale, the number of digits past the decimal place, for proper monetary calculations. <ref>http://www.javaranch.com/journal/2003/07/MoneyInJava.html</ref> On the downside, this specification for rounding and scale is required, which adds code to the implementation. <ref name="dobbs" />BigDecimal values are also immutable, which avoids read/write and write/write conflicts in applications. [http://www.opentaps.org/docs/index.php/How_to_Use_Java_BigDecimal:_A_Tutorial] While there are a lot of nice things about BigDecimal, there are some more issues with BigDecimal which can cause problems in representing money. BigDecimal cannot represent numbers with infinite digits such as 1/9 (.11111...) and throws an ArithmeticException on any calculation that would produce such number. To deal with this, hacks such as the following must be implemented:
BigDecimal bd1 = BigDecimal(1);
BigDecimal bd2 = BigDecimal(9);
try {
return bd1.divide(bd2);
} catch(ArithmaticException ae) {
return new BigDecimal(bd1.doubleValue() / bd2.doubleValue());
}
Also, since there isn't a BigDecimal equivalent for SQL databases, so storing BigDecimal values either requires conversion to a different format, which can affect accuracy and/or precision, or the value must be stored as a BLOB, which is cumbersome and inefficient. In general use, calculations with BigDecimal are significantly slower than with integers, and also take up more storage space. <ref>http://lemnik.wordpress.com/2011/03/25/bigdecimal-and-your-money/</ref>

===Class===
In ''Object-Oriented Design Using Java'', recommends using a class to represent money, rather than just using a long integer alone. He gives two reasons for using a class. The first is encapsulation - by encapsulating money into a class, all the operations specific to working with money can be implemented to work as desired in all cases, which also avoids code duplication. The second reason is that the compiler is better able to detect coding errors, such as adding money to something that isn't money. <ref name="lec20" /> Implementing Money as a class is a generally good idea, but there are multiple ways to go about it.

====Abstract Class====
If multiple kinds of currencies are needed to be represented, one implementation is to create an abstract Money class and have each possible currency be a subclass of the abstract class. Since there are over 180 different currencies worldwide, it can be a challenge to implement subclasses for each one required.

The following is the abstract class proposed by Skrien in Object-Oriented Design Using Java:
public abstract class Money implements Comparable<Money> {
public long getAmount()
public String toString()
public int compareTo(Money m)
public boolean equals(Object o)
public int hashCode()
public Money plus(Money)
public Money minus(Money)
public Money times(double factor)
public Money dividedBy(double divisor)
public Money negate()
}
<ref name="lec20" />

====Single Class====
Rather than implementing a variety of subclasses for each currency, a single class can be used to represent money, with currency specified within. This is a good idea, since currencies basically operate the same calculation-wise, but have variations in decimal locations and the symbols used to present them. Java has a [http://docs.oracle.com/javase/6/docs/api/java/util/Currency.html Currency class] which holds the information for a given currency.

The following is the Single Class implementation given by Skrien in ''Object-Oriented Design Using Java'':

public class Money implements Comparable<Money> {
private long amount;
private Currency currency;
public Money(long amount, Currency currency) {
this.amount = amount;
this.currency = currency;
}
public long getAmount() { return amount; }
public Currency getCurrency() {
return currency; }
public String toString() { ...above... }
public int compareTo(Money o) { ... }
public boolean equals(Object o) { ... }
public int hashCode() { ... }
public Money plus(Money) { ... }
public Money minus(Money) { ... }
public Money times(double factor) { ... }
public Money dividedBy(double divisor) { ... }
public Money negate() { ... }
}
<ref name="lec20" />

====Mixed Money====

====Using an Interface====

==Resources==
*Need to go through these for information
**[http://courses.ncsu.edu/csc517//common/lectures/notes/lec20.pdf PDF from class lecture]
**[http://docs.oracle.com/javase/1.4.2/docs/api/java/util/Currency.html Java's Currency class docs]
**[http://drdobbs.com/java/184405653 A standalone class to tackle the problem (in Java)]
**[http://www.javapractices.com/topic/TopicAction.do?Id=13 Representing money (Java)]
**[http://www.javaranch.com/journal/2003/07/MoneyInJava.html Working with money in Java]
**[http://timeandmoney.sourceforge.net/ Time and Money Java project - doesn't seem to have much documentation, though]
**[http://joda-money.sourceforge.net/ Joda Money class library for Java]
**[http://lemnik.wordpress.com/2011/03/25/bigdecimal-and-your-money/ BigDecimal and Your Money (a criticism of using BigDecimal format)]
**[http://www.opentaps.org/docs/index.php/How_to_Use_Java_BigDecimal:_A_Tutorial Tutorial on using BigDecimal]
**[http://junit.sourceforge.net/doc/testinfected/testing.htm JUnit Test Infected: Programmers Love Writing Tests (has a Money class example]
**[http://www.xencraft.com/resources/multi-currency.html Currency Internationalization (i18n), Multiple Currencies and Foreign Exchange (FX)] -nothing programming-wise, but a good overview of the considerations for currency
**[http://www.di-mare.com/adolfo/p/money.htm Yet Another C++ Money Class ]
**[http://edenti.deis.unibo.it/utils/Java-tips/Currency%20representation.txt Representing currencies (txt document with example and details)]

==References==
<references />

CSC/ECE 517 Fall 2011/ch7 7a or

2011-12-01T03:23:42Z

Opevans:

Wiki Chapter: CSC/ECE 517 Fall 2011/ch7 7a or

''7a. Representing money. Skrien Chapter 6 gives an example of a class that can be used to represent money. But how is it done in real programs? Investigate, and report on the advantages and disadvantages of other approaches vs. Skrien's.''
__TOC__
==Introduction==
Money is very important to people worldwide and is something that often must be represented in computer programs. This raises the question of how money should be represented, which can vary from program to program. There is much to be considered such as string formatting, the way money is used, and the variety of different currencies in the world. In Chapter 6 of Skrien's ''Object-Oriented Design Using Java'', he suggests an implementation that represents money as a class, but there are other approaches that can be taken, each with their respective advantages and disadvantages.

==Properties of Money==
Money has certain properties and uses that must be considered in implementation.

===Responsibilities/Using Money===
The following are ways in which a representation of money should be able to be used: <ref name="lec20">http://courses.ncsu.edu/csc517/common/lectures/notes/lec20.pdf</ref>
*To represent a positive or negative amount of money.
*Possibly representing multiple components of a currency - i.e. dollars and cents.
*Possibly representing amounts of multiple currencies - i.e. a mix of US Dollars, euros, and yen.'
*To have a string formatting potentially including currency symbols like the dollar sign ($) and/or commas and/or decimal points.
*Addition, subtraction, multiplication, and division.
The degree to which of the above must be met will depend on the depth of the implementing project.

===Different Currencies===
Some applications may only handle only one currency such as the US Dollar, but more generally applied applications, such as banking, must be able to handle different kinds of currencies.

There are currently over 180 currencies in use around the world.<ref>http://en.wikipedia.org/wiki/List_of_circulating_currencies</ref>

Implementation must be aware of how to specifically represent each currency used. Some currencies use decimal points, such as how the US has 100 cents to a dollar, while others have no decimal, such as yen. Each currency also has a different sign symbol used such as $, €, or ¥. Different currencies also have different rules about how rounding values is handled.

Special consideration must be taken when using different currencies in conjunction with each other. Foreign exchange rates can be used to convert between different currencies, but the exchange rate often change, so attention must be paid to that. In some cases, it is also important to keep track of how much money the user has of more than one currency at a time, so that must be handled somehow. <ref>http://www.xencraft.com/resources/multi-currency.html</ref><ref name="lec20" />

===Immutable vs. Mutable===
Money values can be either mutable, meaning changeable, or immutable, meaning unchanging. Mutable money values are useful in that a new value does not need to be created for every change. However, mutable values cause problems for use in hash maps or with concurrency. The issue with concurrency is a read and write issue in a system with multiple users. With changing values, money not be what the user expects and lead to unpredictable behavior. Skrien feels this is a significant enough disadvantage to prefer an immutable representation for money.<ref name="lec20" />

==Possible Representations==
There are several possible ways to represent money in code.

===Floating Point Number===
Floating point numbers seem like an appealing option since they already include a fractional component, which lends itself straightforward to currencies like the US dollar which also have a fractional component. However, floating point numbers come with a drawback due to the way floats are formatted. Since floats are based on binary representation rather than a decimal representation, a value that would be exact in decimal notation can only be stored approximately in a floats point number. For instance, 9.48 is stored as 9.479999542236328125. Performing calculations with these approximated values can lead to inaccurate results. <ref name="dobbs">http://drdobbs.com/java/184405653</ref>

Another deficiency of floating point numbers is that they lose precision as the number gets larger. This is less of a problem when dealing with small amounts of currency, but when dealing with large amounts, on the order of the United States federal debt, the number of significant figures to the right of the decimal point decreases, again leading to possibly inaccurate results.<ref>Skrien, Dale. ''Object-Oriented Design Using Java''. McGraw Hill, 2009, p. 174.</ref>

===Two Integers===
For currencies with a fractional component, using two integers to represent one amount of money is an option. One integer to represent the main component and one to represent the fractional part. For US currency, this would mean an integer for dollars and an integer for cents. This representation makes displaying monetary values simple, as each component is already split out and accurate. Also, by using integers, calculations with money work out as they should, avoiding the loss of accuracy floating points have. However, code will need to be implemented to handle when the fraction component carries over. In the case of dollars and cents, if the cents exceed 100, the cents value should be decreased by 100 and the dollars increased by 1. This handling of carries adds overhead to calculations. The main drawbacks of this implementation is the added overhead and storage required. <ref name="lec20" />

===One Integer, Implied Decimal Point===
One integer can be used to represent money, even including the fractional component. The location of the decimal place is simply implied based on the currency. For instance, a single integer representation of $12.34 would be 1234. When dealing with US currency, this exploits the fact that the fundamental unit of currency in the US is actually the cent, not the dollar <ref name="dobbs"/>. A specialized print method would have to be constructed to display the monetary amount properly to the user, but all calculations work out properly. This approach has the same advantage that using two integers of maintaining accuracy, but does not have the added overhead or storage. In ''Object-Oriented Design Using Java'', Skrien considers this to be the best use of the primitive types for representing money.<ref name="lec20" />

===BigDecimal===
Java offers a [http://docs.oracle.com/javase/6/docs/api/java/math/BigDecimal.html BigDecimal] class, which many people use for representing money. BigDecimal is capable of storing any size number since it stores each digit as an entry in an array, which grows as necessary. It also allows for specification of both the rounding method and the scale, the number of digits past the decimal place, for proper monetary calculations. [http://www.javaranch.com/journal/2003/07/MoneyInJava.html] On the downside, this specification for rounding and scale is required, which adds code to the implementation. [http://drdobbs.com/java/184405653] BigDecimal values are also immutable, which avoids read/write and write/write conflicts in applications. [http://www.opentaps.org/docs/index.php/How_to_Use_Java_BigDecimal:_A_Tutorial] While there are a lot of nice things about BigDecimal, there are some more issues with BigDecimal which can cause problems in representing money. BigDecimal cannot represent numbers with infinite digits such as 1/9 (.11111...) and throws an ArithmeticException on any calculation that would produce such number. To deal with this, hacks such as the following must be implemented:
BigDecimal bd1 = BigDecimal(1);
BigDecimal bd2 = BigDecimal(9);
try {
return bd1.divide(bd2);
} catch(ArithmaticException ae) {
return new BigDecimal(bd1.doubleValue() / bd2.doubleValue());
}
Also, since there isn't a BigDecimal equivalent for SQL databases, so storing BigDecimal values either requires conversion to a different format, which can affect accuracy and/or precision, or the value must be stored as a BLOB, which is cumbersome and inefficient. In general use, calculations with BigDecimal are significantly slower than with integers, and also take up more storage space. [http://lemnik.wordpress.com/2011/03/25/bigdecimal-and-your-money/]

===Class===
In ''Object-Oriented Design Using Java'', recommends using a class to represent money, rather than just using a long integer alone. He gives two reasons for using a class. The first is encapsulation - by encapsulating money into a class, all the operations specific to working with money can be implemented to work as desired in all cases, which also avoids code duplication. The second reason is that the compiler is better able to detect coding errors, such as adding money to something that isn't money. <ref name="lec20" /> Implementing Money as a class is a generally good idea, but there are multiple ways to go about it.

====Abstract Class====
If multiple kinds of currencies are needed to be represented, one implementation is to create an abstract Money class and have each possible currency be a subclass of the abstract class. Since there are over 180 different currencies worldwide, it can be a challenge to implement subclasses for each one required.

The following is the abstract class proposed by Skrien in Object-Oriented Design Using Java:
public abstract class Money implements Comparable<Money> {
public long getAmount()
public String toString()
public int compareTo(Money m)
public boolean equals(Object o)
public int hashCode()
public Money plus(Money)
public Money minus(Money)
public Money times(double factor)
public Money dividedBy(double divisor)
public Money negate()
}
<ref name="lec20" />

====Single Class====
Rather than implementing a variety of subclasses for each currency, a single class can be used to represent money, with currency specified within. This is a good idea, since currencies basically operate the same calculation-wise, but have variations in decimal locations and the symbols used to present them. Java has a [http://docs.oracle.com/javase/6/docs/api/java/util/Currency.html Currency class] which holds the information for a given currency.

The following is the Single Class implementation given by Skrien in ''Object-Oriented Design Using Java'':

public class Money implements Comparable<Money> {
private long amount;
private Currency currency;
public Money(long amount, Currency currency) {
this.amount = amount;
this.currency = currency;
}
public long getAmount() { return amount; }
public Currency getCurrency() {
return currency; }
public String toString() { ...above... }
public int compareTo(Money o) { ... }
public boolean equals(Object o) { ... }
public int hashCode() { ... }
public Money plus(Money) { ... }
public Money minus(Money) { ... }
public Money times(double factor) { ... }
public Money dividedBy(double divisor) { ... }
public Money negate() { ... }
}
<ref name="lec20" />

====Mixed Money====

====Using an Interface====

==Resources==
*Need to go through these for information
**[http://courses.ncsu.edu/csc517//common/lectures/notes/lec20.pdf PDF from class lecture]
**[http://docs.oracle.com/javase/1.4.2/docs/api/java/util/Currency.html Java's Currency class docs]
**[http://drdobbs.com/java/184405653 A standalone class to tackle the problem (in Java)]
**[http://www.javapractices.com/topic/TopicAction.do?Id=13 Representing money (Java)]
**[http://www.javaranch.com/journal/2003/07/MoneyInJava.html Working with money in Java]
**[http://timeandmoney.sourceforge.net/ Time and Money Java project - doesn't seem to have much documentation, though]
**[http://joda-money.sourceforge.net/ Joda Money class library for Java]
**[http://lemnik.wordpress.com/2011/03/25/bigdecimal-and-your-money/ BigDecimal and Your Money (a criticism of using BigDecimal format)]
**[http://www.opentaps.org/docs/index.php/How_to_Use_Java_BigDecimal:_A_Tutorial Tutorial on using BigDecimal]
**[http://junit.sourceforge.net/doc/testinfected/testing.htm JUnit Test Infected: Programmers Love Writing Tests (has a Money class example]
**[http://www.xencraft.com/resources/multi-currency.html Currency Internationalization (i18n), Multiple Currencies and Foreign Exchange (FX)] -nothing programming-wise, but a good overview of the considerations for currency
**[http://www.di-mare.com/adolfo/p/money.htm Yet Another C++ Money Class ]
**[http://edenti.deis.unibo.it/utils/Java-tips/Currency%20representation.txt Representing currencies (txt document with example and details)]

==References==
<references />

CSC/ECE 517 Fall 2011/ch7 7a or

2011-12-01T03:12:14Z

Opevans: /* Different Currencies */

Wiki Chapter: CSC/ECE 517 Fall 2011/ch7 7a or

''7a. Representing money. Skrien Chapter 6 gives an example of a class that can be used to represent money. But how is it done in real programs? Investigate, and report on the advantages and disadvantages of other approaches vs. Skrien's.''
__TOC__
==Introduction==
Money is very important to people worldwide and is something that often must be represented in computer programs. This raises the question of how money should be represented, which can vary from program to program. There is much to be considered such as string formatting, the way money is used, and the variety of different currencies in the world. In Chapter 6 of Skrien's ''Object-Oriented Design Using Java'', he suggests an implementation that represents money as a class, but there are other approaches that can be taken, each with their respective advantages and disadvantages.

==Properties of Money==
Money has certain properties and uses that must be considered in implementation.

===Responsibilities/Using Money===
The following are ways in which a representation of money should be able to be used: [http://courses.ncsu.edu/csc517//common/lectures/notes/lec20.pdf]
*To represent a positive or negative amount of money.
*Possibly representing multiple components of a currency - i.e. dollars and cents.
*Possibly representing amounts of multiple currencies - i.e. a mix of US Dollars, euros, and yen.'
*To have a string formatting potentially including currency symbols like the dollar sign ($) and/or commas and/or decimal points.
*Addition, subtraction, multiplication, and division.
The degree to which of the above must be met will depend on the depth of the implementing project.

===Different Currencies===
Some applications may only handle only one currency such as the US Dollar, but more generally applied applications, such as banking, must be able to handle different kinds of currencies.

There are currently over 180 currencies in use around the world.[http://en.wikipedia.org/wiki/List_of_circulating_currencies]

Implementation must be aware of how to specifically represent each currency used. Some currencies use decimal points, such as how the US has 100 cents to a dollar, while others have no decimal, such as yen. Each currency also has a different sign symbol used such as $, €, or ¥. Different currencies also have different rules about how rounding values is handled.

Special consideration must be taken when using different currencies in conjunction with each other. Foreign exchange rates can be used to convert between different currencies, but the exchange rate often change, so attention must be paid to that. In some cases, it is also important to keep track of how much money the user has of more than one currency at a time, so that must be handled somehow. <ref>http://www.xencraft.com/resources/multi-currency.html</ref><ref>http://courses.ncsu.edu/csc517//common/lectures/notes/lec20.pdf</ref>

===Immutable vs. Mutable===
Money values can be either mutable, meaning changeable, or immutable, meaning unchanging. Mutable money values are useful in that a new value does not need to be created for every change. However, mutable values cause problems for use in hash maps or with concurrency. The issue with concurrency is a read and write issue in a system with multiple users. With changing values, money not be what the user expects and lead to unpredictable behavior. Skrien feels this is a significant enough disadvantage to prefer an immutable representation for money.[http://courses.ncsu.edu/csc517//common/lectures/notes/lec20.pdf]

==Possible Representations==
There are several possible ways to represent money in code.

===Floating Point Number===
Floating point numbers seem like an appealing option since they already include a fractional component, which lends itself straightforward to currencies like the US dollar which also have a fractional component. However, floating point numbers come with a drawback due to the way floats are formatted. Since floats are based on binary representation rather than a decimal representation, a value that would be exact in decimal notation can only be stored approximately in a floats point number. For instance, 9.48 is stored as 9.479999542236328125. Performing calculations with these approximated values can lead to inaccurate results. [http://drdobbs.com/java/184405653]

Another deficiency of floating point numbers is that they lose precision as the number gets larger. This is less of a problem when dealing with small amounts of currency, but when dealing with large amounts, on the order of the United States federal debt, the number of significant figures to the right of the decimal point decreases, again leading to possibly inaccurate results.<ref>Skrien, Dale. ''Object-Oriented Design Using Java''. McGraw Hill, 2009, p. 174.</ref>

===Two Integers===
For currencies with a fractional component, using two integers to represent one amount of money is an option. One integer to represent the main component and one to represent the fractional part. For US currency, this would mean an integer for dollars and an integer for cents. This representation makes displaying monetary values simple, as each component is already split out and accurate. Also, by using integers, calculations with money work out as they should, avoiding the loss of accuracy floating points have. However, code will need to be implemented to handle when the fraction component carries over. In the case of dollars and cents, if the cents exceed 100, the cents value should be decreased by 100 and the dollars increased by 1. This handling of carries adds overhead to calculations. The main drawbacks of this implementation is the added overhead and storage required. [http://courses.ncsu.edu/csc517//common/lectures/notes/lec20.pdf]

===One Integer, Implied Decimal Point===
One integer can be used to represent money, even including the fractional component. The location of the decimal place is simply implied based on the currency. For instance, a single integer representation of $12.34 would be 1234. When dealing with US currency, this exploits the fact that the fundamental unit of currency in the US is actually the cent, not the dollar <ref>http://drdobbs.com/java/184405653</ref>. A specialized print method would have to be constructed to display the monetary amount properly to the user, but all calculations work out properly. This approach has the same advantage that using two integers of maintaining accuracy, but does not have the added overhead or storage. In ''Object-Oriented Design Using Java'', Skrien considers this to be the best use of the primitive types for representing money.<ref>http://courses.ncsu.edu/csc517/common/lectures/notes/lec20.pdf</ref>

===BigDecimal===
Java offers a [http://docs.oracle.com/javase/6/docs/api/java/math/BigDecimal.html BigDecimal] class, which many people use for representing money. BigDecimal is capable of storing any size number since it stores each digit as an entry in an array, which grows as necessary. It also allows for specification of both the rounding method and the scale, the number of digits past the decimal place, for proper monetary calculations. [http://www.javaranch.com/journal/2003/07/MoneyInJava.html] On the downside, this specification for rounding and scale is required, which adds code to the implementation. [http://drdobbs.com/java/184405653] BigDecimal values are also immutable, which avoids read/write and write/write conflicts in applications. [http://www.opentaps.org/docs/index.php/How_to_Use_Java_BigDecimal:_A_Tutorial] While there are a lot of nice things about BigDecimal, there are some more issues with BigDecimal which can cause problems in representing money. BigDecimal cannot represent numbers with infinite digits such as 1/9 (.11111...) and throws an ArithmeticException on any calculation that would produce such number. To deal with this, hacks such as the following must be implemented:
BigDecimal bd1 = BigDecimal(1);
BigDecimal bd2 = BigDecimal(9);
try {
return bd1.divide(bd2);
} catch(ArithmaticException ae) {
return new BigDecimal(bd1.doubleValue() / bd2.doubleValue());
}
Also, since there isn't a BigDecimal equivalent for SQL databases, so storing BigDecimal values either requires conversion to a different format, which can affect accuracy and/or precision, or the value must be stored as a BLOB, which is cumbersome and inefficient. In general use, calculations with BigDecimal are significantly slower than with integers, and also take up more storage space. [http://lemnik.wordpress.com/2011/03/25/bigdecimal-and-your-money/]

===Class===
In ''Object-Oriented Design Using Java'', recommends using a class to represent money, rather than just using a long integer alone. He gives two reasons for using a class. The first is encapsulation - by encapsulating money into a class, all the operations specific to working with money can be implemented to work as desired in all cases, which also avoids code duplication. The second reason is that the compiler is better able to detect coding errors, such as adding money to something that isn't money. [http://courses.ncsu.edu/csc517//common/lectures/notes/lec20.pdf] Implementing Money as a class is a generally good idea, but there are multiple ways to go about it.

====Abstract Class====
If multiple kinds of currencies are needed to be represented, one implementation is to create an abstract Money class and have each possible currency be a subclass of the abstract class. Since there are over 180 different currencies worldwide, it can be a challenge to implement subclasses for each one required.

The following is the abstract class proposed by Skrien in Object-Oriented Design Using Java:
public abstract class Money implements Comparable<Money> {
public long getAmount()
public String toString()
public int compareTo(Money m)
public boolean equals(Object o)
public int hashCode()
public Money plus(Money)
public Money minus(Money)
public Money times(double factor)
public Money dividedBy(double divisor)
public Money negate()
}
[http://courses.ncsu.edu/csc517//common/lectures/notes/lec20.pdf]

====Single Class====
Rather than implementing a variety of subclasses for each currency, a single class can be used to represent money, with currency specified within. This is a good idea, since currencies basically operate the same calculation-wise, but have variations in decimal locations and the symbols used to present them. Java has a [http://docs.oracle.com/javase/6/docs/api/java/util/Currency.html Currency class] which holds the information for a given currency.

The following is the Single Class implementation given by Skrien in ''Object-Oriented Design Using Java'':

public class Money implements Comparable<Money> {
private long amount;
private Currency currency;
public Money(long amount, Currency currency) {
this.amount = amount;
this.currency = currency;
}
public long getAmount() { return amount; }
public Currency getCurrency() {
return currency; }
public String toString() { ...above... }
public int compareTo(Money o) { ... }
public boolean equals(Object o) { ... }
public int hashCode() { ... }
public Money plus(Money) { ... }
public Money minus(Money) { ... }
public Money times(double factor) { ... }
public Money dividedBy(double divisor) { ... }
public Money negate() { ... }
}
[http://courses.ncsu.edu/csc517//common/lectures/notes/lec20.pdf]

====Mixed Money====

====Using an Interface====

==Resources==
*Need to go through these for information
**[http://courses.ncsu.edu/csc517//common/lectures/notes/lec20.pdf PDF from class lecture]
**[http://docs.oracle.com/javase/1.4.2/docs/api/java/util/Currency.html Java's Currency class docs]
**[http://drdobbs.com/java/184405653 A standalone class to tackle the problem (in Java)]
**[http://www.javapractices.com/topic/TopicAction.do?Id=13 Representing money (Java)]
**[http://www.javaranch.com/journal/2003/07/MoneyInJava.html Working with money in Java]
**[http://timeandmoney.sourceforge.net/ Time and Money Java project - doesn't seem to have much documentation, though]
**[http://joda-money.sourceforge.net/ Joda Money class library for Java]
**[http://lemnik.wordpress.com/2011/03/25/bigdecimal-and-your-money/ BigDecimal and Your Money (a criticism of using BigDecimal format)]
**[http://www.opentaps.org/docs/index.php/How_to_Use_Java_BigDecimal:_A_Tutorial Tutorial on using BigDecimal]
**[http://junit.sourceforge.net/doc/testinfected/testing.htm JUnit Test Infected: Programmers Love Writing Tests (has a Money class example]
**[http://www.xencraft.com/resources/multi-currency.html Currency Internationalization (i18n), Multiple Currencies and Foreign Exchange (FX)] -nothing programming-wise, but a good overview of the considerations for currency
**[http://www.di-mare.com/adolfo/p/money.htm Yet Another C++ Money Class ]
**[http://edenti.deis.unibo.it/utils/Java-tips/Currency%20representation.txt Representing currencies (txt document with example and details)]

==References==
<references />

CSC/ECE 517 Fall 2011/ch7 7a or

2011-12-01T03:11:14Z

Opevans: /* One Integer, Implied Decimal Point */

Wiki Chapter: CSC/ECE 517 Fall 2011/ch7 7a or

''7a. Representing money. Skrien Chapter 6 gives an example of a class that can be used to represent money. But how is it done in real programs? Investigate, and report on the advantages and disadvantages of other approaches vs. Skrien's.''
__TOC__
==Introduction==
Money is very important to people worldwide and is something that often must be represented in computer programs. This raises the question of how money should be represented, which can vary from program to program. There is much to be considered such as string formatting, the way money is used, and the variety of different currencies in the world. In Chapter 6 of Skrien's ''Object-Oriented Design Using Java'', he suggests an implementation that represents money as a class, but there are other approaches that can be taken, each with their respective advantages and disadvantages.

==Properties of Money==
Money has certain properties and uses that must be considered in implementation.

===Responsibilities/Using Money===
The following are ways in which a representation of money should be able to be used: [http://courses.ncsu.edu/csc517//common/lectures/notes/lec20.pdf]
*To represent a positive or negative amount of money.
*Possibly representing multiple components of a currency - i.e. dollars and cents.
*Possibly representing amounts of multiple currencies - i.e. a mix of US Dollars, euros, and yen.'
*To have a string formatting potentially including currency symbols like the dollar sign ($) and/or commas and/or decimal points.
*Addition, subtraction, multiplication, and division.
The degree to which of the above must be met will depend on the depth of the implementing project.

===Different Currencies===
Some applications may only handle only one currency such as the US Dollar, but more generally applied applications, such as banking, must be able to handle different kinds of currencies.

There are currently over 180 currencies in use around the world.[http://en.wikipedia.org/wiki/List_of_circulating_currencies]

Implementation must be aware of how to specifically represent each currency used. Some currencies use decimal points, such as how the US has 100 cents to a dollar, while others have no decimal, such as yen. Each currency also has a different sign symbol used such as $, €, or ¥. Different currencies also have different rules about how rounding values is handled.

Special consideration must be taken when using different currencies in conjunction with each other. Foreign exchange rates can be used to convert between different currencies, but the exchange rate often change, so attention must be paid to that. In some cases, it is also important to keep track of how much money the user has of more than one currency at a time, so that must be handled somehow. [http://www.xencraft.com/resources/multi-currency.html][http://courses.ncsu.edu/csc517//common/lectures/notes/lec20.pdf]

===Immutable vs. Mutable===
Money values can be either mutable, meaning changeable, or immutable, meaning unchanging. Mutable money values are useful in that a new value does not need to be created for every change. However, mutable values cause problems for use in hash maps or with concurrency. The issue with concurrency is a read and write issue in a system with multiple users. With changing values, money not be what the user expects and lead to unpredictable behavior. Skrien feels this is a significant enough disadvantage to prefer an immutable representation for money.[http://courses.ncsu.edu/csc517//common/lectures/notes/lec20.pdf]

==Possible Representations==
There are several possible ways to represent money in code.

===Floating Point Number===
Floating point numbers seem like an appealing option since they already include a fractional component, which lends itself straightforward to currencies like the US dollar which also have a fractional component. However, floating point numbers come with a drawback due to the way floats are formatted. Since floats are based on binary representation rather than a decimal representation, a value that would be exact in decimal notation can only be stored approximately in a floats point number. For instance, 9.48 is stored as 9.479999542236328125. Performing calculations with these approximated values can lead to inaccurate results. [http://drdobbs.com/java/184405653]

Another deficiency of floating point numbers is that they lose precision as the number gets larger. This is less of a problem when dealing with small amounts of currency, but when dealing with large amounts, on the order of the United States federal debt, the number of significant figures to the right of the decimal point decreases, again leading to possibly inaccurate results.<ref>Skrien, Dale. ''Object-Oriented Design Using Java''. McGraw Hill, 2009, p. 174.</ref>

===Two Integers===
For currencies with a fractional component, using two integers to represent one amount of money is an option. One integer to represent the main component and one to represent the fractional part. For US currency, this would mean an integer for dollars and an integer for cents. This representation makes displaying monetary values simple, as each component is already split out and accurate. Also, by using integers, calculations with money work out as they should, avoiding the loss of accuracy floating points have. However, code will need to be implemented to handle when the fraction component carries over. In the case of dollars and cents, if the cents exceed 100, the cents value should be decreased by 100 and the dollars increased by 1. This handling of carries adds overhead to calculations. The main drawbacks of this implementation is the added overhead and storage required. [http://courses.ncsu.edu/csc517//common/lectures/notes/lec20.pdf]

===One Integer, Implied Decimal Point===
One integer can be used to represent money, even including the fractional component. The location of the decimal place is simply implied based on the currency. For instance, a single integer representation of $12.34 would be 1234. When dealing with US currency, this exploits the fact that the fundamental unit of currency in the US is actually the cent, not the dollar <ref>http://drdobbs.com/java/184405653</ref>. A specialized print method would have to be constructed to display the monetary amount properly to the user, but all calculations work out properly. This approach has the same advantage that using two integers of maintaining accuracy, but does not have the added overhead or storage. In ''Object-Oriented Design Using Java'', Skrien considers this to be the best use of the primitive types for representing money.<ref>http://courses.ncsu.edu/csc517/common/lectures/notes/lec20.pdf</ref>

===BigDecimal===
Java offers a [http://docs.oracle.com/javase/6/docs/api/java/math/BigDecimal.html BigDecimal] class, which many people use for representing money. BigDecimal is capable of storing any size number since it stores each digit as an entry in an array, which grows as necessary. It also allows for specification of both the rounding method and the scale, the number of digits past the decimal place, for proper monetary calculations. [http://www.javaranch.com/journal/2003/07/MoneyInJava.html] On the downside, this specification for rounding and scale is required, which adds code to the implementation. [http://drdobbs.com/java/184405653] BigDecimal values are also immutable, which avoids read/write and write/write conflicts in applications. [http://www.opentaps.org/docs/index.php/How_to_Use_Java_BigDecimal:_A_Tutorial] While there are a lot of nice things about BigDecimal, there are some more issues with BigDecimal which can cause problems in representing money. BigDecimal cannot represent numbers with infinite digits such as 1/9 (.11111...) and throws an ArithmeticException on any calculation that would produce such number. To deal with this, hacks such as the following must be implemented:
BigDecimal bd1 = BigDecimal(1);
BigDecimal bd2 = BigDecimal(9);
try {
return bd1.divide(bd2);
} catch(ArithmaticException ae) {
return new BigDecimal(bd1.doubleValue() / bd2.doubleValue());
}
Also, since there isn't a BigDecimal equivalent for SQL databases, so storing BigDecimal values either requires conversion to a different format, which can affect accuracy and/or precision, or the value must be stored as a BLOB, which is cumbersome and inefficient. In general use, calculations with BigDecimal are significantly slower than with integers, and also take up more storage space. [http://lemnik.wordpress.com/2011/03/25/bigdecimal-and-your-money/]

===Class===
In ''Object-Oriented Design Using Java'', recommends using a class to represent money, rather than just using a long integer alone. He gives two reasons for using a class. The first is encapsulation - by encapsulating money into a class, all the operations specific to working with money can be implemented to work as desired in all cases, which also avoids code duplication. The second reason is that the compiler is better able to detect coding errors, such as adding money to something that isn't money. [http://courses.ncsu.edu/csc517//common/lectures/notes/lec20.pdf] Implementing Money as a class is a generally good idea, but there are multiple ways to go about it.

====Abstract Class====
If multiple kinds of currencies are needed to be represented, one implementation is to create an abstract Money class and have each possible currency be a subclass of the abstract class. Since there are over 180 different currencies worldwide, it can be a challenge to implement subclasses for each one required.

The following is the abstract class proposed by Skrien in Object-Oriented Design Using Java:
public abstract class Money implements Comparable<Money> {
public long getAmount()
public String toString()
public int compareTo(Money m)
public boolean equals(Object o)
public int hashCode()
public Money plus(Money)
public Money minus(Money)
public Money times(double factor)
public Money dividedBy(double divisor)
public Money negate()
}
[http://courses.ncsu.edu/csc517//common/lectures/notes/lec20.pdf]

====Single Class====
Rather than implementing a variety of subclasses for each currency, a single class can be used to represent money, with currency specified within. This is a good idea, since currencies basically operate the same calculation-wise, but have variations in decimal locations and the symbols used to present them. Java has a [http://docs.oracle.com/javase/6/docs/api/java/util/Currency.html Currency class] which holds the information for a given currency.

The following is the Single Class implementation given by Skrien in ''Object-Oriented Design Using Java'':

public class Money implements Comparable<Money> {
private long amount;
private Currency currency;
public Money(long amount, Currency currency) {
this.amount = amount;
this.currency = currency;
}
public long getAmount() { return amount; }
public Currency getCurrency() {
return currency; }
public String toString() { ...above... }
public int compareTo(Money o) { ... }
public boolean equals(Object o) { ... }
public int hashCode() { ... }
public Money plus(Money) { ... }
public Money minus(Money) { ... }
public Money times(double factor) { ... }
public Money dividedBy(double divisor) { ... }
public Money negate() { ... }
}
[http://courses.ncsu.edu/csc517//common/lectures/notes/lec20.pdf]

====Mixed Money====

====Using an Interface====

==Resources==
*Need to go through these for information
**[http://courses.ncsu.edu/csc517//common/lectures/notes/lec20.pdf PDF from class lecture]
**[http://docs.oracle.com/javase/1.4.2/docs/api/java/util/Currency.html Java's Currency class docs]
**[http://drdobbs.com/java/184405653 A standalone class to tackle the problem (in Java)]
**[http://www.javapractices.com/topic/TopicAction.do?Id=13 Representing money (Java)]
**[http://www.javaranch.com/journal/2003/07/MoneyInJava.html Working with money in Java]
**[http://timeandmoney.sourceforge.net/ Time and Money Java project - doesn't seem to have much documentation, though]
**[http://joda-money.sourceforge.net/ Joda Money class library for Java]
**[http://lemnik.wordpress.com/2011/03/25/bigdecimal-and-your-money/ BigDecimal and Your Money (a criticism of using BigDecimal format)]
**[http://www.opentaps.org/docs/index.php/How_to_Use_Java_BigDecimal:_A_Tutorial Tutorial on using BigDecimal]
**[http://junit.sourceforge.net/doc/testinfected/testing.htm JUnit Test Infected: Programmers Love Writing Tests (has a Money class example]
**[http://www.xencraft.com/resources/multi-currency.html Currency Internationalization (i18n), Multiple Currencies and Foreign Exchange (FX)] -nothing programming-wise, but a good overview of the considerations for currency
**[http://www.di-mare.com/adolfo/p/money.htm Yet Another C++ Money Class ]
**[http://edenti.deis.unibo.it/utils/Java-tips/Currency%20representation.txt Representing currencies (txt document with example and details)]

==References==
<references />

CSC/ECE 517 Fall 2011/ch7 7a or

2011-12-01T03:07:00Z

Opevans: /* Floating Point Number */

Wiki Chapter: CSC/ECE 517 Fall 2011/ch7 7a or

''7a. Representing money. Skrien Chapter 6 gives an example of a class that can be used to represent money. But how is it done in real programs? Investigate, and report on the advantages and disadvantages of other approaches vs. Skrien's.''
__TOC__
==Introduction==
Money is very important to people worldwide and is something that often must be represented in computer programs. This raises the question of how money should be represented, which can vary from program to program. There is much to be considered such as string formatting, the way money is used, and the variety of different currencies in the world. In Chapter 6 of Skrien's ''Object-Oriented Design Using Java'', he suggests an implementation that represents money as a class, but there are other approaches that can be taken, each with their respective advantages and disadvantages.

==Properties of Money==
Money has certain properties and uses that must be considered in implementation.

===Responsibilities/Using Money===
The following are ways in which a representation of money should be able to be used: [http://courses.ncsu.edu/csc517//common/lectures/notes/lec20.pdf]
*To represent a positive or negative amount of money.
*Possibly representing multiple components of a currency - i.e. dollars and cents.
*Possibly representing amounts of multiple currencies - i.e. a mix of US Dollars, euros, and yen.'
*To have a string formatting potentially including currency symbols like the dollar sign ($) and/or commas and/or decimal points.
*Addition, subtraction, multiplication, and division.
The degree to which of the above must be met will depend on the depth of the implementing project.

===Different Currencies===
Some applications may only handle only one currency such as the US Dollar, but more generally applied applications, such as banking, must be able to handle different kinds of currencies.

There are currently over 180 currencies in use around the world.[http://en.wikipedia.org/wiki/List_of_circulating_currencies]

Implementation must be aware of how to specifically represent each currency used. Some currencies use decimal points, such as how the US has 100 cents to a dollar, while others have no decimal, such as yen. Each currency also has a different sign symbol used such as $, €, or ¥. Different currencies also have different rules about how rounding values is handled.

Special consideration must be taken when using different currencies in conjunction with each other. Foreign exchange rates can be used to convert between different currencies, but the exchange rate often change, so attention must be paid to that. In some cases, it is also important to keep track of how much money the user has of more than one currency at a time, so that must be handled somehow. [http://www.xencraft.com/resources/multi-currency.html][http://courses.ncsu.edu/csc517//common/lectures/notes/lec20.pdf]

===Immutable vs. Mutable===
Money values can be either mutable, meaning changeable, or immutable, meaning unchanging. Mutable money values are useful in that a new value does not need to be created for every change. However, mutable values cause problems for use in hash maps or with concurrency. The issue with concurrency is a read and write issue in a system with multiple users. With changing values, money not be what the user expects and lead to unpredictable behavior. Skrien feels this is a significant enough disadvantage to prefer an immutable representation for money.[http://courses.ncsu.edu/csc517//common/lectures/notes/lec20.pdf]

==Possible Representations==
There are several possible ways to represent money in code.

===Floating Point Number===
Floating point numbers seem like an appealing option since they already include a fractional component, which lends itself straightforward to currencies like the US dollar which also have a fractional component. However, floating point numbers come with a drawback due to the way floats are formatted. Since floats are based on binary representation rather than a decimal representation, a value that would be exact in decimal notation can only be stored approximately in a floats point number. For instance, 9.48 is stored as 9.479999542236328125. Performing calculations with these approximated values can lead to inaccurate results. [http://drdobbs.com/java/184405653]

Another deficiency of floating point numbers is that they lose precision as the number gets larger. This is less of a problem when dealing with small amounts of currency, but when dealing with large amounts, on the order of the United States federal debt, the number of significant figures to the right of the decimal point decreases, again leading to possibly inaccurate results.<ref>Skrien, Dale. ''Object-Oriented Design Using Java''. McGraw Hill, 2009, p. 174.</ref>

===Two Integers===
For currencies with a fractional component, using two integers to represent one amount of money is an option. One integer to represent the main component and one to represent the fractional part. For US currency, this would mean an integer for dollars and an integer for cents. This representation makes displaying monetary values simple, as each component is already split out and accurate. Also, by using integers, calculations with money work out as they should, avoiding the loss of accuracy floating points have. However, code will need to be implemented to handle when the fraction component carries over. In the case of dollars and cents, if the cents exceed 100, the cents value should be decreased by 100 and the dollars increased by 1. This handling of carries adds overhead to calculations. The main drawbacks of this implementation is the added overhead and storage required. [http://courses.ncsu.edu/csc517//common/lectures/notes/lec20.pdf]

===One Integer, Implied Decimal Point===
One integer can be used to represent money, even including the fractional component. The location of the decimal place is simply implied based on the currency. For instance, a single integer representation of $12.34 would be 1234. A specialized print method would have to be constructed to display the monetary amount properly to the user, but all calculations work out properly. This approach has the same advantage that using two integers of maintaining accuracy, but does not have the added overhead or storage. In ''Object-Oriented Design Using Java'', Skrien considers this to be the best use of the primitive types for representing money. [http://courses.ncsu.edu/csc517//common/lectures/notes/lec20.pdf]

===BigDecimal===
Java offers a [http://docs.oracle.com/javase/6/docs/api/java/math/BigDecimal.html BigDecimal] class, which many people use for representing money. BigDecimal is capable of storing any size number since it stores each digit as an entry in an array, which grows as necessary. It also allows for specification of both the rounding method and the scale, the number of digits past the decimal place, for proper monetary calculations. [http://www.javaranch.com/journal/2003/07/MoneyInJava.html] On the downside, this specification for rounding and scale is required, which adds code to the implementation. [http://drdobbs.com/java/184405653] BigDecimal values are also immutable, which avoids read/write and write/write conflicts in applications. [http://www.opentaps.org/docs/index.php/How_to_Use_Java_BigDecimal:_A_Tutorial] While there are a lot of nice things about BigDecimal, there are some more issues with BigDecimal which can cause problems in representing money. BigDecimal cannot represent numbers with infinite digits such as 1/9 (.11111...) and throws an ArithmeticException on any calculation that would produce such number. To deal with this, hacks such as the following must be implemented:
BigDecimal bd1 = BigDecimal(1);
BigDecimal bd2 = BigDecimal(9);
try {
return bd1.divide(bd2);
} catch(ArithmaticException ae) {
return new BigDecimal(bd1.doubleValue() / bd2.doubleValue());
}
Also, since there isn't a BigDecimal equivalent for SQL databases, so storing BigDecimal values either requires conversion to a different format, which can affect accuracy and/or precision, or the value must be stored as a BLOB, which is cumbersome and inefficient. In general use, calculations with BigDecimal are significantly slower than with integers, and also take up more storage space. [http://lemnik.wordpress.com/2011/03/25/bigdecimal-and-your-money/]

===Class===
In ''Object-Oriented Design Using Java'', recommends using a class to represent money, rather than just using a long integer alone. He gives two reasons for using a class. The first is encapsulation - by encapsulating money into a class, all the operations specific to working with money can be implemented to work as desired in all cases, which also avoids code duplication. The second reason is that the compiler is better able to detect coding errors, such as adding money to something that isn't money. [http://courses.ncsu.edu/csc517//common/lectures/notes/lec20.pdf] Implementing Money as a class is a generally good idea, but there are multiple ways to go about it.

====Abstract Class====
If multiple kinds of currencies are needed to be represented, one implementation is to create an abstract Money class and have each possible currency be a subclass of the abstract class. Since there are over 180 different currencies worldwide, it can be a challenge to implement subclasses for each one required.

The following is the abstract class proposed by Skrien in Object-Oriented Design Using Java:
public abstract class Money implements Comparable<Money> {
public long getAmount()
public String toString()
public int compareTo(Money m)
public boolean equals(Object o)
public int hashCode()
public Money plus(Money)
public Money minus(Money)
public Money times(double factor)
public Money dividedBy(double divisor)
public Money negate()
}
[http://courses.ncsu.edu/csc517//common/lectures/notes/lec20.pdf]

====Single Class====
Rather than implementing a variety of subclasses for each currency, a single class can be used to represent money, with currency specified within. This is a good idea, since currencies basically operate the same calculation-wise, but have variations in decimal locations and the symbols used to present them. Java has a [http://docs.oracle.com/javase/6/docs/api/java/util/Currency.html Currency class] which holds the information for a given currency.

The following is the Single Class implementation given by Skrien in ''Object-Oriented Design Using Java'':

public class Money implements Comparable<Money> {
private long amount;
private Currency currency;
public Money(long amount, Currency currency) {
this.amount = amount;
this.currency = currency;
}
public long getAmount() { return amount; }
public Currency getCurrency() {
return currency; }
public String toString() { ...above... }
public int compareTo(Money o) { ... }
public boolean equals(Object o) { ... }
public int hashCode() { ... }
public Money plus(Money) { ... }
public Money minus(Money) { ... }
public Money times(double factor) { ... }
public Money dividedBy(double divisor) { ... }
public Money negate() { ... }
}
[http://courses.ncsu.edu/csc517//common/lectures/notes/lec20.pdf]

====Mixed Money====

====Using an Interface====

==Resources==
*Need to go through these for information
**[http://courses.ncsu.edu/csc517//common/lectures/notes/lec20.pdf PDF from class lecture]
**[http://docs.oracle.com/javase/1.4.2/docs/api/java/util/Currency.html Java's Currency class docs]
**[http://drdobbs.com/java/184405653 A standalone class to tackle the problem (in Java)]
**[http://www.javapractices.com/topic/TopicAction.do?Id=13 Representing money (Java)]
**[http://www.javaranch.com/journal/2003/07/MoneyInJava.html Working with money in Java]
**[http://timeandmoney.sourceforge.net/ Time and Money Java project - doesn't seem to have much documentation, though]
**[http://joda-money.sourceforge.net/ Joda Money class library for Java]
**[http://lemnik.wordpress.com/2011/03/25/bigdecimal-and-your-money/ BigDecimal and Your Money (a criticism of using BigDecimal format)]
**[http://www.opentaps.org/docs/index.php/How_to_Use_Java_BigDecimal:_A_Tutorial Tutorial on using BigDecimal]
**[http://junit.sourceforge.net/doc/testinfected/testing.htm JUnit Test Infected: Programmers Love Writing Tests (has a Money class example]
**[http://www.xencraft.com/resources/multi-currency.html Currency Internationalization (i18n), Multiple Currencies and Foreign Exchange (FX)] -nothing programming-wise, but a good overview of the considerations for currency
**[http://www.di-mare.com/adolfo/p/money.htm Yet Another C++ Money Class ]
**[http://edenti.deis.unibo.it/utils/Java-tips/Currency%20representation.txt Representing currencies (txt document with example and details)]

==References==
<references />

CSC/ECE 517 Fall 2011/ch7 7a or

2011-12-01T03:04:17Z

Opevans:

Wiki Chapter: CSC/ECE 517 Fall 2011/ch7 7a or

''7a. Representing money. Skrien Chapter 6 gives an example of a class that can be used to represent money. But how is it done in real programs? Investigate, and report on the advantages and disadvantages of other approaches vs. Skrien's.''
__TOC__
==Introduction==
Money is very important to people worldwide and is something that often must be represented in computer programs. This raises the question of how money should be represented, which can vary from program to program. There is much to be considered such as string formatting, the way money is used, and the variety of different currencies in the world. In Chapter 6 of Skrien's ''Object-Oriented Design Using Java'', he suggests an implementation that represents money as a class, but there are other approaches that can be taken, each with their respective advantages and disadvantages.

==Properties of Money==
Money has certain properties and uses that must be considered in implementation.

===Responsibilities/Using Money===
The following are ways in which a representation of money should be able to be used: [http://courses.ncsu.edu/csc517//common/lectures/notes/lec20.pdf]
*To represent a positive or negative amount of money.
*Possibly representing multiple components of a currency - i.e. dollars and cents.
*Possibly representing amounts of multiple currencies - i.e. a mix of US Dollars, euros, and yen.'
*To have a string formatting potentially including currency symbols like the dollar sign ($) and/or commas and/or decimal points.
*Addition, subtraction, multiplication, and division.
The degree to which of the above must be met will depend on the depth of the implementing project.

===Different Currencies===
Some applications may only handle only one currency such as the US Dollar, but more generally applied applications, such as banking, must be able to handle different kinds of currencies.

There are currently over 180 currencies in use around the world.[http://en.wikipedia.org/wiki/List_of_circulating_currencies]

Implementation must be aware of how to specifically represent each currency used. Some currencies use decimal points, such as how the US has 100 cents to a dollar, while others have no decimal, such as yen. Each currency also has a different sign symbol used such as $, €, or ¥. Different currencies also have different rules about how rounding values is handled.

Special consideration must be taken when using different currencies in conjunction with each other. Foreign exchange rates can be used to convert between different currencies, but the exchange rate often change, so attention must be paid to that. In some cases, it is also important to keep track of how much money the user has of more than one currency at a time, so that must be handled somehow. [http://www.xencraft.com/resources/multi-currency.html][http://courses.ncsu.edu/csc517//common/lectures/notes/lec20.pdf]

===Immutable vs. Mutable===
Money values can be either mutable, meaning changeable, or immutable, meaning unchanging. Mutable money values are useful in that a new value does not need to be created for every change. However, mutable values cause problems for use in hash maps or with concurrency. The issue with concurrency is a read and write issue in a system with multiple users. With changing values, money not be what the user expects and lead to unpredictable behavior. Skrien feels this is a significant enough disadvantage to prefer an immutable representation for money.[http://courses.ncsu.edu/csc517//common/lectures/notes/lec20.pdf]

==Possible Representations==
There are several possible ways to represent money in code.

===Floating Point Number===
Floating point numbers seem like an appealing option since they already include a fractional component, which lends itself straightforward to currencies like the US dollar which also have a fractional component. However, floating point numbers come with a drawback due to the way floats are formatted. Since floats are based on binary representation rather than a decimal representation, a value that would be exact in decimal notation can only be stored approximately in a floats point number. For instance, 9.48 is stored as 9.479999542236328125. Performing calculations with these approximated values can lead to inaccurate results. [http://drdobbs.com/java/184405653]

Another deficiency of floating point numbers is that they lose precision as the number gets larger. This is less of a problem when dealing with small amounts of currency, but when dealing with large amounts, on the order of the United States federal debt, the number of significant figures to the right of the decimal point decreases, again leading to possibly inaccurate results, especially with larger numbers. <ref>Skrien, Dale. ''Object-Oriented Design Using Java''. McGraw Hill, 2009, p. 174.</ref>

===Two Integers===
For currencies with a fractional component, using two integers to represent one amount of money is an option. One integer to represent the main component and one to represent the fractional part. For US currency, this would mean an integer for dollars and an integer for cents. This representation makes displaying monetary values simple, as each component is already split out and accurate. Also, by using integers, calculations with money work out as they should, avoiding the loss of accuracy floating points have. However, code will need to be implemented to handle when the fraction component carries over. In the case of dollars and cents, if the cents exceed 100, the cents value should be decreased by 100 and the dollars increased by 1. This handling of carries adds overhead to calculations. The main drawbacks of this implementation is the added overhead and storage required. [http://courses.ncsu.edu/csc517//common/lectures/notes/lec20.pdf]

===One Integer, Implied Decimal Point===
One integer can be used to represent money, even including the fractional component. The location of the decimal place is simply implied based on the currency. For instance, a single integer representation of $12.34 would be 1234. A specialized print method would have to be constructed to display the monetary amount properly to the user, but all calculations work out properly. This approach has the same advantage that using two integers of maintaining accuracy, but does not have the added overhead or storage. In ''Object-Oriented Design Using Java'', Skrien considers this to be the best use of the primitive types for representing money. [http://courses.ncsu.edu/csc517//common/lectures/notes/lec20.pdf]

===BigDecimal===
Java offers a [http://docs.oracle.com/javase/6/docs/api/java/math/BigDecimal.html BigDecimal] class, which many people use for representing money. BigDecimal is capable of storing any size number since it stores each digit as an entry in an array, which grows as necessary. It also allows for specification of both the rounding method and the scale, the number of digits past the decimal place, for proper monetary calculations. [http://www.javaranch.com/journal/2003/07/MoneyInJava.html] On the downside, this specification for rounding and scale is required, which adds code to the implementation. [http://drdobbs.com/java/184405653] BigDecimal values are also immutable, which avoids read/write and write/write conflicts in applications. [http://www.opentaps.org/docs/index.php/How_to_Use_Java_BigDecimal:_A_Tutorial] While there are a lot of nice things about BigDecimal, there are some more issues with BigDecimal which can cause problems in representing money. BigDecimal cannot represent numbers with infinite digits such as 1/9 (.11111...) and throws an ArithmeticException on any calculation that would produce such number. To deal with this, hacks such as the following must be implemented:
BigDecimal bd1 = BigDecimal(1);
BigDecimal bd2 = BigDecimal(9);
try {
return bd1.divide(bd2);
} catch(ArithmaticException ae) {
return new BigDecimal(bd1.doubleValue() / bd2.doubleValue());
}
Also, since there isn't a BigDecimal equivalent for SQL databases, so storing BigDecimal values either requires conversion to a different format, which can affect accuracy and/or precision, or the value must be stored as a BLOB, which is cumbersome and inefficient. In general use, calculations with BigDecimal are significantly slower than with integers, and also take up more storage space. [http://lemnik.wordpress.com/2011/03/25/bigdecimal-and-your-money/]

===Class===
In ''Object-Oriented Design Using Java'', recommends using a class to represent money, rather than just using a long integer alone. He gives two reasons for using a class. The first is encapsulation - by encapsulating money into a class, all the operations specific to working with money can be implemented to work as desired in all cases, which also avoids code duplication. The second reason is that the compiler is better able to detect coding errors, such as adding money to something that isn't money. [http://courses.ncsu.edu/csc517//common/lectures/notes/lec20.pdf] Implementing Money as a class is a generally good idea, but there are multiple ways to go about it.

====Abstract Class====
If multiple kinds of currencies are needed to be represented, one implementation is to create an abstract Money class and have each possible currency be a subclass of the abstract class. Since there are over 180 different currencies worldwide, it can be a challenge to implement subclasses for each one required.

The following is the abstract class proposed by Skrien in Object-Oriented Design Using Java:
public abstract class Money implements Comparable<Money> {
public long getAmount()
public String toString()
public int compareTo(Money m)
public boolean equals(Object o)
public int hashCode()
public Money plus(Money)
public Money minus(Money)
public Money times(double factor)
public Money dividedBy(double divisor)
public Money negate()
}
[http://courses.ncsu.edu/csc517//common/lectures/notes/lec20.pdf]

====Single Class====
Rather than implementing a variety of subclasses for each currency, a single class can be used to represent money, with currency specified within. This is a good idea, since currencies basically operate the same calculation-wise, but have variations in decimal locations and the symbols used to present them. Java has a [http://docs.oracle.com/javase/6/docs/api/java/util/Currency.html Currency class] which holds the information for a given currency.

The following is the Single Class implementation given by Skrien in ''Object-Oriented Design Using Java'':

public class Money implements Comparable<Money> {
private long amount;
private Currency currency;
public Money(long amount, Currency currency) {
this.amount = amount;
this.currency = currency;
}
public long getAmount() { return amount; }
public Currency getCurrency() {
return currency; }
public String toString() { ...above... }
public int compareTo(Money o) { ... }
public boolean equals(Object o) { ... }
public int hashCode() { ... }
public Money plus(Money) { ... }
public Money minus(Money) { ... }
public Money times(double factor) { ... }
public Money dividedBy(double divisor) { ... }
public Money negate() { ... }
}
[http://courses.ncsu.edu/csc517//common/lectures/notes/lec20.pdf]

====Mixed Money====

====Using an Interface====

==Resources==
*Need to go through these for information
**[http://courses.ncsu.edu/csc517//common/lectures/notes/lec20.pdf PDF from class lecture]
**[http://docs.oracle.com/javase/1.4.2/docs/api/java/util/Currency.html Java's Currency class docs]
**[http://drdobbs.com/java/184405653 A standalone class to tackle the problem (in Java)]
**[http://www.javapractices.com/topic/TopicAction.do?Id=13 Representing money (Java)]
**[http://www.javaranch.com/journal/2003/07/MoneyInJava.html Working with money in Java]
**[http://timeandmoney.sourceforge.net/ Time and Money Java project - doesn't seem to have much documentation, though]
**[http://joda-money.sourceforge.net/ Joda Money class library for Java]
**[http://lemnik.wordpress.com/2011/03/25/bigdecimal-and-your-money/ BigDecimal and Your Money (a criticism of using BigDecimal format)]
**[http://www.opentaps.org/docs/index.php/How_to_Use_Java_BigDecimal:_A_Tutorial Tutorial on using BigDecimal]
**[http://junit.sourceforge.net/doc/testinfected/testing.htm JUnit Test Infected: Programmers Love Writing Tests (has a Money class example]
**[http://www.xencraft.com/resources/multi-currency.html Currency Internationalization (i18n), Multiple Currencies and Foreign Exchange (FX)] -nothing programming-wise, but a good overview of the considerations for currency
**[http://www.di-mare.com/adolfo/p/money.htm Yet Another C++ Money Class ]
**[http://edenti.deis.unibo.it/utils/Java-tips/Currency%20representation.txt Representing currencies (txt document with example and details)]

==References==
<references />

CSC/ECE 517 Fall 2011/ch7 7a or

2011-12-01T03:00:08Z

Opevans: /* Floating Point Number */

Wiki Chapter: CSC/ECE 517 Fall 2011/ch7 7a or

''7a. Representing money. Skrien Chapter 6 gives an example of a class that can be used to represent money. But how is it done in real programs? Investigate, and report on the advantages and disadvantages of other approaches vs. Skrien's.''
__TOC__
==Introduction==
Money is very important to people worldwide and is something that often must be represented in computer programs. This raises the question of how money should be represented, which can vary from program to program. There is much to be considered such as string formatting, the way money is used, and the variety of different currencies in the world. In Chapter 6 of Skrien's ''Object-Oriented Design Using Java'', he suggests an implementation that represents money as a class, but there are other approaches that can be taken, each with their respective advantages and disadvantages.

==Properties of Money==
Money has certain properties and uses that must be considered in implementation.

===Responsibilities/Using Money===
The following are ways in which a representation of money should be able to be used: [http://courses.ncsu.edu/csc517//common/lectures/notes/lec20.pdf]
*To represent a positive or negative amount of money.
*Possibly representing multiple components of a currency - i.e. dollars and cents.
*Possibly representing amounts of multiple currencies - i.e. a mix of US Dollars, euros, and yen.'
*To have a string formatting potentially including currency symbols like the dollar sign ($) and/or commas and/or decimal points.
*Addition, subtraction, multiplication, and division.
The degree to which of the above must be met will depend on the depth of the implementing project.

===Different Currencies===
Some applications may only handle only one currency such as the US Dollar, but more generally applied applications, such as banking, must be able to handle different kinds of currencies.

There are currently over 180 currencies in use around the world.[http://en.wikipedia.org/wiki/List_of_circulating_currencies]

Implementation must be aware of how to specifically represent each currency used. Some currencies use decimal points, such as how the US has 100 cents to a dollar, while others have no decimal, such as yen. Each currency also has a different sign symbol used such as $, €, or ¥. Different currencies also have different rules about how rounding values is handled.

Special consideration must be taken when using different currencies in conjunction with each other. Foreign exchange rates can be used to convert between different currencies, but the exchange rate often change, so attention must be paid to that. In some cases, it is also important to keep track of how much money the user has of more than one currency at a time, so that must be handled somehow. [http://www.xencraft.com/resources/multi-currency.html][http://courses.ncsu.edu/csc517//common/lectures/notes/lec20.pdf]

===Immutable vs. Mutable===
Money values can be either mutable, meaning changeable, or immutable, meaning unchanging. Mutable money values are useful in that a new value does not need to be created for every change. However, mutable values cause problems for use in hash maps or with concurrency. The issue with concurrency is a read and write issue in a system with multiple users. With changing values, money not be what the user expects and lead to unpredictable behavior. Skrien feels this is a significant enough disadvantage to prefer an immutable representation for money.[http://courses.ncsu.edu/csc517//common/lectures/notes/lec20.pdf]

==Possible Representations==
There are several possible ways to represent money in code.

===Floating Point Number===
Floating point numbers seem like an appealing option since they already include a fractional component, which lends itself straightforward to currencies like the US dollar which also have a fractional component. However, floating point numbers come with a drawback due to the way floats are formatted. Since floats are based on binary representation rather than a decimal representation, a value that would be exact in decimal notation can only be stored approximately in a floats point number. For instance, 9.48 is stored as 9.479999542236328125. Performing calculations with these approximated values can lead to inaccurate results. [http://drdobbs.com/java/184405653]

Another deficiency of floating point numbers is that they lose precision as the number gets larger. This is less of a problem when dealing with small amounts of currency, but when dealing with large amounts, on the order of the United States federal debt, the number of significant figures to the right of the decimal point decreases, again leading to possibly inaccurate results, especially with larger numbers. <ref>Skrien, Dale. ''Object-Oriented Design Using Java''. McGraw Hill, 2009, p. 174.</ref>

===Two Integers===
For currencies with a fractional component, using two integers to represent one amount of money is an option. One integer to represent the main component and one to represent the fractional part. For US currency, this would mean an integer for dollars and an integer for cents. This representation makes displaying monetary values simple, as each component is already split out and accurate. Also, by using integers, calculations with money work out as they should, avoiding the loss of accuracy floating points have. However, code will need to be implemented to handle when the fraction component carries over. In the case of dollars and cents, if the cents exceed 100, the cents value should be decreased by 100 and the dollars increased by 1. This handling of carries adds overhead to calculations. The main drawbacks of this implementation is the added overhead and storage required. [http://courses.ncsu.edu/csc517//common/lectures/notes/lec20.pdf]

===One Integer, Implied Decimal Point===
One integer can be used to represent money, even including the fractional component. The location of the decimal place is simply implied based on the currency. For instance, a single integer representation of $12.34 would be 1234. A specialized print method would have to be constructed to display the monetary amount properly to the user, but all calculations work out properly. This approach has the same advantage that using two integers of maintaining accuracy, but does not have the added overhead or storage. In ''Object-Oriented Design Using Java'', Skrien considers this to be the best use of the primitive types for representing money. [http://courses.ncsu.edu/csc517//common/lectures/notes/lec20.pdf]

===BigDecimal===
Java offers a [http://docs.oracle.com/javase/6/docs/api/java/math/BigDecimal.html BigDecimal] class, which many people use for representing money. BigDecimal is capable of storing any size number since it stores each digit as an entry in an array, which grows as necessary. It also allows for specification of both the rounding method and the scale, the number of digits past the decimal place, for proper monetary calculations. [http://www.javaranch.com/journal/2003/07/MoneyInJava.html] On the downside, this specification for rounding and scale is required, which adds code to the implementation. [http://drdobbs.com/java/184405653] BigDecimal values are also immutable, which avoids read/write and write/write conflicts in applications. [http://www.opentaps.org/docs/index.php/How_to_Use_Java_BigDecimal:_A_Tutorial] While there are a lot of nice things about BigDecimal, there are some more issues with BigDecimal which can cause problems in representing money. BigDecimal cannot represent numbers with infinite digits such as 1/9 (.11111...) and throws an ArithmeticException on any calculation that would produce such number. To deal with this, hacks such as the following must be implemented:
BigDecimal bd1 = BigDecimal(1);
BigDecimal bd2 = BigDecimal(9);
try {
return bd1.divide(bd2);
} catch(ArithmaticException ae) {
return new BigDecimal(bd1.doubleValue() / bd2.doubleValue());
}
Also, since there isn't a BigDecimal equivalent for SQL databases, so storing BigDecimal values either requires conversion to a different format, which can affect accuracy and/or precision, or the value must be stored as a BLOB, which is cumbersome and inefficient. In general use, calculations with BigDecimal are significantly slower than with integers, and also take up more storage space. [http://lemnik.wordpress.com/2011/03/25/bigdecimal-and-your-money/]

===Class===
In ''Object-Oriented Design Using Java'', recommends using a class to represent money, rather than just using a long integer alone. He gives two reasons for using a class. The first is encapsulation - by encapsulating money into a class, all the operations specific to working with money can be implemented to work as desired in all cases, which also avoids code duplication. The second reason is that the compiler is better able to detect coding errors, such as adding money to something that isn't money. [http://courses.ncsu.edu/csc517//common/lectures/notes/lec20.pdf] Implementing Money as a class is a generally good idea, but there are multiple ways to go about it.

====Abstract Class====
If multiple kinds of currencies are needed to be represented, one implementation is to create an abstract Money class and have each possible currency be a subclass of the abstract class. Since there are over 180 different currencies worldwide, it can be a challenge to implement subclasses for each one required.

The following is the abstract class proposed by Skrien in Object-Oriented Design Using Java:
public abstract class Money implements Comparable<Money> {
public long getAmount()
public String toString()
public int compareTo(Money m)
public boolean equals(Object o)
public int hashCode()
public Money plus(Money)
public Money minus(Money)
public Money times(double factor)
public Money dividedBy(double divisor)
public Money negate()
}
[http://courses.ncsu.edu/csc517//common/lectures/notes/lec20.pdf]

====Single Class====
Rather than implementing a variety of subclasses for each currency, a single class can be used to represent money, with currency specified within. This is a good idea, since currencies basically operate the same calculation-wise, but have variations in decimal locations and the symbols used to present them. Java has a [http://docs.oracle.com/javase/6/docs/api/java/util/Currency.html Currency class] which holds the information for a given currency.

The following is the Single Class implementation given by Skrien in ''Object-Oriented Design Using Java'':

public class Money implements Comparable<Money> {
private long amount;
private Currency currency;
public Money(long amount, Currency currency) {
this.amount = amount;
this.currency = currency;
}
public long getAmount() { return amount; }
public Currency getCurrency() {
return currency; }
public String toString() { ...above... }
public int compareTo(Money o) { ... }
public boolean equals(Object o) { ... }
public int hashCode() { ... }
public Money plus(Money) { ... }
public Money minus(Money) { ... }
public Money times(double factor) { ... }
public Money dividedBy(double divisor) { ... }
public Money negate() { ... }
}
[http://courses.ncsu.edu/csc517//common/lectures/notes/lec20.pdf]

====Mixed Money====

====Using an Interface====

==Resources==
*Need to go through these for information
**[http://courses.ncsu.edu/csc517//common/lectures/notes/lec20.pdf PDF from class lecture]
**[http://docs.oracle.com/javase/1.4.2/docs/api/java/util/Currency.html Java's Currency class docs]
**[http://drdobbs.com/java/184405653 A standalone class to tackle the problem (in Java)]
**[http://www.javapractices.com/topic/TopicAction.do?Id=13 Representing money (Java)]
**[http://www.javaranch.com/journal/2003/07/MoneyInJava.html Working with money in Java]
**[http://timeandmoney.sourceforge.net/ Time and Money Java project - doesn't seem to have much documentation, though]
**[http://joda-money.sourceforge.net/ Joda Money class library for Java]
**[http://lemnik.wordpress.com/2011/03/25/bigdecimal-and-your-money/ BigDecimal and Your Money (a criticism of using BigDecimal format)]
**[http://www.opentaps.org/docs/index.php/How_to_Use_Java_BigDecimal:_A_Tutorial Tutorial on using BigDecimal]
**[http://junit.sourceforge.net/doc/testinfected/testing.htm JUnit Test Infected: Programmers Love Writing Tests (has a Money class example]
**[http://www.xencraft.com/resources/multi-currency.html Currency Internationalization (i18n), Multiple Currencies and Foreign Exchange (FX)] -nothing programming-wise, but a good overview of the considerations for currency
**[http://www.di-mare.com/adolfo/p/money.htm Yet Another C++ Money Class ]
**[http://edenti.deis.unibo.it/utils/Java-tips/Currency%20representation.txt Representing currencies (txt document with example and details)]

CSC/ECE 517 Fall 2011/ch7 7a or

2011-12-01T02:52:09Z

Opevans: /* Floating Point Number */

Wiki Chapter: CSC/ECE 517 Fall 2011/ch7 7a or

''7a. Representing money. Skrien Chapter 6 gives an example of a class that can be used to represent money. But how is it done in real programs? Investigate, and report on the advantages and disadvantages of other approaches vs. Skrien's.''
__TOC__
==Introduction==
Money is very important to people worldwide and is something that often must be represented in computer programs. This raises the question of how money should be represented, which can vary from program to program. There is much to be considered such as string formatting, the way money is used, and the variety of different currencies in the world. In Chapter 6 of Skrien's ''Object-Oriented Design Using Java'', he suggests an implementation that represents money as a class, but there are other approaches that can be taken, each with their respective advantages and disadvantages.

==Properties of Money==
Money has certain properties and uses that must be considered in implementation.

===Responsibilities/Using Money===
The following are ways in which a representation of money should be able to be used: [http://courses.ncsu.edu/csc517//common/lectures/notes/lec20.pdf]
*To represent a positive or negative amount of money.
*Possibly representing multiple components of a currency - i.e. dollars and cents.
*Possibly representing amounts of multiple currencies - i.e. a mix of US Dollars, euros, and yen.'
*To have a string formatting potentially including currency symbols like the dollar sign ($) and/or commas and/or decimal points.
*Addition, subtraction, multiplication, and division.
The degree to which of the above must be met will depend on the depth of the implementing project.

===Different Currencies===
Some applications may only handle only one currency such as the US Dollar, but more generally applied applications, such as banking, must be able to handle different kinds of currencies.

There are currently over 180 currencies in use around the world.[http://en.wikipedia.org/wiki/List_of_circulating_currencies]

Implementation must be aware of how to specifically represent each currency used. Some currencies use decimal points, such as how the US has 100 cents to a dollar, while others have no decimal, such as yen. Each currency also has a different sign symbol used such as $, €, or ¥. Different currencies also have different rules about how rounding values is handled.

Special consideration must be taken when using different currencies in conjunction with each other. Foreign exchange rates can be used to convert between different currencies, but the exchange rate often change, so attention must be paid to that. In some cases, it is also important to keep track of how much money the user has of more than one currency at a time, so that must be handled somehow. [http://www.xencraft.com/resources/multi-currency.html][http://courses.ncsu.edu/csc517//common/lectures/notes/lec20.pdf]

===Immutable vs. Mutable===
Money values can be either mutable, meaning changeable, or immutable, meaning unchanging. Mutable money values are useful in that a new value does not need to be created for every change. However, mutable values cause problems for use in hash maps or with concurrency. The issue with concurrency is a read and write issue in a system with multiple users. With changing values, money not be what the user expects and lead to unpredictable behavior. Skrien feels this is a significant enough disadvantage to prefer an immutable representation for money.[http://courses.ncsu.edu/csc517//common/lectures/notes/lec20.pdf]

==Possible Representations==
There are several possible ways to represent money in code.

===Floating Point Number===
Floating point numbers seem like an appealing option since they already include a fractional component, which lends itself straightforward to currencies like the US dollar which also have a fractional component. However, floating point numbers come with a drawback due to the way floats are formatted. Since floats are based on binary representation rather than a decimal representation, a value that would be exact in decimal notation can only be stored approximately in a floats point number. For instance, 9.48 is stored as 9.479999542236328125. Performing calculations with these approximated values can lead to inaccurate results. [http://drdobbs.com/java/184405653]

Another deficiency of floating point numbers is that they lose precision as the number gets larger. This is less of a problem when dealing with small amounts of currency, but when dealing with large amounts, on the order of the United States federal debt, the number of significant figures to the right of the decimal point decreases, again leading to possibly inaccurate results, especially with larger numbers.

===Two Integers===
For currencies with a fractional component, using two integers to represent one amount of money is an option. One integer to represent the main component and one to represent the fractional part. For US currency, this would mean an integer for dollars and an integer for cents. This representation makes displaying monetary values simple, as each component is already split out and accurate. Also, by using integers, calculations with money work out as they should, avoiding the loss of accuracy floating points have. However, code will need to be implemented to handle when the fraction component carries over. In the case of dollars and cents, if the cents exceed 100, the cents value should be decreased by 100 and the dollars increased by 1. This handling of carries adds overhead to calculations. The main drawbacks of this implementation is the added overhead and storage required. [http://courses.ncsu.edu/csc517//common/lectures/notes/lec20.pdf]

===One Integer, Implied Decimal Point===
One integer can be used to represent money, even including the fractional component. The location of the decimal place is simply implied based on the currency. For instance, a single integer representation of $12.34 would be 1234. A specialized print method would have to be constructed to display the monetary amount properly to the user, but all calculations work out properly. This approach has the same advantage that using two integers of maintaining accuracy, but does not have the added overhead or storage. In ''Object-Oriented Design Using Java'', Skrien considers this to be the best use of the primitive types for representing money. [http://courses.ncsu.edu/csc517//common/lectures/notes/lec20.pdf]

===BigDecimal===
Java offers a [http://docs.oracle.com/javase/6/docs/api/java/math/BigDecimal.html BigDecimal] class, which many people use for representing money. BigDecimal is capable of storing any size number since it stores each digit as an entry in an array, which grows as necessary. It also allows for specification of both the rounding method and the scale, the number of digits past the decimal place, for proper monetary calculations. [http://www.javaranch.com/journal/2003/07/MoneyInJava.html] On the downside, this specification for rounding and scale is required, which adds code to the implementation. [http://drdobbs.com/java/184405653] BigDecimal values are also immutable, which avoids read/write and write/write conflicts in applications. [http://www.opentaps.org/docs/index.php/How_to_Use_Java_BigDecimal:_A_Tutorial] While there are a lot of nice things about BigDecimal, there are some more issues with BigDecimal which can cause problems in representing money. BigDecimal cannot represent numbers with infinite digits such as 1/9 (.11111...) and throws an ArithmeticException on any calculation that would produce such number. To deal with this, hacks such as the following must be implemented:
BigDecimal bd1 = BigDecimal(1);
BigDecimal bd2 = BigDecimal(9);
try {
return bd1.divide(bd2);
} catch(ArithmaticException ae) {
return new BigDecimal(bd1.doubleValue() / bd2.doubleValue());
}
Also, since there isn't a BigDecimal equivalent for SQL databases, so storing BigDecimal values either requires conversion to a different format, which can affect accuracy and/or precision, or the value must be stored as a BLOB, which is cumbersome and inefficient. In general use, calculations with BigDecimal are significantly slower than with integers, and also take up more storage space. [http://lemnik.wordpress.com/2011/03/25/bigdecimal-and-your-money/]

===Class===
In ''Object-Oriented Design Using Java'', recommends using a class to represent money, rather than just using a long integer alone. He gives two reasons for using a class. The first is encapsulation - by encapsulating money into a class, all the operations specific to working with money can be implemented to work as desired in all cases, which also avoids code duplication. The second reason is that the compiler is better able to detect coding errors, such as adding money to something that isn't money. [http://courses.ncsu.edu/csc517//common/lectures/notes/lec20.pdf] Implementing Money as a class is a generally good idea, but there are multiple ways to go about it.

====Abstract Class====
If multiple kinds of currencies are needed to be represented, one implementation is to create an abstract Money class and have each possible currency be a subclass of the abstract class. Since there are over 180 different currencies worldwide, it can be a challenge to implement subclasses for each one required.

The following is the abstract class proposed by Skrien in Object-Oriented Design Using Java:
public abstract class Money implements Comparable<Money> {
public long getAmount()
public String toString()
public int compareTo(Money m)
public boolean equals(Object o)
public int hashCode()
public Money plus(Money)
public Money minus(Money)
public Money times(double factor)
public Money dividedBy(double divisor)
public Money negate()
}
[http://courses.ncsu.edu/csc517//common/lectures/notes/lec20.pdf]

====Single Class====
Rather than implementing a variety of subclasses for each currency, a single class can be used to represent money, with currency specified within. This is a good idea, since currencies basically operate the same calculation-wise, but have variations in decimal locations and the symbols used to present them. Java has a [http://docs.oracle.com/javase/6/docs/api/java/util/Currency.html Currency class] which holds the information for a given currency.

The following is the Single Class implementation given by Skrien in ''Object-Oriented Design Using Java'':

public class Money implements Comparable<Money> {
private long amount;
private Currency currency;
public Money(long amount, Currency currency) {
this.amount = amount;
this.currency = currency;
}
public long getAmount() { return amount; }
public Currency getCurrency() {
return currency; }
public String toString() { ...above... }
public int compareTo(Money o) { ... }
public boolean equals(Object o) { ... }
public int hashCode() { ... }
public Money plus(Money) { ... }
public Money minus(Money) { ... }
public Money times(double factor) { ... }
public Money dividedBy(double divisor) { ... }
public Money negate() { ... }
}
[http://courses.ncsu.edu/csc517//common/lectures/notes/lec20.pdf]

====Mixed Money====

====Using an Interface====

==Resources==
*Need to go through these for information
**[http://courses.ncsu.edu/csc517//common/lectures/notes/lec20.pdf PDF from class lecture]
**[http://docs.oracle.com/javase/1.4.2/docs/api/java/util/Currency.html Java's Currency class docs]
**[http://drdobbs.com/java/184405653 A standalone class to tackle the problem (in Java)]
**[http://www.javapractices.com/topic/TopicAction.do?Id=13 Representing money (Java)]
**[http://www.javaranch.com/journal/2003/07/MoneyInJava.html Working with money in Java]
**[http://timeandmoney.sourceforge.net/ Time and Money Java project - doesn't seem to have much documentation, though]
**[http://joda-money.sourceforge.net/ Joda Money class library for Java]
**[http://lemnik.wordpress.com/2011/03/25/bigdecimal-and-your-money/ BigDecimal and Your Money (a criticism of using BigDecimal format)]
**[http://www.opentaps.org/docs/index.php/How_to_Use_Java_BigDecimal:_A_Tutorial Tutorial on using BigDecimal]
**[http://junit.sourceforge.net/doc/testinfected/testing.htm JUnit Test Infected: Programmers Love Writing Tests (has a Money class example]
**[http://www.xencraft.com/resources/multi-currency.html Currency Internationalization (i18n), Multiple Currencies and Foreign Exchange (FX)] -nothing programming-wise, but a good overview of the considerations for currency
**[http://www.di-mare.com/adolfo/p/money.htm Yet Another C++ Money Class ]
**[http://edenti.deis.unibo.it/utils/Java-tips/Currency%20representation.txt Representing currencies (txt document with example and details)]

CSC/ECE 517 Fall 2011/ch7 7a or

2011-12-01T02:51:21Z

Opevans: /* Floating Point Number */

Wiki Chapter: CSC/ECE 517 Fall 2011/ch7 7a or

''7a. Representing money. Skrien Chapter 6 gives an example of a class that can be used to represent money. But how is it done in real programs? Investigate, and report on the advantages and disadvantages of other approaches vs. Skrien's.''
__TOC__
==Introduction==
Money is very important to people worldwide and is something that often must be represented in computer programs. This raises the question of how money should be represented, which can vary from program to program. There is much to be considered such as string formatting, the way money is used, and the variety of different currencies in the world. In Chapter 6 of Skrien's ''Object-Oriented Design Using Java'', he suggests an implementation that represents money as a class, but there are other approaches that can be taken, each with their respective advantages and disadvantages.

==Properties of Money==
Money has certain properties and uses that must be considered in implementation.

===Responsibilities/Using Money===
The following are ways in which a representation of money should be able to be used: [http://courses.ncsu.edu/csc517//common/lectures/notes/lec20.pdf]
*To represent a positive or negative amount of money.
*Possibly representing multiple components of a currency - i.e. dollars and cents.
*Possibly representing amounts of multiple currencies - i.e. a mix of US Dollars, euros, and yen.'
*To have a string formatting potentially including currency symbols like the dollar sign ($) and/or commas and/or decimal points.
*Addition, subtraction, multiplication, and division.
The degree to which of the above must be met will depend on the depth of the implementing project.

===Different Currencies===
Some applications may only handle only one currency such as the US Dollar, but more generally applied applications, such as banking, must be able to handle different kinds of currencies.

There are currently over 180 currencies in use around the world.[http://en.wikipedia.org/wiki/List_of_circulating_currencies]

Implementation must be aware of how to specifically represent each currency used. Some currencies use decimal points, such as how the US has 100 cents to a dollar, while others have no decimal, such as yen. Each currency also has a different sign symbol used such as $, €, or ¥. Different currencies also have different rules about how rounding values is handled.

Special consideration must be taken when using different currencies in conjunction with each other. Foreign exchange rates can be used to convert between different currencies, but the exchange rate often change, so attention must be paid to that. In some cases, it is also important to keep track of how much money the user has of more than one currency at a time, so that must be handled somehow. [http://www.xencraft.com/resources/multi-currency.html][http://courses.ncsu.edu/csc517//common/lectures/notes/lec20.pdf]

===Immutable vs. Mutable===
Money values can be either mutable, meaning changeable, or immutable, meaning unchanging. Mutable money values are useful in that a new value does not need to be created for every change. However, mutable values cause problems for use in hash maps or with concurrency. The issue with concurrency is a read and write issue in a system with multiple users. With changing values, money not be what the user expects and lead to unpredictable behavior. Skrien feels this is a significant enough disadvantage to prefer an immutable representation for money.[http://courses.ncsu.edu/csc517//common/lectures/notes/lec20.pdf]

==Possible Representations==
There are several possible ways to represent money in code.

===Floating Point Number===
Floating point numbers seem like an appealing option since they already include a fractional component, which lends itself straightforward to currencies like the US dollar which also have a fractional component. However, floating point numbers come with a drawback due to the way floats are formatted. Since floats are based on binary representation rather than a decimal representation, a value that would be exact in decimal notation can only be stored approximately in a floats point number. For instance, 9.48 is stored as 9.479999542236328125. Performing calculations with these approximated values can lead to inaccurate results. [http://drdobbs.com/java/184405653] Another deficiency of floating point numbers is that they lose precision as the number gets larger. This is less of a problem when dealing with small amounts of currency, but when dealing with large amounts, on the order of the United States federal debt, the number of significant figures to the right of the decimal point decreases, again leading to possibly inaccurate results, especially with larger numbers.

===Two Integers===
For currencies with a fractional component, using two integers to represent one amount of money is an option. One integer to represent the main component and one to represent the fractional part. For US currency, this would mean an integer for dollars and an integer for cents. This representation makes displaying monetary values simple, as each component is already split out and accurate. Also, by using integers, calculations with money work out as they should, avoiding the loss of accuracy floating points have. However, code will need to be implemented to handle when the fraction component carries over. In the case of dollars and cents, if the cents exceed 100, the cents value should be decreased by 100 and the dollars increased by 1. This handling of carries adds overhead to calculations. The main drawbacks of this implementation is the added overhead and storage required. [http://courses.ncsu.edu/csc517//common/lectures/notes/lec20.pdf]

===One Integer, Implied Decimal Point===
One integer can be used to represent money, even including the fractional component. The location of the decimal place is simply implied based on the currency. For instance, a single integer representation of $12.34 would be 1234. A specialized print method would have to be constructed to display the monetary amount properly to the user, but all calculations work out properly. This approach has the same advantage that using two integers of maintaining accuracy, but does not have the added overhead or storage. In ''Object-Oriented Design Using Java'', Skrien considers this to be the best use of the primitive types for representing money. [http://courses.ncsu.edu/csc517//common/lectures/notes/lec20.pdf]

===BigDecimal===
Java offers a [http://docs.oracle.com/javase/6/docs/api/java/math/BigDecimal.html BigDecimal] class, which many people use for representing money. BigDecimal is capable of storing any size number since it stores each digit as an entry in an array, which grows as necessary. It also allows for specification of both the rounding method and the scale, the number of digits past the decimal place, for proper monetary calculations. [http://www.javaranch.com/journal/2003/07/MoneyInJava.html] On the downside, this specification for rounding and scale is required, which adds code to the implementation. [http://drdobbs.com/java/184405653] BigDecimal values are also immutable, which avoids read/write and write/write conflicts in applications. [http://www.opentaps.org/docs/index.php/How_to_Use_Java_BigDecimal:_A_Tutorial] While there are a lot of nice things about BigDecimal, there are some more issues with BigDecimal which can cause problems in representing money. BigDecimal cannot represent numbers with infinite digits such as 1/9 (.11111...) and throws an ArithmeticException on any calculation that would produce such number. To deal with this, hacks such as the following must be implemented:
BigDecimal bd1 = BigDecimal(1);
BigDecimal bd2 = BigDecimal(9);
try {
return bd1.divide(bd2);
} catch(ArithmaticException ae) {
return new BigDecimal(bd1.doubleValue() / bd2.doubleValue());
}
Also, since there isn't a BigDecimal equivalent for SQL databases, so storing BigDecimal values either requires conversion to a different format, which can affect accuracy and/or precision, or the value must be stored as a BLOB, which is cumbersome and inefficient. In general use, calculations with BigDecimal are significantly slower than with integers, and also take up more storage space. [http://lemnik.wordpress.com/2011/03/25/bigdecimal-and-your-money/]

===Class===
In ''Object-Oriented Design Using Java'', recommends using a class to represent money, rather than just using a long integer alone. He gives two reasons for using a class. The first is encapsulation - by encapsulating money into a class, all the operations specific to working with money can be implemented to work as desired in all cases, which also avoids code duplication. The second reason is that the compiler is better able to detect coding errors, such as adding money to something that isn't money. [http://courses.ncsu.edu/csc517//common/lectures/notes/lec20.pdf] Implementing Money as a class is a generally good idea, but there are multiple ways to go about it.

====Abstract Class====
If multiple kinds of currencies are needed to be represented, one implementation is to create an abstract Money class and have each possible currency be a subclass of the abstract class. Since there are over 180 different currencies worldwide, it can be a challenge to implement subclasses for each one required.

The following is the abstract class proposed by Skrien in Object-Oriented Design Using Java:
public abstract class Money implements Comparable<Money> {
public long getAmount()
public String toString()
public int compareTo(Money m)
public boolean equals(Object o)
public int hashCode()
public Money plus(Money)
public Money minus(Money)
public Money times(double factor)
public Money dividedBy(double divisor)
public Money negate()
}
[http://courses.ncsu.edu/csc517//common/lectures/notes/lec20.pdf]

====Single Class====
Rather than implementing a variety of subclasses for each currency, a single class can be used to represent money, with currency specified within. This is a good idea, since currencies basically operate the same calculation-wise, but have variations in decimal locations and the symbols used to present them. Java has a [http://docs.oracle.com/javase/6/docs/api/java/util/Currency.html Currency class] which holds the information for a given currency.

The following is the Single Class implementation given by Skrien in ''Object-Oriented Design Using Java'':

public class Money implements Comparable<Money> {
private long amount;
private Currency currency;
public Money(long amount, Currency currency) {
this.amount = amount;
this.currency = currency;
}
public long getAmount() { return amount; }
public Currency getCurrency() {
return currency; }
public String toString() { ...above... }
public int compareTo(Money o) { ... }
public boolean equals(Object o) { ... }
public int hashCode() { ... }
public Money plus(Money) { ... }
public Money minus(Money) { ... }
public Money times(double factor) { ... }
public Money dividedBy(double divisor) { ... }
public Money negate() { ... }
}
[http://courses.ncsu.edu/csc517//common/lectures/notes/lec20.pdf]

====Mixed Money====

====Using an Interface====

==Resources==
*Need to go through these for information
**[http://courses.ncsu.edu/csc517//common/lectures/notes/lec20.pdf PDF from class lecture]
**[http://docs.oracle.com/javase/1.4.2/docs/api/java/util/Currency.html Java's Currency class docs]
**[http://drdobbs.com/java/184405653 A standalone class to tackle the problem (in Java)]
**[http://www.javapractices.com/topic/TopicAction.do?Id=13 Representing money (Java)]
**[http://www.javaranch.com/journal/2003/07/MoneyInJava.html Working with money in Java]
**[http://timeandmoney.sourceforge.net/ Time and Money Java project - doesn't seem to have much documentation, though]
**[http://joda-money.sourceforge.net/ Joda Money class library for Java]
**[http://lemnik.wordpress.com/2011/03/25/bigdecimal-and-your-money/ BigDecimal and Your Money (a criticism of using BigDecimal format)]
**[http://www.opentaps.org/docs/index.php/How_to_Use_Java_BigDecimal:_A_Tutorial Tutorial on using BigDecimal]
**[http://junit.sourceforge.net/doc/testinfected/testing.htm JUnit Test Infected: Programmers Love Writing Tests (has a Money class example]
**[http://www.xencraft.com/resources/multi-currency.html Currency Internationalization (i18n), Multiple Currencies and Foreign Exchange (FX)] -nothing programming-wise, but a good overview of the considerations for currency
**[http://www.di-mare.com/adolfo/p/money.htm Yet Another C++ Money Class ]
**[http://edenti.deis.unibo.it/utils/Java-tips/Currency%20representation.txt Representing currencies (txt document with example and details)]

CSC/ECE 517 Fall 2011/ch3 3a oe

2011-10-13T03:07:14Z

Opevans: /* Ruby Introduction */

= Ruby Introduction =

Ruby is an interpreted, dynamically-typed, polymorphic, object-oriented programming language. The author, Yukuhiro "Matz" Matsumoto, describes it as blending aspects of Perl, Smalltalk, Eiffel, Ada, and Lisp. [http://www.ruby-lang.org/en/about/] As a result, it is very flexible language from top to bottom. It can be used as a procedural scripting language for rudimentary scripts, or as object oriented language.

Originally released in 1995, it gained widespread recognition a decade later with the availabiliy and widespread adoption of the web programming framework Ruby on Rails. [http://rubyonrails.org/]

== Basic syntax ==

In comparison with some other object-oriented or procedural languages such as Java or C, Ruby has a flexible syntax. Many aspects of a statement that would be required in Java are optional in Ruby.

* Semicolons at the end of each line are optional. They are generally used only when combining multiple statements on a single line.
* A return statement at the end of a method is not necessary. If there is no return statement, the return value of the last executed statement is returned.
* Method arguments. Methods can be created that will accept any number of arguments without using overloading in the conventional sense. Methods can be called with or without parentheses around arguments.
* Variable types. Types for variables do not need to be declared in Ruby.

In other cases, where there may be only one way to write a statement in Java, for example, there may be nearly limitless ways to do so in Ruby. The programmer is allowed to determine which way works best for the situation at hand.

=== Control Strucures ===

There are some significant differences in control structures between Ruby and Java.

==== Blocks and closures ====

==== Loops and iterators ====
These constructs all achieve the same result of printing the nubmers 1 through 5. It is left up to the programmer to decide which method works the best for the particular situation.

for i in 1..5 do puts i.to_s; end
for i in [1,2,3,4,5] do puts i.to_s; end
(1..5).each { |i| puts i.to_s }
[1,2,3,4,5].each { |i| puts i.to_s }
1.upto(5) { |i| puts i.to_s }
1.step(5,1) { |i| puts i.to_s }

== Object-Oriented principles ==

=== Everything is an object ===

In comparison with some other Object Oriented languages, Ruby is a very "pure" language, in that essentially everything is an object. There are no primitive types, and even numbers or literal strings are treated as objects and can have methods run on them.
5.times do puts "hello"; end
"hello".index('e') ->returns 1

=== Unbounded polymorphism ===

Object types and classes are not checked by the compiler (there is no compiler!) or at runtime. An object's class does not matter as long as it contains all the instance methods and variables that are accessed. This is also known as "Duck Typing," a reference to the famous "Duck test": If it looks like a duck, swims like a duck, and quacks like a duck, then it probably is a duck.

=== Dynamic typing ===

Data types of objects are handled and checked at runtime, as opposed to a statically typed language where they are checked at compile time. In a statically typed language like Java, when you define an array, it must be an array containing elements all of the same type. In dynamically typed languages like Ruby, each element of an array can be any type.

== Basic types/classes ==

=== Array ===
http://www.ruby-doc.org/core/Array.html

An array is an ordered one dimensional vector of objects. The objects in the vector are indexed with consecutive integers starting from zero. Any element in any array can be of any object type. An array is created as below:
@a1 = ['a', 2, :blah]
or
@a2[0] = 'a'
@a2[1] = 2
@a2[2] = :blah

The individual elements are accessed as below:
@a[0]
--> 'a'

Unlike some other languages, arrays in Ruby are dynamically allocated and can shrink and grow as necessary. Array elements can be accessed by negative indices as well. An index of -1 will retrieve the ultimate element in the array; an index of -2 will retrieve the penultimate element, and so on. An undefined array element that is written to by index will be allocated and defined automatically, while an undefined element read by index will return nil. Therefore, there will never be an out of bounds error for an array in Ruby.

Examples of useful instance methods:
* array.push(object): adds an element to the end of an array.,
* array.pop adds or retrieves the last element to/from the front of any array.
* array.unshift(object): adds an element to the front of an array.
* array.shift: removes and returns the element to the front of the array.
* array.each { |val| block }: iterator that executes the block once for each element in the array
* array.length: returns the number of elements in the array
* array.concat: Returns an array containing the array concatenated with another

=== Hash ===
http://www.ruby-doc.org/core/Hash.html

A hash is similar to an array, however it is not ordered and it is indexed by keys, which can be any object type. It functions as a mapping from the key to the value. An interesting point is that a hash could be treated just like an array, if all elements in the hash are indexed by integers.

A hash is defined as below:
@h1 = {'a' => 'foo', 2 => 'bar'}
or
@h2['a'] = 'foo'
@h2[2] = 'bar'

Examples of useful instance methods:
* hash.keys: returns an array populated with all the keys of the hash.
* hash.values: returns an array populated with all the values of the hash. If both keys and values are retrieved without modifying the hash between, the keys and values will be in the same order.
* array.each { |key,val| block }: iterator that executes the block once for each element in the hash

=== String ===
http://www.ruby-doc.org/core/String.html

A string is a sequence of bytes (Frequently characters.) It can be used to store data in any encoding: ASCII, unicode, or binary.

A string is defined as follows:
@s = "hello world"

Examples of useful instance methods:
* string.length: returns the number of bytes in the string.
* string.index(pattern) returns the index of the first occurence of a pattern or [http://www.ruby-doc.org/core-1.9.2/Regexp.html regular expression]
* string.sub(pattern, replacement): Substitutes the first occurrence of a substring or regular expression pattern with replacement.

=== Symbol ===
http://www.ruby-doc.org/core/Symbol.html

A symbol is similar to a string, with the exception that it is immutable - it cannot be changed once defined. Any reference to a particular symbol will refer to the same object for the entire time that a program is running. A symbol is defined as follows:

:Foo

CSC/ECE 517 Fall 2011/ch3 3a oe

2011-10-10T00:58:27Z

Opevans:

= Ruby Introduction =

Ruby is a very flexible language from top to bottom. It can be used as a procedural scripting language for rudimentary scripts, or as object oriented language.

== Basic syntax ==

In comparison with some other object-oriented or procedural languages such as Java or C, Ruby has a flexible syntax. Many aspects of a statement that would be required in Java are optional in Ruby.

-Semicolons at the end of each line are optional. They are generally used only when combining multiple statements on a single line.
-A return statement at the end of a method is not necessary. If there is no return statement, the return value of the last executed statement is returned.
-Method arguments. Methods can be created that will accept any number of arguments without using overloading in the conventional sense. Methods can be called with or without parentheses around arguments.

In other cases, where there may be only one way to write a statement in Java, for example, there may be nearly limitless ways to do so in Ruby. The programmer is allowed to determine which way works best for the situation at hand.

-Loops and iterators. These constructs all achieve the same result of printing the nubmers 1 through 5. It is left up to the programmer to decide which method works the best for the particular situation.

for i in 1..5 do puts i.to_s; end
for i in [1,2,3,4,5] do puts i.to_s; end
(1..5).each { |i| puts i.to_s }
[1,2,3,4,5].each { |i| puts i.to_s }
1.upto(5) { |i| puts i.to_s }
1.step(5,1) { |i| puts i.to_s }

== Object-Oriented principles ==

=== Everything is an object ===

In comparison with some other Object Oriented languages, Ruby is a very "pure" language, in that essentially everything is an object. There are no primitive types, and even numbers or literal strings are treated as objects and can have methods run on them.
5.times do puts "hello"; end
"hello".index('e') ->returns 1

=== Unbounded polymorphism ===

Object types and classes are not checked by the compiler (there is no compiler!) or at runtime. An object's class does not matter as long as it contains all the instance methods and variables that are accessed. This is also known as "Duck Typing," a reference to the famous "Duck test": If it looks like a duck, swims like a duck, and quacks like a duck, then it probably is a duck.

=== Dynamic typing ===

Data types of objects are handled and checked at runtime, as opposed to a statically typed language where they are checked at compile time. In a statically typed language like Java, when you define an array, it must be an array containing elements all of the same type. In dynamically typed languages like Ruby, each element of an array can be any type.

== Basic types/classes ==

=== Array ===
http://www.ruby-doc.org/core/Array.html

An array is an ordered one dimensional vector of objects. The objects in the vector are indexed with consecutive integers starting from zero. Any element in any array can be of any object type. An array is created as below:
@a1 = ['a', 2, :blah]
or
@a2[0] = 'a'
@a2[1] = 2
@a2[2] = :blah

The individual elements are accessed as below:
@a[0]
--> 'a'

Unlike some other languages, arrays in Ruby are dynamically allocated and can shrink and grow as necessary. Array elements can be accessed by negative indices as well. An index of -1 will retrieve the ultimate element in the array; an index of -2 will retrieve the penultimate element, and so on. An undefined array element that is written to by index will be allocated and defined automatically, while an undefined element read by index will return nil. Therefore, there will never be an out of bounds error for an array in Ruby.

Examples of useful instance methods:
* array.push(object): adds an element to the end of an array.,
* array.pop adds or retrieves the last element to/from the front of any array.
* array.unshift(object): adds an element to the front of an array.
* array.shift: removes and returns the element to the front of the array.
* array.each { |val| block }: iterator that executes the block once for each element in the array
* array.length: returns the number of elements in the array
* array.concat: Returns an array containing the array concatenated with another

=== Hash ===
http://www.ruby-doc.org/core/Hash.html

A hash is similar to an array, however it is not ordered and it is indexed by keys, which can be any object type. It functions as a mapping from the key to the value. An interesting point is that a hash could be treated just like an array, if all elements in the hash are indexed by integers.

A hash is defined as below:
@h1 = {'a' => 'foo', 2 => 'bar'}
or
@h2['a'] = 'foo'
@h2[2] = 'bar'

Examples of useful instance methods:
* hash.keys: returns an array populated with all the keys of the hash.
* hash.values: returns an array populated with all the values of the hash. If both keys and values are retrieved without modifying the hash between, the keys and values will be in the same order.
* array.each { |key,val| block }: iterator that executes the block once for each element in the hash

=== String ===
http://www.ruby-doc.org/core/String.html

A string is a sequence of bytes (Frequently characters.) It can be used to store data in any encoding: ASCII, unicode, or binary.

A string is defined as follows:
@s = "hello world"

Examples of useful instance methods:
* string.length: returns the number of bytes in the string.
* string.index(pattern) returns the index of the first occurence of a pattern or [http://www.ruby-doc.org/core-1.9.2/Regexp.html regular expression]
* string.sub(pattern, replacement): Substitutes the first occurrence of a substring or regular expression pattern with replacement.

=== Symbol ===
http://www.ruby-doc.org/core/Symbol.html

A symbol is similar to a string, with the exception that it is immutable - it cannot be changed once defined. Any reference to a particular symbol will refer to the same object for the entire time that a program is running. A symbol is defined as follows:

:Foo

CSC/ECE 517 Fall 2011/ch3 3a oe

2011-10-07T02:45:59Z

Opevans:

CSC/ECE 517 Fall 2011/ch3 3a oe

2011-10-07T02:40:14Z

Opevans:

Basic syntax
Ruby is a very flexible language from top to bottom. It can be used as a procedural scripting language or as object oriented language.

In comparison with some other object-oriented or procedural languages such as Java or C, Ruby has a flexible syntax. Many aspects of a statement that would be required in Java are optional in Ruby.

-Semicolons at the end of each line are optional. They are generally used only when combining multiple statements on a single line.
-A return statement at the end of a method is not necessary. If there is no return statement, the return value of the last executed statement is returned.
-Method arguments. Methods can be created that will accept any number of arguments without using overloading in the conventional sense. Methods can be called with or without parentheses around arguments.

In other cases, where there may be only one way to write a statement in Java, for example, there may be nearly limitless ways to do so in Ruby. The programmer is allowed to determine which way works best for the situation at hand.

-Loops and iterators. These constructs all achieve the same result of printing the nubmers 1 through 5. The

for i in 1..5 do puts i.to_s; end
for i in [1,2,3,4,5] do puts i.to_s; end
(1..5).each { |i| puts i.to_s }
[1,2,3,4,5].each { |i| puts i.to_s }
1.upto(5) { |i| puts i.to_s }
1.step(5,1) { |i| puts i.to_s }

Object-Oriented principles

Everything is an object.

In comparison with some other Object Oriented languages, Ruby is a very "pure" language, in that essentially everything is an object. There are no primitive types, and even numbers or literal strings are treated as objects and can have methods run on them.
5.times do puts "hello"; end
"hello".index('e') ->returns 1

Unbounded polymorphism

Object types and classes are not checked by the compiler (there is no compiler!) or at runtime. An object's class does not matter as long as it contains all the instance methods and variables that are accessed. This is also known as "Duck Typing," a reference to the famous "Duck test": If it looks like a duck, swims like a duck, and quacks like a duck, then it probably is a duck.

Dynamic typing

Data types of objects are handled and checked at runtime, as opposed to a statically typed language where they are checked at compile time. In a statically typed language like Java, when you define an array, it must be an array containing elements all of the same type. In dynamically typed languages like Ruby, each element of an array can be any type.

Basic classes

Array
www.ruby-doc.org/core/Array.html

An array is an ordered one dimensional vector of objects. The objects in the vector are indexed with consecutive integers starting from zero. Any element in any array can be of any object type. An array is created as below:
@a = ['a', 2, :blah]

The individual elements are accessed as below:
@a[0]
--> 'a'

Unlike some other languages, array elements can be accessed by negative indices as well. An index of -1 will retrieve the ultimate element in the array; an index of -2 will retrieve the penultimate element, and so on.

Examples of useful instance methods:
array.each { block }: iterator that executes the block once for each element in the array
array.length: returns the number of elements in the array
array.concat: Returns an array containing the array concatenated with another

Hash
www.ruby-doc.org/core/Hash.html

A hash is similar to an array, however it is not ordered and it is indexed by keys, which can be any object type. It functions as a mapping from the key to the value.

String
www.ruby-doc.org/core/String.html

Symbol
http://www.ruby-doc.org/core/Symbol.html

CSC/ECE 517 Fall 2011

2011-10-07T00:30:23Z

Opevans:

[[Link title]]
*[[CSC/ECE 517 Fall 2011/ch1 1a ms]]

*[[CSC/ECE 517 Fall 2011/ch1 1a cs]]

*[[CSC/ECE 517 Fall 2011/ch1 1a ri]]

*[[CSC/ECE 517 Fall 2011/ch1 1a lj]]

*[[CSC/ECE 517 Fall 2011/ch1 1b sa]]

*[[CSC/ECE 517 Fall 2011/ch1 1b ds]]

*[[CSC/ECE 517 Fall 2011/ch1 1b tj]]

*[[CSC/ECE 517 Fall 2011/ch1 1c cm]]

*[[CSC/ECE 517 Fall 2011/ch1 1c sj]]

*[[CSC/ECE 517 Fall 2011/ch1 1c ka]]

*[[CSC/ECE 517 Fall 2011/ch1 1d sr]]

*[[CSC/ECE 517 Fall 2011/ch1 1e vs]]

*[[CSC/ECE 517 Fall 2011/ch1 1e aa]]

*[[CSC/ECE 517 Fall 2011/ch1 1a sc]]

*[[CSC/ECE 517 Fall 2011/ch1 1e dm]]

*[[CSC/ECE 517 Fall 2011/ch1 1e an]]

*[[CSC/ECE 517 Fall 2011/ch1 1e sa]]

*[[CSC/ECE 517 Fall 2011/ch1 1e lm]]

*[[CSC/ECE 517 Fall 2011/ch1 1g vn]]

*[[CSC/ECE 517 Fall 2011/ch1 1f rs]]

*[[CSC/ECE 517 Fall 2011/ch1 1f sv]]

*[[CSC/ECE 517 Fall 2011/ch1 1g jn]]

*[[CSC/ECE 517 Fall 2011/ch1 1h ps]]

*[[CSC/ECE 517 Fall 2011/ch1 1e sm]]

*[[CSC/ECE 517 Fall 2011/ch1 1i zf]]

*[[CSC/ECE 517 Fall 2011/ch1 1g rn]]

*[[CSC/ECE 517 Fall 2011/ch1 1i cl]]

*[[CSC/ECE 517 Fall 2011/ch1 1d ss]]

*[[CSC/ECE 517 Fall 2011/ch1 1i lj]]

*[[CSC/ECE 517 Fall 2011/ch1 1h hs]]

*[[CSC/ECE 517 Fall 2011/ch1 1d gs]]

*[[CSC/ECE 517 Fall 2011/ch1 2b ns]]

*[[CSC/ECE 517 Fall 2011/ch1 2b jp]]

*[[CSC/ECE 517 Fall 2011/ch1 2a av]]

*[[CSC/ECE 517 Fall 2011/ch2 2f jm]]

*[[CSC/ECE 517 Fall 2011/ch2 2e ad]]

*[[CSC/ECE 517 Fall 2011/ch2 2e kt]]

*[[CSC/ECE 517 Fall 2011/ch2 2e gp]]

*[[CSC/ECE 517 Fall 2011/ch1 2b qu]]

*[[CSC/ECE 517 Fall 2011/ch2 2c bs]]

*[[CSC/ECE 517 Fall 2011/ch1 2c rs]]

*[[CSC/ECE 517 Fall 2011/ch1 2a ca]]

*[[CSC/ECE 517 Fall 2011/ch1 2b rv]]

*[[CSC/ECE 517 Fall 2011/ch2 2c ds]]

*[[CSC/ECE 517 Fall 2011/ch2 2b sa]]

*[[CSC/ECE 517 Fall 2011/ch2 2f vh]]

*[[CSC/ECE 517 Fall 2011/ch2 2e ps]]

*[[CSC/ECE 517 Fall 2011/ch3 3a oe]]

*[[CSC/ECE 517 Fall 2011/ch3 3h rr]]

*[[CSC/ECE 517 Fall 2011/ch3 3h ss]]

*[[trial]]

CSC/ECE 517 Fall 2011/ch3 3a oe

2011-10-07T00:29:31Z

Opevans: Created page with "Testing"

Testing

CSC/ECE 517 Fall 2010/ch1 S10 ms

2010-12-07T21:06:52Z

Opevans:

*[[CSC/ECE 517 Fall 2010/ch1 1a vc]]

*[[CSC/ECE 517 Fall 2010/ch1 1a br]]

*[[CSC/ECE 517 Fall 2010/ch1 1b mg]]

*[[CSC/ECE 517 Fall 2010/ch1 1c JF]]

*[[CSC/ECE 517 Fall 2010/ch1 1e az]]

*[[CSC/ECE 517 Fall 2010/ch1 1e bb]]

*[[CSC/ECE 517 Fall 2010/ch1 1f vn]]

*[[CSC/ECE 517 Fall 2010/ch1 25 ag]]

*[[CSC/ECE 517 Fall 2010/ch2 2b dg]]

*[[CSC/ECE 517 Fall 2010/ch1 2e RI]]

*[[CSC/ECE 517 Fall 2010/ch1 S6 aa]]

*[[CSC/ECE 517 Fall 2010/ch1 S6 km]]

*[[CSC/ECE 517 Fall 2010/ch1 S10 GP]]

*[[CSC/ECE 517 Fall 2010/ch1 S10 MS]]

*[[CSC/ECE 517 Fall 2010/ch1 S10 MM]]

*[[CSC/ECE 517 Fall 2010/ch1 S10 PH]]

*[[CSC/ECE 517 Fall 2010/ch2 2a CB]]

*[[CSC/ECE 517 Fall 2010/ch2 2a mw]]

*[[CSC/ECE 517 Fall 2010/ch2 2c ck]]

*[[CSC/ECE 517 Fall 2010/ch2 S23 GP]]

*[[CSC/ECE 517 Fall 2010/ch2 S24 NS]]

*[[CSC/ECE 517 Fall 2010/ch2 S23 SS]]

*[[CSC/ECE 517 Fall 2010/ch2 S23 NR]]

*[[CSC/ECE 517 Fall 2010/ch2 S20 TT]]

*[[CSC/ECE 517 Fall 2010/ch2 2d AS]]

*[[CSC/ECE 517 Fall 2010/ch2 S24 rm]]

*[[CSC/ECE 517 Fall 2010/ch3 3a SN]]

*[[CSC/ECE 517 Fall 2010/ch3 3b ka]]

*[[CSC/ECE 517 Fall 2010/ch3 3e br]]

*[[CSC/ECE 517 Fall 2010/ch3 3f lj]]

*[[CSC/ECE 517 Fall 2010/ch3 3h az]]

*[[CSC/ECE 517 Fall 2010/ch3 3h PW]]

*[[CSC/ECE 517 Fall 2010/ch3 3i IC]]

*[[CSC/ECE 517 Fall 2010/ch3 3i MM]]

*[[CSC/ECE 517 Fall 2010/ch3 3j KS]]

*[[CSC/ECE 517 Fall 2010/ch3 S30 SK]]

*[[CSC/ECE 517 Fall 2010/ch3 4b mt]]

*[[CSC/ECE 517 Fall 2010/ch4 4e ms]]

*[[CSC/ECE 517 Fall 2010/ch4 4f sv]]

*[[CSC/ECE 517 Fall 2010/ch4 4g HW]]

*[[CSC/ECE 517 Fall 2010/ch4 4g km]]

*[[CSC/ECE 517 Fall 2010/ch4 4h am]]

*[[CSC/ECE 517 Fall 2010/ch5 5b mt]]

*[[CSC/ECE 517 Fall 2010/ch5 5b jz]]

*[[CSC/ECE 517 Fall 2010/ch5 5c ck]]

*[[CSC/ECE 517 Fall 2010/ch5 5c IC]]

*[[CSC/ECE 517 Fall 2010/ch5 5f SN]]

*[[CSC/ECE 517 Fall 2010/ch5 5a KR]]

*[[CSC/ECE 517 Fall 2010/ch5 5b RR]]

*[[CSC/ECE 517 Fall 2010/ch5 5e ms]]

*[[CSC/ECE 517 Fall 2010/chd 6d isb]]

*[[CSC/ECE 517 Fall 2010/ch6 6b SK]]

*[[CSC/ECE 517 Fall 2010/ch6 6c AW]]

*[[CSC/ECE 517 Fall 2010/ch6 6d bb]]

*[[CSC/ECE 517 Fall 2010/ch6 6h AS]]

*[[CSC/ECE 517 Fall 2010/ch6 6f AZ]]

*[[CSC/ECE 517 Fall 2010/ch6 6b AK]]

*[[CSC/ECE 517 Fall 2010/ch6 6g ss]]

*[[CSC/ECE 517 Fall 2010/ch6 6d NM]]

*[[ CSC/ECE 517 Fall 2010/ch6 6a PC]]

*[[ CSC/ECE 517 Fall 2010/ch2 4d RB]]

*[[ CSC/ECE 517 Fall 2010/ch7 71 ed]]

*[[ CSC/ECE 517 Fall 2010/ch7 7c ed]]

*[[ CSC/ECE 517 Fall 2010/ch7 7e GP]]

*[[ CSC/ECE 517 Fall 2010/ch7 7e GS]]

*[[ CSC/ECE 517 Fall 2010/ch7 7f PW]]

*[[ CSC/ECE 517 Fall 2010/ch7 7g ms]]

*[[ CSC/ECE 517 Fall 2010/ch7 7i sr]]

*[[ CSC/ECE_517_Fall_2010/ch7 7b JB]]

*[[ CSC/ECE_517_Fall_2010/ch7 S36 JB]]

*[[ CSC/ECE_517_Fall_2010/ch7 n 7i OE]]

CSC/ECE 517 Fall 2010/ch7 n 7i OE

2010-12-07T21:02:38Z

Opevans:

== Visual Object Oriented Programming ==

Visual programming languages are a class of languages where the program is defined by a series of interconnected pictoral icons rather than textual statements. Many graphical programming languages are designed to be accessable to those without formal training in programming. Theoretically, a visual programming language might be easier for a novice to comprehend, as rather than memorizing syntax and methods, the user is presented with a pallette of icons to choose from and can lay them out in a logical and familiar way, similar to an electric circut diagram.

Visual programming languages often have several disadvantages. Though the basic functionality may be more accessible to novices than text-based languages, there is a tradeoff. It may be more difficult to implement complicated algorithms or control paths. Complicated programs are difficult to keep clean. and "spaghetti" code may result. Many visual programming languages have been developed for a host of reasons, but few have been widely adopted. The two examples below are exceptions, and have garnered a significant user base.

== Labview / G ==

Labview is a proprietary programming language developed by National Instruments. It is widely used in laboratory environments for control and operation of experimental equipment. LabView's target users generally do not have formal training in computer programming so it is designed to be intuitive. The program is graphically represented in a manner similar to an electrical schematic. Labview is considered to be a dataflow language, where operations are performed as soon as their inputs become valid, rather than when they are encountered in code.

As of version 8.2, LabView or G incorporates several object-oriented principles. Given LabView's orientation towards non-programmers, the language's designers made some tradeoffs between implementing all aspects of object-oriented languages, and maintaining simplicity. The result was that two of the tenets of OO programming were implemented: Encapsulation and Inheritence.

'''Encapsulation'''. LabView implements classes and supports the concepts of public, private, and protected methods, but private data only. Private data within classes is accessed and modified by accessor methods (known as virtual instruments, or VIs.)

'''Inheritance'''. Classes can inherit other classes. Because there is no protected or public data, all data from parent classes must be accessed through the accessor methods.

There are several significant differences between the implementation of Object-Oriented principles in an imperitave language like Java or C++ and LabView. In Java, classes are passed by reference; in C++ they can be passed by reference or value. In LabView, they are passed by value only and therefore may be duplicated by the compiler. Many existing OO design patterns, specifically those from the Gang of Four book, depend on classes that are passed by reference. Therefore, the LabView developers have designed a different set of design patterns
LabVIEW Object-Oriented Programming: The Decisions Behind the Design [[http://zone.ni.com/devzone/cda/tut/p/id/3574]]
[[http://decibel.ni.com/content/docs/DOC-2875]]

== Prograph ==

Prograph is a programming language developed in the 1980s and 1990s primarily for the Macintosh in the 1980s and 1990s. While LabView is designed specifically for controlling and collecting data from experimental equipment, Prograph is intended as more of a multipurpose language. Similar to LabView, it follows the dataflow paradigm.

Prograph supports encapsulation and data abstraction through classes with single inheritance.

Prograph achieved its greatest adoption for small applications developed in-house potentially by non-programmers. Though it faded to obscurity after the company developing it went bankrupt in 1995, since then, user groups have brought about its reemergence as an open standard.

Qinwei Zhu, Jiunwei Chen, Visual Programming. [[http://courses.cs.vt.edu/~cs6704/VPL.ppt]]

CSC/ECE 517 Fall 2010/ch7 n 7i OE

2010-12-07T21:01:58Z

Opevans:

== Visual Object Oriented Programming ==

Visual programming languages are a class of languages where the program is defined by a series of interconnected pictoral icons rather than textual statements. Many graphical programming languages are designed to be accessable to those without formal training in programming. Theoretically, a visual programming language might be easier for a novice to comprehend, as rather than memorizing syntax and methods, the user is presented with a pallette of icons to choose from and can lay them out in a logical and familiar way, similar to an electric circut diagram.

Visual programming languages often have several disadvantages. Though the basic functionality may be more accessible to novices than text-based languages, there is a tradeoff. It may be more difficult to implement complicated algorithms or control paths. Complicated programs are difficult to keep clean. and "spaghetti" code may result. Many visual programming languages have been developed for a host of reasons, but few have been widely adopted. The two examples below are exceptions, and have garnered a significant user base.

== Labview / G ==

Labview is a proprietary programming language developed by National Instruments. It is widely used in laboratory environments for control and operation of experimental equipment. LabView's target users generally do not have formal training in computer programming so it is designed to be intuitive. The program is graphically represented in a manner similar to an electrical schematic. Labview is considered to be a dataflow language, where operations are performed as soon as their inputs become valid, rather than when they are encountered in code.

As of version 8.2, LabView or G incorporates several object-oriented principles. Given LabView's orientation towards non-programmers, the language's designers made some tradeoffs between implementing all aspects of object-oriented languages, and maintaining simplicity. The result was that two of the tenets of OO programming were implemented: Encapsulation and Inheritence.

Encapsulation. LabView implements classes and supports the concepts of public, private, and protected methods, but private data only. Private data within classes is accessed and modified by accessor methods (known as virtual instruments, or VIs.)

Inheritance. Classes can inherit other classes. Because there is no protected or public data, all data from parent classes must be accessed through the accessor methods.

There are several significant differences between the implementation of Object-Oriented principles in an imperitave language like Java or C++ and LabView. In Java, classes are passed by reference; in C++ they can be passed by reference or value. In LabView, they are passed by value only and therefore may be duplicated by the compiler. Many existing OO design patterns, specifically those from the Gang of Four book, depend on classes that are passed by reference. Therefore, the LabView developers have designed a different set of design patterns
LabVIEW Object-Oriented Programming: The Decisions Behind the Design [[http://zone.ni.com/devzone/cda/tut/p/id/3574]]
[[http://decibel.ni.com/content/docs/DOC-2875]]

== Prograph ==

Prograph is a programming language developed in the 1980s and 1990s primarily for the Macintosh in the 1980s and 1990s. While LabView is designed specifically for controlling and collecting data from experimental equipment, Prograph is intended as more of a multipurpose language. Similar to LabView, it follows the dataflow paradigm.

Prograph supports encapsulation and data abstraction through classes with single inheritance.

Prograph achieved its greatest adoption for small applications developed in-house potentially by non-programmers. Though it faded to obscurity after the company developing it went bankrupt in 1995, since then, user groups have brought about its reemergence as an open standard.

Qinwei Zhu, Jiunwei Chen, Visual Programming. [[http://courses.cs.vt.edu/~cs6704/VPL.ppt]]