Ok forget what I said about the set element, it does give out the type that it took in. I still think we need to do something about calculate though.
Regards Scott 2008/10/25 Scott Gray <[EMAIL PROTECTED]>: > 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 >>>>>> >>>>>> >>>>>> >>>> >>>> >> >> >
