tag:blogger.com,1999:blog-741750605858169835.post4878176847801191948..comments2024-01-24T14:53:02.919+00:00Comments on Stephen Colebourne's blog: Java 7 - What to do with BigDecimal?Stephen Colebournehttp://www.blogger.com/profile/01454237967846880639noreply@blogger.comBlogger30125tag:blogger.com,1999:blog-741750605858169835.post-8348043535331947922022-11-17T01:38:56.218+00:002022-11-17T01:38:56.218+00:002022 and Java 19 - and not any better yet, it'...2022 and Java 19 - and not any better yet, it's a shame ... :(Lindahttps://www.blogger.com/profile/11878065306426557348noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-57785491487779483232017-04-14T01:12:29.310+01:002017-04-14T01:12:29.310+01:00For me the biggest problem with BigDecimal was the...For me the biggest problem with BigDecimal was the api and problems with equals method (1.20 is not equal to 1.200). So much so, that i made a custom Decimal implementation that "fixes" most issues of BigDecimal and provides groovy and kotlin operators: https://github.com/MatejTymes/JavaFixesMatej Tymeshttps://www.blogger.com/profile/01374039014087672059noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-20367819483287622632017-01-19T11:52:10.116+00:002017-01-19T11:52:10.116+00:00Maybe it might be interesting for you my small inv...Maybe it might be interesting for you my small investigation about BigDecimal literal:<br />https://github.com/cheptsov/AdvancedExpressionFolding/issues/14#issuecomment-273756356stokitohttps://www.blogger.com/profile/12691568036832912137noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-86053183692160682402015-05-28T13:58:17.076+01:002015-05-28T13:58:17.076+01:002015 and Java8 - and not any better yet, it's ...2015 and Java8 - and not any better yet, it's a shame ... :(Anonymoushttps://www.blogger.com/profile/05667830260667914581noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-41825118803961400082007-07-29T00:01:20.000+01:002007-07-29T00:01:20.000+01:00Wow, this shook my world a bit. It made me look at...Wow, this shook my world a bit. It made me look at the .Net spec which defines that "CIL opcodes are one or more bytes long". Perhaps we should have looked more into the future?Srgjan Srepflerhttp://schrepfler.blogspot.comnoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-8475321022279979032007-07-20T23:06:23.000+01:002007-07-20T23:06:23.000+01:00Frankly, I cannot see much use in it.
Besides of ...Frankly, I cannot see much use in it.<br /><br />Besides of the (outstanding) coercion rules which open the door for many Java Puzzlers ("CAFEBABE") to come - my uses of BigDecimal had been mostly for the defined rounding semantics (i.e. fixed-point libraries) which can't be expressed by the literals (unless you add even more).<br /><br />Overloading math operators for BigXxx would be a nice syntactic shortcut, but literals (besides 0) are not really used that often when working with BigDecimals.Carsten Saagerhttp://saager.orgnoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-42669931065918300512007-07-15T19:39:43.000+01:002007-07-15T19:39:43.000+01:00My preference for operator overloading would be to...My preference for operator overloading would be to make interfaces that would have to be implemented for the compiler to do overloading. The semantics can then be defined on this interface (eg. binary '+' is 'add', unary '+' is plus; 'add' method must be be commutative, associative, etc.).<br /><br />Don't know the maths well enough, but would a parameterised 'Ring' and 'Field' work?<br /><br />Eg. BigDecimal implements FieldBen Lingsnoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-39359395858879873542007-07-14T12:47:07.000+01:002007-07-14T12:47:07.000+01:00@Stephen: "What would the literal G/g suffix ...@Stephen: "What would the literal G/g suffix be short for?"<br />Nothing particular. I just liked the G ;)<br />Actually, one could think of T or t as suffix, which could be short for "ten based / base ten" a.k.a. decimal. One should actually do some brain storming on if it would be possible to replace the current number usage with BigDecimal or type-inference in general. For example, don't override operators in BD but in Number and try handling different subclasses thereof by autoconversion or similar.Stefan Schulzhttp://jroller.com/page/jaddanoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-87413680793600684312007-07-14T00:18:27.000+01:002007-07-14T00:18:27.000+01:00Take a look at the Java operator compiler:
https:...Take a look at the Java operator compiler:<br /><br />https://jop.dev.java.net/Bill Rightnoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-2965400601907782592007-07-13T19:25:18.000+01:002007-07-13T19:25:18.000+01:00I've been doing some benchmarking of BigDecima...I've been doing some benchmarking of BigDecimal. Turns out to be difficult to keep JNI overhead out of the numbers, and also it often takes much longer just to print results than to do the calculations that you're trying to measure. See this http://forums.java.net/jive/thread.jspa?threadID=18620&tstart=60 for example. Turns out after I posted that I figured out that the slowness is due to concatenation of Strings and a bit of I/O slowness, not due to something slow in BigDecimal.<br /><br />I also would like the ability to use operator overloading for BigDecimal. When we translate COBOL code to Java, we have to translate all operations from the pretty syntax to ugly method calls. That won't go over well when you're trying to convince customers that Java is more readable than COBOL.Andy Trippnoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-80243187554043091482007-07-13T14:06:13.000+01:002007-07-13T14:06:13.000+01:00I think I'd prefer that an undecorated decimal...I think I'd prefer that an undecorated decimal value would be presumed to be BigDecimal (instead of Double). That, of course, fails the backwards compatibility test. We could use X|x as a suffix (roman numeral 10) as a big decimal indicator, at the risk of confusing anyone who uses leading X's to indicate hex constants.<br /><br />I think baking in support for big decimal literals without adding the primitive (using String and Array as precedents) is a good compromise.David Hallhttp://jroller.com/page/dhallnoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-56958272279734558022007-07-13T13:51:27.000+01:002007-07-13T13:51:27.000+01:00Stephen, it's hardly backwards compatible, but...Stephen, it's hardly backwards compatible, but couldn't that be resolved by using reified generics? To my knowledge, in C# the byte code is the same for add/subtract etc. regardless of the primitive in question. I remember hearing Anders Hejlsberg talk about this very issue a while back.Caspernoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-59216410789049710292007-07-13T09:54:19.000+01:002007-07-13T09:54:19.000+01:00@Stefan, What would the literal G/g suffix be shor...@Stefan, What would the literal G/g suffix be short for?<br /><br />@Srgjan, The 35 bytecodes refers to the number of bytecodes (out of 256) still unused (http://en.wikipedia.org/wiki/Java_bytecode). These would be used up rapidly if a primitive decimal was added (as each primitive uses many bytecodes).<br /><br />Adding a literal syntax that operates like String by constructing a class (BigDecimal in this case) does not of course require any bytecode changes.Stephen Colebournenoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-62492421394485878162007-07-13T01:49:36.000+01:002007-07-13T01:49:36.000+01:00What do you mean by "There are 35 bytecodes f...What do you mean by "There are 35 bytecodes free at the moment."? I'm somewhat with the adding a decimal type in java as a syntactic sugar and using the compiler to generate some BigDecimal bytecode behind, that way you'd have binary compatibility and would (hopefully) not need to add new bytecode, though I wasn't aware all bytecode space has been used, I really can't believe that.Srgjan Srepflerhttp://schrepfler.blogspot.comnoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-16248740336992635962007-07-12T19:02:40.000+01:002007-07-12T19:02:40.000+01:00I like the idea of introducing new literals for Bi...I like the idea of introducing new literals for BigDecimal. Operator overloading for a type that has a literal representation seems quite logical to me. Primitives, on the other hand, are a real pain in OO. I'd rather like all primitives to be replaced by literals, only caring about objects in future.<br />Although, the suffix is of lesser importance, I'd rather chose G/g. A solution as in Groovy would be a nice possibility, though.Stefan Schulzhttp://jroller.com/page/jaddanoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-75727174770811100112007-07-12T17:57:49.000+01:002007-07-12T17:57:49.000+01:00@George Bush:
BigDecimal was written by veteran Jo...@George Bush:<br />BigDecimal was written by veteran Josh Bloch, to his defense a base 10 decimal that does not feel awkward is not an entirely simple thing to encapsulate in a language such as Java.Caspernoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-22135656762191342152007-07-12T17:48:59.000+01:002007-07-12T17:48:59.000+01:00Now that I think of it, couldn't the annotatio...Now that I think of it, couldn't the annotation idea be implemented as a compiler extension, without being integrated into the language? I'm not super familiar with the annotation processor but if you can get access to the syntax tree then this should be possible.Matthew Hallnoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-68372826011283928352007-07-12T17:15:47.000+01:002007-07-12T17:15:47.000+01:00I like the annotation idea applied to Eugene's...I like the annotation idea applied to Eugene's idea, giving a declarative way to map ISUB=>subtract(...), IADD=>add(...), ...<br />The stack effects of the bytecode(s) in the method annotations might let you do sanity checking of which operators are okay to map to which methods.Ronnoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-78939216149649421552007-07-12T16:47:35.000+01:002007-07-12T16:47:35.000+01:00Søren, I've been bitten by the scale in equals...Søren, I've been bitten by the scale in equals comparisons too, and have similarly had to resort to compareTo() == 0 for equality.<br /><br />Although operator overloading is a source of contention, I must admit I would love to see it added to the language. Maybe we could find a middle ground, by only offering operator "aliasing," i.e. some descriptor would say "on this object or interface, invoking the + operator actually calls this add() method over here." Or maybe an annotation would do it:<br /><br />class BigDecimal {<br />__@Operator("+")<br />__public BigDecimal add(BigDecimal augend) {<br />____// ...<br />__}<br />}<br /><br />interface List {<br /> @Operator("+=")<br /> public boolean add(T e);<br />}<br /><br />Of course this means that operator overloading would be interpreted contextually (depending on the type of reference you have to the object). It also means that if you change your mind on which method should be assigned to "+", that client could would have to recompile to start using that new method.<br /><br />Hmm. On the positive side, we could finally find a use for BigDecimal.plus()!<br /><br />@Operator("+")<br />public BigDecimal plus(); // Woo hoo! Now we can support unary plus!Matthew Hallnoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-8566198815296216772007-07-12T16:31:40.000+01:002007-07-12T16:31:40.000+01:00Sounds like I touched a raw nerve, thanks for all ...Sounds like I touched a raw nerve, thanks for all the comments.<br /><br />@Eugene, I looked at your blog, and its a very clever idea :-) However, for me its still a hack around the real problems, which are OpOverload and literals.<br /><br />@Casper, @John, Looking at adding a primitive type is difficult. There are 35 bytecodes free at the moment. But a decimal primitive type would probably use most of those 35 leaving little for other changes, so I'm unconvinced that its the right solution. String isn't a primitive either, so being a literal is not connected with being a primitive.<br /><br />@Patrick, I accept that a literal could bake in BigDecimal, but what else can we do (except create a better implementation and bake that in). For OpOverload, I suspect that a new interface should be added that specifies the mathematical operations as method names. But we need self-types before that works properly.<br /><br />As for alternative implementations, thats where my 'new idea' comes in. If we had a BigDecimal factory (rather than constructors), then it could return optimised implementations based on the size of the underlying number (eg. use a long rather than a BigInteger for storage).<br /><br />@Soren, I'd forgotten equals being a pain :-)<br /><br />@Daniel, I'd forgotten that Groovy uses BD throughout. Thats one argument for keeping the existing class and working to improve access (as per groovy).<br /><br />I'm definitely thinking Literals and OpOverload is the way to go. What do people think about the 'n' suffix for 'numeric' big decimal literals?Stephen Colebournenoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-12788450714359844242007-07-12T16:19:40.000+01:002007-07-12T16:19:40.000+01:00RE: BigDecimal.plus() -- from the javadoc:
"...RE: BigDecimal.plus() -- from the javadoc:<br /><br />"This method, which simply returns this BigDecimal is included for symmetry with the unary minus method negate()."<br /><br />Symmetry? I believe the opposite of "negate" is "leave it alone." I agree with you, there was no need for symmetry here. Let's see<br /><br />BigDecimal dec = new BigDecimal(50);<br />// just to make sure!<br />dec = dec.plus();<br /><br />...yeah.Matthew Hallnoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-44527129944765572322007-07-12T14:51:15.000+01:002007-07-12T14:51:15.000+01:00see:
https://o24j.dev.java.net/
(really) small oo ...see:<br />https://o24j.dev.java.net/<br />(really) small oo API for java.mbiennoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-76548096437582435562007-07-12T14:41:20.000+01:002007-07-12T14:41:20.000+01:00True BigDecimal source is a mess. Seems like as ja...True BigDecimal source is a mess. Seems like as java Date and Calendar was developed in india, OMG.George Bushnoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-43236795201748610462007-07-12T14:00:49.000+01:002007-07-12T14:00:49.000+01:00By the way, Groovy uses BigDecimal by default for ...By the way, Groovy uses BigDecimal by default for decimal expressions.<br /><br />groovy> (1.5*2).class<br />Result: class java.math.BigDecimal<br /><br />You can also force double (or float) mode if performance is an issue:<br /><br />groovy> (1.5d*2).class<br />Result: class java.lang.Double<br /><br />BigDecimal seems to be fast enough for common operations, though. For more infos, see<br />http://groovy.codehaus.org/Groovy+BigDecimal+Math <br />http://groovy.codehaus.org/Groovy+Floating+Point+MathDaniel Lichtenbergerhttp://justfiveminutes.wordpress.com/noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-90827528040911355312007-07-12T13:33:47.000+01:002007-07-12T13:33:47.000+01:00I can't believe noone has mentioned my biggest...I can't believe noone has mentioned my biggest annoyance with BigDecimal yet: that they include scale in equals() comparisons. How silly is that? They create a class that guarantees a given mathematical number can be represented exactly, but then make it so that two instances, that represent the SAME mathematical number, can be deemed unequal simply because the scale is different? On what planet was that ever useful?? I have used BDs a lot and every time I needed to compare two BDs, I didn't care about scale. Yeah yeah, I know, I can just use compareTo() == 0 instead, but that is awkward and unnatural.<br /><br />Wrt the original proposal, I think the way to go is to add a literal notation for BDs, just like we have it for String like you suggest. Then either use general operator overloading, if that is introduced, or special-case OO for the common mathematical operations (which btw should always return a new BD instead of modifying the current - unless += syntax is added as well, that should modify the object).Søren Boisennoreply@blogger.com