Thanks David, that all makes perfect sense. Next question :-) Some of the minilang operations need to be revised I think, for example <set> uses string as the default type and <calculate> defaults to a Double. I'm wondering if we should make the type attribute required, I've seen bugs in the past because people haven't bothered to specify a type and my bet is that people assume in a lot of cases that the type (for calculate at least) that they are passing in will be the type to come out.
The other option for calculate is that we could take Groovy's approach and choose the best type available for the operation if one isn't specified: http://groovy.codehaus.org/Groovy+Math#GroovyMath-Mathoperations WDYT? Thanks Scott 2008/10/24 David E Jones <[EMAIL PROTECTED]>: > > On Oct 23, 2008, at 3:15 AM, Scott Gray wrote: > >> Hi David, everyone >> >> I thought I'd set about changing pretty much all the doubles in the >> accounting component to BigDecimal and I've got a couple of questions: >> 1. Do we need to follow the standard path we've taken in the past >> where we deprecate any methods taking or returning doubles and add Bd >> to the end of a new BigDecimal version? I guess we do but it's going >> to take a longer so I figure no harm in asking. > > I'm not sure where these got started, but they seem only really useful if > you want a BigDecimal version of a function AND a Double version of it. > > I'd say no, there is no reason to continue following this pattern. It may > break backward compatibility in esoteric areas, but really this should be > considered a bug and all code affected should be moved to use BigDecimal > instead of Double anyway. > >> 2. Slightly OT but I can't see the point of the scaled and rounded >> ZEROs in the java files, could someone explain the advantage of them >> over BigDecimal.ZERO? > > In older versions of Java there was no BigDecimal.ZERO, so this is probably > from older code and should updated. > >> 3. Could someone give me an example of when to use >> floating-point/double over fixed-point/BigDecimal? I'm not 100% sure >> of that one. > > Since we're doing business applications most things should be fixed point. > The problem with floating point is that certain decimal numbers are not > represented accurately and so if used without rounding in a calculation > you'll get weird results, usually something like a bunch of 9s or 1s at the > end of a decimal part of the number. This is because a binary number > representation for non-integer numbers basically look at 1/2 and 1/2 of 1/2 > and 1/2 of 1/2 of 1/2, and not all fractions split up evenly like that, so > even with a 64 bit floating point number when converted back into a base-10 > number you get something weird. > > So when to use a floating point number? When you are dealing with extreme > numbers where precision beyond a certain number of significant digits > doesn't matter so much. For financial things ALL digits are significant, so > a number representation that may cause you to lose some is a BAD thing. For > scientific stuff sometimes you need numbers that are on the order to 10E30 > or 10E-30 or the like that don't work so well for fixed point things, but > they only really care about, say, 5 of the 30 or more possible significant > digits. > > -David > > >> >> 2008/10/22 David E Jones <[EMAIL PROTECTED]>: >>> >>> I've created a branch, now available at: >>> >>> https://svn.apache.org/repos/asf/ofbiz/branches/typecheckcleanup200810 >>> >>> The branch split was revision 706867, so we can merge from the trunk at >>> that >>> rev going forward, and eventually merge back into the trunk once we're >>> comfortable that enough things have been tested by running, perhaps using >>> a >>> bunch of the automated tests too (not sure how well those run in the >>> trunk >>> right now though, ie I haven't run them in quite some time!). >>> >>> Anyway, the main initial process that I targeted was ecommerce browsing, >>> add >>> to cart, and checkout/order. Still need to test basic things like order >>> fulfillment, purchasing and receiving, and tons of other stuff, but >>> hopefully most other things won't be impacted as much. >>> >>> Any and all help is appreciated! >>> >>> -David >>> >>> NOTE: I'm still checking out the branch and applying my patch with the >>> work >>> so far, so it'll be a few minutes before that's in. >>> >>> On Oct 21, 2008, at 10:20 PM, Scott Gray wrote: >>> >>>> +1 for making the changes and I'm happy to help with the mundane stuff. >>>> >>>> Regards >>>> Scott >>>> >>>> 2008/10/22 David E Jones <[EMAIL PROTECTED]>: >>>>> >>>>> I added some stuff to make the warnings from entity field type checks a >>>>> bit >>>>> more prominent, and include a stack trace to make them easier to track >>>>> down. >>>>> I tried throwing exceptions instead of the warning log messages but >>>>> that >>>>> pretty much breaks everything, especially because we have lots of >>>>> BigDecimal/Double problems... >>>>> >>>>> On the BigDecimal versus Double stuff, one of the main type change >>>>> problems >>>>> comes from this old issue. To help resolve this I'd like to change the >>>>> java-type of currency-amount and currency-precise to BigDecimal instead >>>>> of >>>>> Double. >>>>> >>>>> It doesn't make sense to change the "floating-point" type's java-type >>>>> to >>>>> BigDecimal, because it really is a floating point like a Double. >>>>> However, >>>>> we >>>>> also have many fields that need decimal precision but really should be >>>>> fixed >>>>> point and not floating point... but they really aren't "currency". For >>>>> these >>>>> I propose to add a "fixed-point" field type. This would have a >>>>> BigDecimal >>>>> java-type and in the database should have a type that is also fixed >>>>> point >>>>> (ie not DOUBLE or FLOAT), unless the database has no fixed point types >>>>> (which is a big minus for those databases). Also, the floating-point >>>>> type >>>>> should have a Double java-type and a floating point SQL type. >>>>> >>>>> One side effect to changing the java-type on these field types is that >>>>> it >>>>> changes services definitions that are based on entity definitions, >>>>> which >>>>> causes the service engine to throw exceptions for type checks... and it >>>>> does >>>>> throw exceptions instead of just printing warning messages, so it does >>>>> break >>>>> stuff when doing that. >>>>> >>>>> This is a change that we can't switch back and forth on. Either all of >>>>> these >>>>> services take a Double typed parameters, or BigDecimal typed ones... >>>>> and >>>>> never some of each. >>>>> >>>>> Because of this I'm actually tempted to do a branch and get the changes >>>>> going. I'm paying with a few common processes with this in place right >>>>> now. >>>>> >>>>> Any thoughts related to this would be appreciated. >>>>> >>>>> Checking types... what a can of worms! >>>>> >>>>> -David >>>>> >>>>> >>>>> >>> >>> > >
