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