7Units/src/main/java/sevenUnits, branch v1.0.0b2

Bump version to 1.0.0b2

2025-05-31T01:31:09Z

All that's left before 1.0.0 is released is the documentation fixes. Unless I find any major issues, 7Units 1.0.0 releases June 8.

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.

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.

Throw error on expressions with too many operators

2025-05-31T00:54:18Z

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).

Setup automated javadoc

2025-05-18T04:03:29Z

./gradlew javadoc

Add more UnitDatabase tests

2025-04-30T21:42:01Z

Improve Metric base units SuppressWarnings message

2025-04-20T23:23:31Z

Add tests for NameSymbol

2025-03-21T20:26:01Z

convertToMulti: Compare unit bases to this.base

2025-03-07T16:48:10Z

This is a necessary precondition for the conversion methods used later on in convertToMutliple, and it is simpler than the existing method. I can also be sure it works, due to the tests I just wrote.