Hi,
You are right: If I display directly the (Double) results from cell.getValue(), I will have the correct display.
In fact, the problem occured when I tried to transform those doubles into Big Decimals. I used the constructor BigDecimal(double) without specifying a MathContext. On the other hand, if I provide MathContext.DECIMAL64, the result appears OK.
By the way, this is the reason why in your test case, the first result was not exact: you were using constructor BigDecimal(double) instead of BigDecimal(String) or BigDecimal(double, MathContext).
However, the conversion from double to big decimal does not trigger the precision loss, but in fact it simply reveals it (as far as I understand the java spec). Consequently, if Aspose uses double internally (which I understand perfectly: it is java's standard !), there may be some precision loss. I can mask part of it when converting back to BigDecimal, but I am never sure of the precision of my result.
I will continue the analysis of the tool with *real* test cases and see wether this has an impact on my application. Thank you very much for your help.
------------------------------------------------------------------------
New test case:
Workbook book = new Workbook();
Cells cells = book.getWorksheets().getSheet(0).getCells();
Cell cell = cells.getCell("A1");
cell.setValue(new BigDecimal("380.2"));
System.out.println("Input Cell value as double: " + cell.getValue());
System.out.println("Input Cell value as Big Decimal: " + new BigDecimal(((Double)cell.getValue()).doubleValue()));
System.out.println("Input Cell value as Big Decimal/MathContext: " + new BigDecimal(((Double)cell.getValue()).doubleValue(), MathContext.DECIMAL64));
Will give the following output:
Input Cell value as double: 380.2
Input Cell value as Big Decimal: 380.19999999999998863131622783839702606201171875
Input Cell value as Big Decimal/MathContext: 380.2000000000000