7Units/src/test/java, branch v1.0.0b2

Ensure LinearUnit&Prefix ==/hash obey contracts

2025-05-31T01:30:44Z

Previously, these classes' equals() and hashCode() methods did not obey the contracts: For equals(), I considered two values equal even if there was a very small deviation, in order to avoid floating-point error. This equals relation is not transitive (i.e. it is possible that a = b && b = c but a ≠ c), violating the contract of equals. This also makes it impossible to properly implement hashCode, as if two values are equal, they must have the same hash code. The solution I had provided is an ineffective hack, which could mess with hash maps and sets. I have changed the implementation to demand exact equality. I have also provided equalsApproximately() methods to both classes that use the old behaviour. Hash codes are only really used for hash maps, and the old implementation doesn't even achieve its purpose, so I did not add a method to return the old hash behaviour.

Allow prefix search toString to be in any order

2025-05-31T01:01:53Z

The order will be determined by hashes, but it doesn't matter which one goes where.

Remove Unitlike/MultiUnit

2025-05-31T00:54:19Z

I ended up never using this code - it was simpler to just use lists of units and values. Making a whole new object for lists of units, and an abstract class for things that convert things other than doubles, is needlessly complicated, and doesn't solve any major issues. For example, I still need to store each Unitlike type in a different collection, because it will have a different type.

ExpressionParser: use correct operand order

2025-05-31T00:54:17Z

Most of the internal problems with the expression parser happened because I was accepting the arguments for binary operators in the wrong order. For example, '2 - 1' became '1 2 -', not '2 1 -'. The likely cause of this error is the following sequence of events: - In commit 6dbd32cd, I created the code for interpreting RPN. I accepted two arguments from the stack (o1 and o2), then performed o1 o2. However, because stacks are in LIFO order, I should have actually done o2 o1. - Later, in commit 94349688, I created the code for converting an infix expression to RPN. Creating the expressions in the correct order did not work, because my interpreter used the incorrect order. To 'fix' this problem, I created the expressions in the incorrect order. I did not notice any discrepancy, probably because I was not testing the individual methods, only the two-step whole (which found no errors).

Add tests for submethods of ExpressionParser

2025-05-21T23:20:44Z

These tests fail right now, because ExpressionParser has a bug. They should help me fix it.

Add tests for Presenter

2025-05-10T02:20:00Z

Add more UnitDatabase tests

2025-04-30T21:42:01Z

Add tests for NameSymbol

2025-03-21T20:26:01Z

Add tests for LinearUnitValue

2025-03-07T16:47:53Z

I specifically added tests for the methods that Jacoco says haven't been tested: - convertToMultiple - equals - equivalent - hashCode - operation methods

Allow default datafile to be disabled

2025-02-24T01:36:03Z

If this option is deselected, the default unit, prefix, dimension and metric exception data will not be loaded, and only custom data and the few units that are not provided by files will be available. The main rationale for this change is so that the data can be localized by custom unit files.