After I posted I noticed that the requirements were for a String constructor and an ".accept(String)" method. These, also are consistent with an immutable class, although the .accept method will have to return a new instance in that case, and might as well be a static factory method. (As such it would not conform to standard Java naming conventions, but that's a nit.)
In any case, to build a new Number object as the result of an operation, you'll probably want a private constructor that builds a number from an linked list of Digits, a sign and a mantissa.
I woke up with a clearer picture of another possibility for the constructor of the queue of digits. A special zero digit could serve as the root of the Digit list. It would have to be recognizable (by identity) or by a boolean flag to distinguish it from the other zeroes that just happen to be in the string of digits.
Also - I double checked and I got the terms backward as I 're-purposed' them.
"Characteristic" and "mantissa" classically apply to logarithms. When they do, it is the "mantissa" or integer part which encodes the power of 10, and the "characteristic" or decimal which specifies the series of digits composing the value.
Of course, the numbers you're designing aren't logarithms. Whereas 0.30103 (with a mantissa of 0 and a characteristic of .30103) is an approximation of the log of 2, 3.30103 goes for 2000, etc. In your case the exponent plays a the notation instead be "0.30103 e 3" for the number 301.03.
here is a discussion: http://www.tpub.com/math1/
I apologize for making the mistake and regret if it caused any confusion.
Main Topics
Browse All Topics
by: rpnmanPosted on 2009-09-17 at 23:27:09ID: 25363267
This is one of the most detailed specifications I've ever seen for an exercise of this sort. Much of the implementation is spelled out for you.
Here is the strategy I would follow for tackling this task:
As a general rule, I would always put unit tests in place every step along the way and keep them in place and regularly execute this. If you do not have a unit test framework (or you have not yet studied that process) then at least add a main method to each class that conducts basic tests on it, and write a few extra integration tests as you go. This can save an enormous amount of time in the long run.
I would start with the digit "node" class. "Digit" might be a better name. Implement and test the basic ability to hold a value, adding, removing and inserting in a queue. Cover the case of a single digit, then add more.
Building on that I would design the Number class as described. with no operations at all. Consider having it eliminate leading and trailing zeroes automatically to make your job easier, but be sure to handle the case of zero itself as an exception to this rule. (Imply them by the mantissa: 1234 e -8 = 0.00001234).
Perhaps your Number elements should be immutable after the last digit has been added, so the result of any operation is a new Number object. This practice would be consistent with what is done in other solutions like this, and would simplify your task in many ways. If you do this, your constructor should accept all of the digits at once (perhaps as an array or list) to avoid the problem of a partially formed Number.
After getting the basic framework in place, tackle the problem of getting the Number class to display itself correctly. Placing the sign, the decimal point, leading zeroes as needed, etc. This will make further testing easier.
After that add simple magnitude comparison logic and then the operations. I'd start with addition first, as it is by far the easiest. Since you do not have to deal with division, you are NOT faced with the problem of recognizing and dealing with infinitely continuing fractions. That is why the spec says "You can be thankful for this."
Hope this helps.
Have fun. (I mean it.)
Select allOpen in new window