https://issues.apache.org/jira/browse/OFBIZ-2019
--- On Fri, 10/24/08, Scott Gray <[EMAIL PROTECTED]> wrote: > From: Scott Gray <[EMAIL PROTECTED]> > Subject: Re: Entity Field Type Checking and Move BigDecimal versus Double > Stuff > To: dev@ofbiz.apache.org > Date: Friday, October 24, 2008, 3:03 PM > 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 > >>>>> > >>>>> > >>>>> > >>> > >>> > > > >
