Early Draft
Werner Keil
Jean-Marie Dautelle
--
You received this message because you are subscribed to the Google Groups "units-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to units-dev+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Werner Keil
Am Mittwoch, 26. November 2014 19:53:02 UTC+1 schrieb Jean-Marie Dautelle:
Hi Werner and All,I am fine with this early draft (it is very close to latest JSR-275 work). I am not sure we should keep the QuantityFactory and spi package in the API though (too implementation dependent).Cheers,Jean-Marie.
On Wed, Nov 26, 2014 at 4:56 PM, Werner Keil wrote:
Hi,JSR 363 is soon about to publish Early Draft.Please have a look at the Spec on Google Docs: https://docs.google.com/document/d/12KhosAFriGCczBs6gwtJJDfg_QlANT92_lhxUWO2gCYFeedback is welcome either here on the mailing list or for those of you with java.net account feel free to use JIRA.Cheers,Werner
--
You received this message because you are subscribed to the Google Groups "units-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to units-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Werner Keil
It's possible I'm way too late with this suggestion (and it may have
been beaten to death in discussions I didn't see), but I think it could
be very useful to have more introspective access into a UnitConverter.
An example use would be: on a full environment with Java and a
comprehensive unit database, select any two obscure units and
construct a UnitConverter between them, then let some application-
supplied code-generator visitor be sent down the resulting UnitConverter
and its children, emitting custom code to perform that conversion on
some much more constrained device.
Doing this nicely would probably entail some attempt to enumerate what
basic kinds of UnitConverter may exist. My guess is there probably are
not very many. Two kinds are already treated specially with the
isIdentity() and isLinear() methods, but I could imagine a structure like:
interface UnitConverter {
interface Polynomial extends UnitConverter { getCoefficients(); }
interface Linear extends Polynomial { getSlope(); getIntercept(); }
interface Log extends UnitConverter { getBase(); }
interface Exp extends UnitConverter { getBase(); }
interface Rational extends UnitConverter {
UnitConverter getDividend(); UnitConverter getDivisor();
}
}
Am I crazy in thinking a small set like that would cover a large
fraction of UnitConverters in practice? Weird things like currencies
might not fit the scheme, so they might not implement any of the more
specific subinterfaces, and not be easily rendered into code for another
environment.
With the current API, if you get a converter and its isLinear() returns
true, you could pump two values through it and determine what it is, but
that's a little hackish and could get you an approximate result.
Another subinterface that might be of interest could be:
interface Inexact extends UnitConverter {
getRelativeError();
getDomainMin();
getDomainMax();
}
... for a converter that is known not to be using an exact conversion, but
has a known relative error for inputs in a certain range. So a converter
from km to [mi_i] could be linear with slope 15625/25146 exactly, or the
often-used approximate slope 5/8 with getRelativeError() returning 6e-3...
Chapman Flack
Martin Desruisseaux
Hello Werner
Please have a look at the Spec on Google Docs: https://docs.google.com/document/d/12KhosAFriGCczBs6gwtJJDfg_QlANT92_lhxUWO2gCY
Sorry for being so late. I just had a look and the
specification, and it looks okay. I fixed some formatting but
otherwise did not edited the content. Below are my comments
about the content:
Page 8 - Objective
The three last bullets at the bottom of the page (about
concrete classes) are not part of the specification, but rather
of the reference implementation. I suggest to either omit them,
or insert a line before them saying "The reference
implementation includes:".
Page 9 - Aspirations
First bullet ("Small or no runtime overhead compared with an
implementation not using Unit-API") is not true: there is
a huge overhead in using arithmetic operations on Quantity
compared to double primitive type. I suggest to either
remove that bullet, or explain that it may be true only when
using UnitConverter directly, not Quantity.
Page 12 - Online-shop
Paragraph contains "decimal point number" words. Do you
mean "floating point number", or maybe "decimal number"?
Page 12 - Internet of Things
Where the picture come from? Do we have the right to insert it
in our document (does the picture has a license)?
Could the Medical & Healthcare and Quantified Self use cases give actual examples of units or quantities?
I wonder if the following sentence should be rephrased? In
particular starting with something else the "See", avoiding
acronyms not defined in the specification. I'm also do not quite
understand what is a "connected scale".
See a few personal health devices from “Smart Pill Boxes” (knowing the dosage a patient needs based on their EHR) to connected scales, blood pressure, heartbeat or sugar sensors.
Page 16 - code example
I don't think that Vector should implement Quantity.
It could have implemented Measurement if we had kept
that interface, but not Quantity if we understand it
as a scalar measurement. I suggest to replace the first line by:
public class Vector<Q extends Quantity> {
I have not yet finished. Will continue the review a little bit
later...
Martin
Werner Keil
Martin Desruisseaux
Thanks for the reply. I will apply the agreed modifications later today, and will post an other email for the remaining of the spec. Sorry for being so late, I have been busy all last week with an other Open Geospatial Consortium meeting.
Le 13/12/14 03:40, Werner Keil a écrit :
Do sentence do not specify under which circumstances there is no overhead. The vast majority of developers use the double primitive types, for which there is a huge overhead. Furthermore even in the case of BigDecimal, we still have the cost of checking the unit, potentially applying conversion or unit multiplication.
So this sentence rather looks like false advertisement - I don't think that we can honestly keep it.
Martin
Martin Desruisseaux
Hello Werner, Frank and all
Answers below, separated in 3 sections (types, coefficients and
errors):
On unit conversion types
I agree with Frank that some way to get the formulas used by a UnitConverter
may be useful. The interfaces proposed by Frank could work, but it
may be a little bit late for introducing them. Furthermore
defining those interfaces may expose more implementation details
than desired:
- An implementation could choose to implement logbase(x) as ln(x)/ln(base).
- An other implementation could choose to implement logbase(x) as the concatenation of ln(x) with a linear conversion.
If we provide the proposed UnitConverter
sub-interfaces, it would make the above implementation choices
more visible.
A partial alternative could be to replace the isIdentity()
and isLinear() methods by a single getConversionType()
method which would returns one of the following enum values:
enum ConversionType {IDENTITY, LINEAR, LOGARITHMIC, EXPONENTIAL, OTHER}
I think the identity, linear, logarithmic and exponential cases
cover almost all unit conversions in SI and imperial system,
except conversions of sexagesimal degrees to decimal degrees.
Admittedly this enum proposal does not provide the function
coefficients.
On unit conversion coefficients
On Frank's point about the difficulty to get the coefficients of
the underlying conversion (current API leads to approximative
values), I agree with him. I proposed a while ago the following
methods in UnitConverter:
/** * Returns the derivative of this conversion function at the given value. * Note that for a linear conversion, the derivative is the slope and is the same for all x values. */ double derivative(double x);
Derivatives are really needed for advanced users. For those who
are not so comfortable with mathematics, at least this method
allow them to get the slope of a linear function, which meets part
(admittedly not all) of Frank's request.
On unit conversion errors
If we take inspiration from ISO 19111 (coordinate operations)
terminology, a conversion is by definition exact to the accuracy
allowed by floating point operations. An operation with known
errors (not due to floating point rounding errors) is called transformation,
and I think is out of scope of JSR-363 since there is many kinds
of such errors. Furthermore, unit conversions are often exact by
definition. For example the conversion factor from inches to
centimetres is 2.54 by definition, so I don't think that
we need (or should) handle the case of approximative
transformations. I would rather said in the specification that
implementations shall use the official definitions with all the
accuracy given by the standard body.
Martin
Werner Keil
Werner Keil
Werner Keil
Werner Keil
Jean-Marie Dautelle
--
You received this message because you are subscribed to the Google Groups "Units Developers" group.
Werner Keil
Am Sonntag, 12. August 2018 14:39:09 UTC+2 schrieb Jean-Marie Dautelle:
Hi Werner and All,It looks good, but is there a way to identify what has changed from version 1.0 (e.g. font color different).This would be useful for people who already know v 1.0 and want only look at the changes.Thanks,Jean-Marie
Martin Desruisseaux
> I cannot say, if Google Docs has this kind of feature?
> Has someone seen such a "diff" or used it?
alternatively, an annex listing the changes.
Martin
Werner Keil
Werner Keil
Martin Desruisseaux
Hello Werner
Sorry if my question is trivial. Could we summarize the situation please?
- Could you remind us what is EDR?
- What is final for this EDR; is it the Java classes for the API, or the implementation?
- Can we have a summary of what has changed in the specification document compared to JSR-363?
Thanks
Martin
