| Age | Commit message (Collapse) | Author |
|---|
|
This commit moves all of the expression formatting code to one method,
and changes it so that it works with things like '1e+2'. This does mean
that I had to require spaces for addition and subtraction, but without
that, the rules would be complicated.
|
|
Specifically, for every @since tag with a date, I added another that
contains the correspending version. I did not add date @since tags to
comments that do not have them, as that would be too tedious for what
it's worth. These dates could still be found by using git bisect
though.
|
|
I used the Git history for years after 2019, and only included 2019 or
2018 if they were already there. I also added copyright notices to all
code files that don't already have them.
|
|
In some cases I've used @SuppressWarnings, which Gradle doesn't seem to
respect, but I've solved all the other ones.
|
|
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.
|
|
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.
|
|
./gradlew javadoc
|
|
|
|
|
|
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.
|
|
Previously, any error in the unit or dimension file(s) crashes the
program. Instead, 7Units now ignores any invalid lines, still parsing
the correct ones, and shows a popup in case any errors happen.
|
|
This ensures that small errors from floor arithmetic will not, for
example, cause 2 feet to be converted to 1 foot + 12 in.
|
|
|
|
|
|
|
|
|
|
|
|
| is like /, but with higher precedence. This feature is a part of GNU
Units, and was included in 7Units for compatibility.
|
|
Previously, you could only exponentiate individual dimensions in
expressions. For example, `Length^3` was valid, but `(Length / Time)^2`
was not. This is now fixed.
|
|
This was added to be consistent with the data file spec, which was
changed for consistency with unit expressions. It may not be a common
expression, but it's a bit weird that you can use +/- in units but not
prefixes, even though they're in the same file!
|
|
|
|
Also fixed some bugs:
- Presenter now has default values for its settings in case they don't load properly
- UnitDatabase ensures its units, prefixes and dimensions have all of the names
you give it
|
|
|
|
|
|
|
|
(Added tests for the settings and unit/prefix viewer parts of the GUI, which are
not yet implemented)
|
|
|
|
|
|
|
|
|
|
|
|
TabbedView now displays its units, but with their toString method which shows
their definition in addition to their name
|
|
|
|
|
|
Also fixed a bug where a prefixed unit map with units but no prefixes would
appear empty
|
|
|
|
The bug: non-exact LinearUnitValue instances have their value printed as "(",
i.e. "(5.0 ± 0.1) m" will be printed as "( m"
|
|
|
|
|
|
|
|
|
|
|
