Home » Eclipse Projects » EclipseLink » a custom number class
| a custom number class [message #382753] |
Mon, 20 October 2008 11:51  |
 Tom Eugelink
Messages: 817
Registered: July 2009 |
Senior Member |
|
|
Ok, I know this is very "on the edge", but I'm almost there. So close...
I'm using jGoodies binding library, and one of the properties in my BM got an update because "0.00" is not equal to "0". But because that property has a restriction on when an update is allowed, an IllegalArgumentException was thrown. The problem naturally is that the update should not have occurred: the value was 0 and remained 0.
Now I understand that "0.00" and "0" are not equal, taking the scale into account, but I got frustrated have to yet-again deal with these scale and rounding nuances, so I decided to try and roll-in an experimental Number class I've written some time ago called "AnyNumber"
AnyNumber does away with rounding, because it stores every number as a division. So 0,3333333 is stored as "1 divided by 3". Like BigDecimal I added all the required mathematical methods like add, subtract, multiply, power, abs, sgn, etc, etc. AnyNumber uses BigInteger for its internal storage, so it can become very big, and naturally it is optimized when the divider is ONE.
It also implements the Number interface and has conversions from and to the regular numeric types.
First step I took is to add a converter class to the BM, allowing the reading and writing from regular database numbers. I needed some tweaks in the Swing environment to spit out the correct class, but as a whole it is up and running within a working day.
Load, persist, searching, everything works just fine! My screens all work, and my scale problem went away like snow in the Sahara. So all is peachy except one thing: sorting. When I try to sort in a AnyNumber field, I get an error message:
"invalid ORDER BY item [t.iVersion] of type [org.tbee.math.AnyNumber], expected expresion of an orderable type"
Is there anyway to make sorting on these custom items possible?
Maybe the Converter interface could be extended with a method to provide the information to enable sorting on @Convert fields?
It would be a shame to fail over this, after all the rest fell into place.
Tom
|
|
| | | | |
| Re: a custom number class [message #382765 is a reply to message #382760] |
Tue, 21 October 2008 13:05  |
|
Please log a bug for this, we should not be doing such validation.
Include the exception stack trace.
BTW your AnyNumber class was called Fraction in the old Smalltalk days.
Possibly you could store it in the database as a long using the high int
for the numerator and the low int for the denominator, perhaps as a string
as well, but in general unless your writing some mathematical application
it is probably not worth the trouble.
James : Wiki : Book : Blog : Twitter
|
|
|
| Re: a custom number class [message #382767 is a reply to message #382765] |
Tue, 21 October 2008 13:57 |
Tom Eugelink
Messages: 817
Registered: July 2009 |
Senior Member |
|
|
> Please log a bug for this, we should not be doing such validation.
> Include the exception stack trace.
Bug#: 251533
> BTW your AnyNumber class was called Fraction in the old Smalltalk days.
Interesting. The pureness of Smalltalk always is impressive. Maybe I should rename my class :-)
FYI my class name was derived from the fact that the Java number classes cannot store all numbers, like 1/3 cannot be correctly written in the decimal system, there are also numbers that cannot be correctly written in the binary system.
> Possibly you could store it in the database as a long using the high int
> for the numerator and the low int for the denominator, perhaps as a
> string as well, but in general unless your writing some mathematical
> application it is probably not worth the trouble.
Maybe. The production solution to the problem involved patching the scale of the BigDecimal and is already up and running.
But I do get frequently frustrated by all the scale and rounding issues that one has to cope with, just for doing some simple calculating, even in financial applications. Back in the days of school things were simple; 1/3 was 1/3, not 0.33 or 0.3 or 0. AnyNumber does take away all those worries, so it certainly makes other areas less complex. But database storage still doesn't have a nice solution.
Another possible approach would be to only use it during calculations. I mean, the price of an item is rounded anyhow, and so are the amounts (in the end some human has to pick that order), and that is the input for any calculation. The output must be a payable amount, so is also rounded (ever tried to type 0.33333333333333 in your banking application?).
IOW if AnyNumber can easily use the other numbers, it still is an interesting class to use for calculation. That is what I'll be trying in the production BM.
|
|
| |
Goto Forum:
Current Time: Thu Apr 25 00:38:40 GMT 2024
Powered by FUDForum. Page generated in 0.04622 seconds |
] 
Search
Help
Register
Login
Home
