Home » Eclipse Projects » UOMo » uomo in structural engineering project
uomo in structural engineering project [message #670398] |
Fri, 13 May 2011 20:51 |
Eclipse User |
|
|
|
Originally posted by: Luca Salvatori
Dear All,
I saw that the class org.eclipse.uomo.units.NonSI and the Unit constants
in it are not public (unlike the classes SI and USCustomary and their
constants, in the same package).
I am wondering whether this is intentional and the class is not for
direct use. The class header says it is an "internal collection ..." but
I do not understand how the user is supposed to access the units defined
in it.
Kind regards,
Luca
|
|
|
Re: uomo in structural engineering project [message #670851 is a reply to message #670398] |
Sun, 15 May 2011 22:01 |
Werner Keil Messages: 1087 Registered: July 2009 |
Senior Member |
|
|
Dear Luca,
Thanks a lot for raising the question and exploration use cases for UOMo in your structural engineering project.
The org.eclipse.uomo.units.NonSI class was taken from the earlier (JSR) implementation, Jean-Marie, myself and others had worked on.
It was pointed out by people at Google and others providing input, that this SystemOfUnits may not have the most lucky name, and seem a bit like "dump" for all kinds of units that don't fit into other categories. Thus USCustomary was created which you may notice, contains certain units for the US context, which NonSI has similar UK counterparts for.
I'm open to constructive suggestions for a new Out of The Box system similar to SI or USCustomary. Considering it is final at the moment like all other unit systems, I agree, its members are pretty much for internal usage only.
An alternative to creating further (final) default unit systems would be to move the elements into org.eclipse.uomo.units.AbstractSystemOfUnits making them abstract and thus only available for implementing unit systems.
This would also allow usage by custom-specific unit systems, i.E. if you find such need in your project or other use cases.
Kind Regards,
Werner
|
|
|
Re: uomo in structural engineering project [message #671220 is a reply to message #670851] |
Tue, 17 May 2011 07:24 |
Eclipse User |
|
|
|
Originally posted by: Luca Salvatori
Dear Werner,
thanks for you reply.
On 16/05/2011 00:01, Werner Keil wrote:
> Dear Luca,
>
> Thanks a lot for raising the question and exploration use
> cases for UOMo in your structural engineering project.
>
> The org.eclipse.uomo.units.NonSI class was taken from the
> earlier (JSR) implementation, Jean-Marie, myself and others
> had worked on.
> It was pointed out by people at Google and others providing
> input, that this SystemOfUnits may not have the most lucky
> name, and seem a bit like "dump" for all kinds of units
> that don't fit into other categories.
I provide some more details on what I am doing, hoping that the
description of an usage-attempt be useful.
While exploring uomo, I needed some units already defined in NonSI (e.g.
kilogram-force). Then I tried adding new units useful for my project.
Indeed, I started treating NonSI exactly as you wrote: I put all new
units in it (and upgraded the class and its constants to public, for the
sake of my tests).
Units I had to add for my structural engineering project are those still
used by some practitioner engineers, for example, the metric-tonn-force,
or the metric-technical-unit-of-mass (the mass which accelerated by 1m/s
results in a kgf). I think that these units might be common also in
other European countries besides Italy and deserve to be added somewhere
instead than being redefined by users (such as me).
Whether these units belong to a clearly nameable set, I am not sure. If
it was for Italy, I would put them in an EngineeringCustomary or
something similar. On the other hand, they may be happy to stay in
NonSI, with their friends kilogram-force, etc.
I agree that NonSI is quite vague and wide. Maybe some units should be
moved to an UK specific set, and other to a "SIAffine" set, in which I
would put units which are non-SI but whose definition is dependent on SI
(e.g. kilogram-force, metric ton, angstrom, and those that I defined above).
BTW, I also added some units, which, I assumed, are common in US
engineering practice, such as kilopound (kip) and kilopound-force
(kipf). The assumption is due to the fact that they are present in every
US engineering program I checked. These units might be at home in
USCustomary, but I am not in the (geographic) position to assert that.
> Thus USCustomary was
> created which you may notice, contains certain units for
> the US context, which NonSI has similar UK counterparts
> for. I'm open to constructive suggestions for a new Out of The
> Box system similar to SI or USCustomary. Considering it is
> final at the moment like all other unit systems, I agree,
> its members are pretty much for internal usage only.
>
> An alternative to creating further (final) default unit
> systems would be to move the elements into
> org.eclipse.uomo.units.AbstractSystemOfUnits making them
> abstract and thus only available for implementing unit
> systems.
This sound interesting too. However, my first temptation when seeing a
class named AbstractSystemOfUnits would be to derive from it (as it is
currently done in uomo). This would end-up in having all units available
in concrete sub-classes and this might create some confusion.
>
> This would also allow usage by custom-specific unit systems,
> i.E. if you find such need in your project or other use
> cases.
>
> Kind Regards,
> Werner
Kind regards,
Luca
|
|
|
Re: uomo in structural engineering project [message #674438 is a reply to message #670851] |
Thu, 26 May 2011 22:27 |
Eclipse User |
|
|
|
Originally posted by: Luca Salvatori
Dear Werner,
I try and keep the discussion alive (see previous post in this tread,
also quoted below):
- I have noticed that some non-SI units (both in NonSI and in
USCustomary) lack of symbol in messages.properties (e.g., inch, pound,
pound-force, metric-ton), some other unit symbols in the same file have
been commented. I do not see the reason (I had to add the first group
and uncomment the second group for my test to work.
- How does UOMo relate to JScience? You mentioned J.M. Dautelle, who
seems now active in JScience. Are the two projects still connected
somehow (besides using the same API)?
Best wishes,
Luca
--
Dear Werner,
thanks for you reply.
On 16/05/2011 00:01, Werner Keil wrote:
> Dear Luca,
>
> Thanks a lot for raising the question and exploration use
> cases for UOMo in your structural engineering project.
>
> The org.eclipse.uomo.units.NonSI class was taken from the
> earlier (JSR) implementation, Jean-Marie, myself and others
> had worked on.
> It was pointed out by people at Google and others providing
> input, that this SystemOfUnits may not have the most lucky
> name, and seem a bit like "dump" for all kinds of units
> that don't fit into other categories.
I provide some more details on what I am doing, hoping that the
description of an usage-attempt be useful.
While exploring uomo, I needed some units already defined in NonSI (e.g.
kilogram-force). Then I tried adding new units useful for my project.
Indeed, I started treating NonSI exactly as you wrote: I put all new
units in it (and upgraded the class and its constants to public, for the
sake of my tests).
Units I had to add for my structural engineering project are those still
used by some practitioner engineers, for example, the metric-tonn-force,
or the metric-technical-unit-of-mass (the mass which accelerated by 1
m/s results in 1 kgf). I think that these units might be common also in
other European countries besides Italy and deserve to be added somewhere
instead than being redefined by users (such as me).
Whether these units belong to a clearly nameable set, I am not sure. If
it were for Italy, I would put them in an EngineeringCustomary or
something similar. On the other hand, they may be happy to stay in
NonSI, with their friends kilogram-force, etc.
I agree that NonSI is quite vague and wide. Maybe some units should be
moved to an UK specific set, and other to a "SIAffine" set, in which I
would put units which are non-SI but whose definition is dependent on SI
(e.g. kilogram-force, metric ton, angstrom, and those that I defined above).
BTW, I also added some units, which, I assumed, are common in US
engineering practice, such as kilopound (kip) and kilopound-force
(kipf). The assumption is due to the fact that they are present in every
US engineering program I checked. These units might be at home in
USCustomary, but I am not in the (geographic) position to assert that.
> Thus USCustomary was
> created which you may notice, contains certain units for
> the US context, which NonSI has similar UK counterparts
> for. I'm open to constructive suggestions for a new Out of The
> Box system similar to SI or USCustomary. Considering it is
> final at the moment like all other unit systems, I agree,
> its members are pretty much for internal usage only.
>
> An alternative to creating further (final) default unit
> systems would be to move the elements into
> org.eclipse.uomo.units.AbstractSystemOfUnits making them
> abstract and thus only available for implementing unit
> systems.
This sound interesting too. However, my first temptation when seeing a
class named AbstractSystemOfUnits would be to derive from it (as it is
currently done in uomo). This would end-up in having all units available
in concrete sub-classes and this might create some confusion.
>
> This would also allow usage by custom-specific unit systems,
> i.E. if you find such need in your project or other use
> cases.
>
> Kind Regards,
> Werner
Kind regards,
Luca
|
|
|
Re: uomo in structural engineering project [message #674914 is a reply to message #674438] |
Sun, 29 May 2011 13:03 |
Werner Keil Messages: 1087 Registered: July 2009 |
Senior Member |
|
|
Dear Luca,
Thanks a lot for contributing to this thread and your suggestions. I'm a bit busy with IP matters regarding some other classes and libraries used, so please excuse me if I may take a bit to respond. IP looks good, the majority of items has been resolved, now all we need is the right way to use e.g. XMLPull, a library already shared on Orbit by our mentor Chris (not sure, if it was due to UOMo but thanks to him in any case)
I shared your question about the message.properties content with the Babel forum, as we're hoping to get most of these bundles imported to the Babel server soon. Especially now, that UOMo download site uses the standard servers which Babel assumes for all imports of such messages.
For most of the other suggestions, especially those around new unit systems or moving parts of NonSI to a possible new type, I think the time is right to open one or the other Bugzilla item for those tasks. Assuming you have a Bugzilla user already, please feel free to open any of these yourself. Marking them e.g. with "helpwanted" sounds good, even though project owners and active committers would do so in any case, but where let's say message bundles for Italian or further domain knowledge in your area of expertise is helpful, other people may be able to step in, too. Most of these sound primarily like Enhancement Requests, although e.g. members in NonSI not being visible to classes outside UOMo Units could be interpreted by sume as a missing feature or defect. Feel free to classify appropriately.
Kind Regards,
Werner
|
|
|
Re: uomo in structural engineering project [message #675135 is a reply to message #674914] |
Mon, 30 May 2011 11:43 |
Eclipse User |
|
|
|
Originally posted by: Luca Salvatori
On 29/05/2011 15:03, Werner Keil wrote:
> Dear Luca,
>
> Thanks a lot for contributing to this thread and your suggestions. I'm a
> bit busy with IP matters regarding some other classes and libraries
> used, so please excuse me if I may take a bit to respond. IP looks good,
> the majority of items has been resolved, now all we need is the right
> way to use e.g. XMLPull, a library already shared on Orbit by our mentor
> Chris (not sure, if it was due to UOMo but thanks to him in any case)
>
> I shared your question about the message.properties content with the
> Babel forum, as we're hoping to get most of these bundles imported to
> the Babel server soon. Especially now, that UOMo download site uses the
> standard servers which Babel assumes for all imports of such messages.
>
> For most of the other suggestions, especially those around new unit
> systems or moving parts of NonSI to a possible new type, I think the
> time is right to open one or the other Bugzilla item for those tasks.
> Assuming you have a Bugzilla user already, please feel free to open any
> of these yourself. Marking them e.g. with "helpwanted" sounds good, even
> though project owners and active committers would do so in any case, but
> where let's say message bundles for Italian or further domain knowledge
> in your area of expertise is helpful, other people may be able to step
> in, too. Most of these sound primarily like Enhancement Requests,
> although e.g. members in NonSI not being visible to classes outside UOMo
> Units could be interpreted by sume as a missing feature or defect. Feel
> free to classify appropriately.
>
> Kind Regards,
> Werner
Dear Werner,
I am not that familiar with bug report in public projects but I tried my
best.
Best wishes,
Luca
|
|
| | |
Goto Forum:
Current Time: Fri Dec 06 14:14:07 GMT 2024
Powered by FUDForum. Page generated in 0.04541 seconds
|