The latest units/quantities packages (for JScience 3.0) has been submitted to the JSR-275 expert group for review. It provides compile time check of quantities consistency through parameterization. For example, by treating mass as an interface, programs specifically request mass in kilograms instead of assuming the unit type.

An example from the javax.quantities package documentation shows a potential "setWeight(double weight)" method call, which doesn't specify clearly what the weight unit is, whether it's pounds or kilograms. With javax.quantities, the method call would change to "setWeight(Quantity<Mass> weight)" and the weight would be accessible by specific unit:

double weightInKg = weight.doubleValue(SI.KILOGRAM);
double weightInLb = weight.doubleValue(NonSI.POUND);

You can browse the proposed API on the web site. There are two packages in the library: javax.quantities and javax.units.

JScience has made the pre-release implementation sources and a binary available on their web site.

All references in the site says JDK 5, does it work with previous versions?

All references in the site says JDK 5, does it work with previous versions?

JDK 5 is required but I think Retroweaver will come to your rescue (at least if you are using JDK 1.4...)

/Tommy
VisionProject
Issue tracking and project management made easy

I understand that this is a "how long is a piece of string" question, but what are the likely timescales for (1) JSR-275 being accepted/rejected, and (2) the code being in the JSE distribution.

I do understand that the code can be used without either of those two conditions being met. That might well be an acceptable alternative.

Hopefully JSR acceptance can be reached before the end of 2006 and the JSR incorporated to Dolphin (1.7).

I find it very interesting that at this stage in java's development there is simultaneously one group of people who argue for more dynamic typing than java has to offer (such as bruce tate in "beyond java") and another group of people (such as the creators of JScience) who really push the limits of what can be enforced through static typing.

To me JScience's approach seems very logical and rigorous, although the result is probably more complex than many would like.

The difference between these groups might just be, that JScience deals with a domain that contains concepts which come close to "universal truths" - which can indeed be statically enforced: there is just not much dynamism in e.g. the definition of Complex and Real numbers, or the physical units that make up the SI system, or what Temperature and Time are all about.

I wonder if proponents of dynamic typing think that JScience should do away with all that static typing rigor?!

  just an observation,
  gerald

http://www.gerald-loeffler.net

I wonder if proponents of dynamic typing think that JScience should do away with all that static typing rigor?!

Neither mathematical proofs nor science have ever needed dynamic types. Dynamic typing is something that appeared centuries after math and science and is used primarily as a convenience (that isn't epistemologically enabling). The analytical value of mathematical closures depends on static typing. In high school chemistry and physics the static tracking of units during algabreic conversions is the first impression the teacher must make. The formulas of thermodynamics (eg, ideal gas law) only make sense when units are tracked. Stoichiometry, the essence of chemistry, depends on the static and trackable categorization of atomic elements. It's absurd to suggest a rival to static typing in quantitative science.

It's absurd to suggest a rival to static typing in quantitative science.

No it's not. Embedding units so deeply into the type information (I'm ignoring the static vs dynamic language debate) makes it so that all the different types of units and their conversions need to be known at compile time.

This is pretty bad, because it would be pretty easy to make units runtime configurable and make your code much more flexible.

It really depends on your target. If you've already worked out all the math, and it's just time to code it, then staticly typing the units would be useful because the compiler double-checks your typing. I'd say if my life is dependent on accurate calculations I'd like the code to be statically typed, or if the performance requirements are so strict that runtime checking imposes too much overhead.

But if you need to do any sort of exploratory development, or are building a flexible system, then I think runtime checking along with thorough automated testing would be almost as good. If your code throws exceptions in a fail-fast way whenever an invalid operation is attempted (according to configurable rules), and you have a good test suite, then the likelyhood of invalid unit conversions escaping the testing process is fairly low.

It's absurd to suggest a rival to static typing in quantitative science.

No it's not. Embedding units so deeply into the type information (I'm ignoring the static vs dynamic language debate) makes it so that all the different types of units and their conversions need to be known at compile time.

The issue is the degree of enforcement of type rules (i.e., type safety) at compile-time vs. runtime. The point is not whether a framework (for computational science or otherwise) should be strongly or weakly typed - the point is how statically should the type rules be enforced. For instance, the statement

  S = V*T

must ultimately (at runtime) only succeed if e.g.
  - S is of type length
  - V is of type velocity
  - T is of type time
  - the units of S, V and T are compatible (e.g., m, m/s, and s, respectively).

That's hopefully beyond dispute ;-)

The question is whether the above statement should cause a compile time error if S, V and T
  1. are not of the correct types *and* units,
  2. or whether only the types and not the units are enforced at compile time,
  3. and what happens if the unit of T is not known until runtime and turns out to be ms instead of s? Will then the result S incorporate the factor 1000 although it did not appear in the statement?

And the point i was *actually* trying to raise in my original posting is this: in the case of computational science it seems pretty clear that one benefits from static type safety (as long as case 3. from above can be handled), because velocity*time is always and will always be of type length. So what is it that makes dynamic typing apparently so desirable in other domains? Is it just the need for compile-time tolerance to inexactness in typing? Is it just that for other, less "eternal" domains than science, we can not afford the effort to enforce type safety with the same rigor? Or is there some other factor that i do not see?

  cheers,
  gerald

http://www.gerald-loeffler.net

Embedding units so deeply into the type information (I'm ignoring the static vs dynamic language debate) makes it so that all the different types of units and their conversions need to be known at compile time.

You don't need dynamic typing to use conversions introduced in the wild. You do need static typing if you want the the bogus assignment of an inch to a dollar warned at build time.

If your code throws exceptions in a fail-fast way whenever an invalid operation is attempted (according to configurable rules), and you have a good test suite, then the likelyhood of invalid unit conversions escaping the testing process is fairly low.

I also espouse fail-fast, but it takes more developer bandwidth than static checking. I major goal of mine is reducing demand for development.

You don't need dynamic typing to use conversions introduced in the wild.

Hence why I said I was ignoring the static vs dynamic typing debate for this discussion.

I also espouse fail-fast, but it takes more developer bandwidth than static checking.

Personally, I consider static checking a "really fast" form of fail-fast. What can be faster than failing at compile time? I think it's more productive to think of it as a gradient: compile (+ additional static analysis) -> automated unit test -> application startup -> automated testing -> fail-fast runtime checks -> manual testing

If you think about it this way, you realize that what you need to do is place checks where they are most effective. Spending days designing your classes so that the compiler can effectively validate your code is a waste if the same thing could be accomplishing by spending a few hours writing test cases, and vice-versa. Put the checks where they are most and effective and can be most efficiently placed.

I major goal of mine is reducing demand for development.

I don't think you mean that. You mean reduce the demand for people who's primary expertise if programming by (1) increasing the productivity of programmers and (2) making development more accessible to domain experts, thereby making programmers less needed.

Personally, my goal is to increase the demand for development (i.e. make the market bigger) by increasing the complexity of non-technical problems that can be successfully solved via software.

The goal is to increase the value of what can be delivered; increased productivity and shifting focus off of the program and onto solving the problem are simply parts of achieving that goal.

I think you've confusing the idea with the thing here.

While it's obviously correct that the laws are not dynamically typed, it's not true that they are statically typed either. The concepts of type and unit are human constructs designed into the *theory* to make it possible to manipulate the numbers, which are abstract, unit/type-less beasts that have been taunting mathematicians for millenia. "Natural philosophy" (aka science) applies (sure, argue endlessly about this verb...) mathematics to nature, at which point unit/type issues are unavoidable.

But it is not properly part of nature, simply an artifact of how we apply number to nature.

Which leaves as an open question what the relationship of a given programming language should do on the question, especially since we're talking about the application of a general purpose language to a specialized use, scientific computing.

I personally suspect that this a case where there is not correct solution and the solution is finding a wise balance, and I notice that the orignal post on this thread smartly questioned rather than answered. Unfortunately, I suspect the answer to the raised question, is "no", type is indeed extricably part of any useful model.

I'm deeply skeptical of the proposal, as it introduces a subtle domain-issue into general purpose programming and will likely cause more trouble than it will solve. But I would love to be proven wrong.

The concepts of type and unit are human constructs designed into the *theory* to make it possible to manipulate the numbers, which are abstract, unit/type-less beasts...

Dude, have you ever heard of mathematical domain theory? You're violating it.

All scales are arbitrary human impositions, but ranges are not arbitrary (Eg, absolute zero temperature is a natural range limit). Nature may be unitless, but certainly not typeless. It's easier to explain natural typing with discrete math rather than continuous math. Stereochemistry is a natural form of discrete binary typing. But continuous math is also naturally typed. Length, area, and volume are all spatial qualities, but they are never substitutes for eachother. Naturally they are strongly typed (ie, not always interchangeable).

Granted, you can convert to and from BigDecimal to use these APIs, but wouldn't an internal use of BigDecimal, along with appropriate getters and setters, provide for a more accurate and flexible representation?

JScience 3.0 (to be released in a couple of weeks) will provide several useful quantity implementation the most useful might be:<code>
   class Measure<Q extends Quantity> extends Real implements Quantity<Q> { ... }
</code>
Note: JScience Real is similar to BigDecimal but easier to use (e.g. error guaranteed even when division are performed).

Just in case if someone care to look at different implementation of quantity math framework. Here is a link: http://sourceforge.net/projects/quantitymanager

Best Regards,

Alex

I don't think we need it as a part of JDK. JDK has already too much of APIs. This library could easily stay as a standalone library with no problems.

I worked on this kind of project 10 years ago. I have used C and Yacc to define a scriping language for Matrix Operations (ex. Matrix mulplication, Transform, reverse etc.) and Engineering analysis.

Due to the nature of the these units, one only needs defines the basic units, and the rest of units will all come together.

All the units can be defined as

units = [Length]^a . [Mass]^b . [Time]^c . [Temp]^d

where a, b, c, d are different powers. For example, if unit is length, then b = c = d = 0. and a = 1. if the Unit is Area, a =2, b =c = d = 0; and If the unit is velocity: a = 1, b = 0, c = -1, d = 0.

You can find more about the unit at
http://www.isr.umd.edu/~austin/aladdin.d/quantity-defn.html


The complete report in PDF format is at
http%3A//www.isr.umd.edu/%7Eaustin/aladdin.d/report95-74.pdf&ei=-iDNQ9imJ6CaYPGTsOwL&sig2=ABnmKBayiNqyx4rqAWIqhQ

The complete project
http://www.isr.umd.edu/~austin/aladdin.html#sec3

The code is free to download.





Chester Chen

Oopsie, what happened to good ol'
[electric current],
[amount of substance] and
[luminous intensity]?

Hilmar

I worked on this kind of project 10 years ago. I have used C and Yacc to define a scriping language for Matrix Operations (ex. Matrix mulplication, Transform, reverse etc.) and Engineering analysis. Due to the nature of the these units, one only needs defines the basic units, and the rest of units will all come together. All the units can be defined as units = [Length]^a . [Mass]^b . [Time]^c . [Temp]^dwhere a, b, c, d are different powers.

With a complete set of units, that is sufficient.
However, if you are to capture the mindset of, say, practicing electronic engineers, you will need simple intuitive, efficient ways for them to express things they use in everyday life, e.g. Henries, Amps, Coulombs, lux, steradians etc. I would have would not put up with the pain of expressing Henries in terms of the fundamental units.

<quote>
 
With a complete set of units, that is sufficient.
However, if you are to capture the mindset of, say, practicing electronic engineers, you will need simple intuitive, efficient ways for them to express things they use in everyday life, e.g. Henries, Amps, Coulombs, lux, steradians etc. I would have would not put up with the pain of expressing Henries in terms of the fundamental units.
</quote>

That's true, we did provide the ready to use units for energy and force etc. The basic units I illustrated ealier is internal to the Aladdin System.

But since Aladdin is mainly developed for Structural Engineering, the units for Electrical Engineering were not there.

Chester