bigdecimal

In Ruby 2.2.0, why does: BigDecimal.new(34.13985572755337, 9) equal 34.0 but BigDecimal.new(34.13985572755338, 9) equal 34.1398557 ? Note that I am running this on a 64 bit machine. Initialize with Strings Instead of Floats In general, you can't get reliable behavior with Floats. You're making the mistake of initializing your BigDecimals with Float values instead of String values, which introduces some imprecision right at the beginning. For example, on my 64-bit system: float1 = 34.13985572755337 float2 = 34.13985572755338 # You can use string literals here, too, if your Float can't be

Is there a really large variable type I can use in Java to store huge numbers (up to around forty digits)? long 's maximum value is 9223372036854775807, which is 19 digits -- not nearly large enough. I'm trying to create a calculator that can handle large numbers, because most nowadays can only hold an insufficient 10 digits or so, and I want want accurate calculations with numbers of a much larger magnitude EDIT Thanks for the answers. I can use BigInteger for big integers, the only limit being the computer's memory (should be sufficient). For decimals, I'll use float ^e, as @WebDaldo

A few interesting observations w.r.t equals operator on 0 and 0.0 new Double(0.0).equals(0) returns false, while new Double(0.0).equals(0.0) returns true. BigDecimal.ZERO.equals(BigDecimal.valueOf(0.0)) returns false, while BigDecimal.ZERO.equals(BigDecimal.valueOf(0)) returns true. Looks like the string comparison is being done in both the cases. Could anyone throw some light on this. Thanks. assylias BigDecimal 'equals' compares the value and the scale. If you only want to compare values (0 == 0.0) you should use compareTo: BigDecimal.ZERO.compareTo(BigDecimal.valueOf(0.0)) == 0 //true

From the Javadoc for BigDecimal : Note: care should be exercised if BigDecimal objects are used as keys in a SortedMap or elements in a SortedSet since BigDecimal 's natural ordering is inconsistent with equals . For example, if you create a HashSet and add new BigDecimal("1.0") and new BigDecimal("1.00") to it, the set will contain two elements (because the values have different scales, so are non-equal according to equals and hashCode ), but if you do the same thing with a TreeSet , the set will contain only one element, because the values compare as equal when you use compareTo . Is there

I have a BigDecimal object and i want to convert it to string. The problem is that my value got fraction and i get a huge number (in length) and i only need the original number in string for example: for BigDecimal bd = new BigDecimal(10.0001) System.out.println(bd.toString()); System.out.println(bd.toPlainString()); the output is: 10.000099999999999766941982670687139034271240234375 10.000099999999999766941982670687139034271240234375 and i need the out put to be exactly the number 10.0001 in string To get exactly 10.0001 you need to use the String constructor or valueOf (which constructs a

I'm very new to JavaScript (I come from a Java background) and I am trying to do some financial calculations with small amounts of money. My original go at this was: <script type="text/javascript"> var normBase = ("[price]").replace("$", ""); var salesBase = ("[saleprice]").replace("$", ""); var base; if (salesBase != 0) { base = salesBase; } else { base = normBase; } var per5 = (base - (base * 0.05)); var per7 = (base - (base * 0.07)); var per10 = (base - (base * 0.10)); var per15 = (base - (base * 0.15)); document.write ( '5% Off: $' + (Math.ceil(per5 * 100) / 100).toFixed(2) + '<br/>' + '7%

枚举类 在Java中，我们可以通过static final来定义常量，无论是int常量还是String常量，使用这些常量来表示一组枚举值的时候，有一个严重的问题就是，编译器无法检查每个值的合理性。为了让编译器能自动检查某个值在枚举的集合内，并且，不同用途的枚举需要不同的类型来标记，不能混用，我们可以使用enum来定义枚举类。 public class Main { public static void main(String[] args) { Weekday day = Weekday.SUN; if (day == Weekday.SAT || day == Weekday.SUN) { System.out.println("Work at home!"); } else { System.out.println("Work at office!"); } } } enum Weekday { SUN, MON, TUE, WED, THU, FRI, SAT; } 定义枚举类是通过关键字enum实现的，只需依次列出枚举的常量名。 和int定义的常量相比，enum常量本身带有类型信息，即Weekday.SUN类型是Weekday，编译器会自动检查出类型错误，而且不同类型的枚举不能互相比较或者赋值，也不可能引用到非枚举的值。 enum的比较

setScale(1)表示保留一位小数，默认用四舍五入方式 setScale(1,BigDecimal.ROUND_DOWN)直接删除多余的小数位，如2.35会变成2.3 setScale(1,BigDecimal.ROUND_UP)进位处理，2.35变成2.4 setScale(1,BigDecimal.ROUND_HALF_UP)四舍五入，2.35变成2.4 setScale(1,BigDecimal.ROUND_HALF_DOWN)四舍五入，2.35变成2.3，如果是5则向下舍 来源： https://www.cnblogs.com/dongjiang/p/11413900.html

Controller **@ApiOperation(value = "导出询价但详情") @RequestMapping(name = "导出询价但详情", value = {"/download"}, method = RequestMethod.GET) public void download(HttpServletResponse res, @RequestParam(value = "inquiryCode", required = false) String inquiryCode, @RequestParam(value = "customerCode", required = false) String customerCode, @RequestParam(value = "status", required = false) String status) throws IOException { String fileName = "Inquiry" + System.currentTimeMillis() + ".xls"; String[] headers = {"询价单编号", "客户编号", "始发国家", "始发仓库", "询价单状态", "是否带电", "重", "长", "宽", "高", "收件人", "收件人公司", "收件人国家",

I have a BigDecimal defined like this: private static final BigDecimal sd = new BigDecimal(0.7d); if i print it, i get the value: 0.6999999999999999555910790149937383830547332763671875 which causes some wrong calculations. Does anyone know a way to get the exact value of 0.7 as BigDecimal ? Change it to 0.71 would view the right result, but it shouldn't be like that Use a String literal: private static final BigDecimal sd = new BigDecimal("0.7"); If you use a double , actually public BigDecimal(double val) is called. The reason you do not get 0.7 is that it cannot be exactly represented by a