# Ticket #1653 (closed feature: moved)

## Add BigInteger and BigDecimal numerical types

Reported by: | curtis | Owned by: | curtis |
---|---|---|---|

Priority: | major | Milestone: | imagej2-b8-analysis |

Component: | ImgLib2 | Version: | |

Severity: | non-issue | Keywords: | |

Cc: | Blocked By: | ||

Blocking: |

### Description

The ImgLib2 library has type-agnostic support for numerical data processing. As such, it would be great to have numerical types based on Java's `BigInteger` and `BigDecimal`, for arbitrary-precision integer- and real-valued numbers, respectively.

Implementing this feature will first require the types to exist within ImgLib2. Then we will need to write additional converter plugins (for the Image > Type menu) as well as ensure that ImageJ2's core numerical commands are well-tested with the new types. Right now, many plugins "cheat" by operating on doubles, which would defeat the purpose of the new types.

## Change History

### comment:2 Changed 7 years ago by bdezonia

Some work towards this is done on the data-types branch including Image > Type > Change plugin and BigInteger and BigDecimal backed types (in imagej packages not imglib). See also ticket #1702.

### comment:3 Changed 7 years ago by bdezonia

The two "big" DataTypes in the data-types branch have a current limitation that makes them unusable by IJ2. IJ2 expects Datasets to support RealType and NativeType. The two types can fake RealType (through narrowing data manipulations of doubles and longs) but they can't fake NativeType. We need to eliminate the NativeType requirement of Dataset.

### comment:4 Changed 7 years ago by bdezonia

Also note as part of merging #1702 to master I commented out the @Plugin annotation to the four as yet unsupportable DataTypes (the two complex types and the two unbounded types). When we are ready to support these classes simply reenable the @Plugin annotation in each of these DataTypes and they will be discovered by NewImage and TypeChanger. Of course we need to make changes to IJ2 to allow Datasets of these types to be constructed.

### comment:5 Changed 7 years ago by bdezonia

A BigDecimal backed type cannot be implemented in a naive way. Take an BigDecimal and divide by 3. An exception is thrown due to repeating decimal expansion.

Our "unlimited" decimal precision class will likely need to be a fixed point representation with some number of decimal places supported (i.e. like 50) rather than BigDecimal backed.

This is already true of the implementation for sqrt() and atan2(). And more if we add other floating operations.

### comment:6 Changed 7 years ago by curtis

Our "unlimited" decimal precision class will likely need to be a fixed point representation

Indeed. Perhaps we can have ImageJ prompt the user for the number of significant digits of precision, when converting to that type. This would be a great feature.

### comment:7 Changed 7 years ago by bdezonia

With commit 331ddf635c0bebe61d51bab1859620bb1fe0ef1e we have a basic fixed point class in place for later use. It needs to be extended to support Imglib's FloatingType when that code is merged to master. Number of decimal places is fixed at 25 places but could be extended to be configurable.

**Note:**See TracTickets for help on using tickets.

In order to avoid working in doubles we'll also have to provide methods of calculation of basic math functions (like Math.sin(), Math.exp(), Math.log()). This was part of what the types-experiment branch of imglib2 was investigating.