OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [ubl-dev] Representation of a measurement as a fraction


rulers (at least here) have 1/10ths and we all know that decimals are nice for representation but don't convert to binary very well.... in fact they can be as much a problem in binary as 1/3 is in decimal

numerical analysis 101

and in case you are wondering about the real world in this - discounts calculated on a line by line basis will frequently lead to rounding errors. In fact many of the invoices we have to process simply don't add up if you calculate them manually from the numbers on the page.

measurements need to allow for fractions as well as decimals to have real meaning

as a side issue allowing units to be stored as fractions and decimals or exponent base n gives the user maximum flexibility to express the number accurately, maximum opportunity for symbolic simplification (common factors etc), and maximum options for an implementer to select the best numerical method to get accurate results.

just my 2cents after 3 decades dealing with this vexing issue.

Regards
Rick

On 21/01/2010, at 12:05 AM, Stephen Green wrote:

> I gather from what Eric is saying that the CCT for
> measure will in many cases result in rounding errors.
> Foot and inch length measurements are usually not
> only presented in whole units and fraction units but
> actually the measurements are made and used this
> way so conversion is to be avoided. e.g. 1'  1 1/3"
> would result in rounding errors and ordering a piece
> of wood, say, using decimals could be a serious
> problem. I think Eric has an important issue here.
> 
> However, I wonder whether society has already made
> steps to avert this, e.g. a ruler typically does not have
> thirds or sevenths of an inch but only fractions which
> are multiples of two and so the decimal conversion is
> helped.
> 
> http://wiki.answers.com/Q/Were_is_one-third_of_an_inch_on_a_ruler
> 
> Best regards
> 
> Steve
> ---
> Stephen D Green
> 
> 
> 
> 
> 2010/1/20 G. Ken Holman <gkholman@cranesoftwrights.com>:
>> Thanks for your post, Eric.
>> 
>> At 2010-01-20 16:25 +0530, ericdes wrote:
>>> 
>>> How would you represent a measurement such as 1"1/4? I don't see anything
>>> other than to convert the value into a decimal... Am I missing something?
>> 
>> Indeed the base CCTS data type for a measurement is a decimal value and not
>> a string.  In a business document an unambiguous representation is crucial
>> to conveying the information accurately.
>> 
>> Thus, the proper *value* representation would be, for example:
>> 
>>   <cbc:Measure unitCode="INH">1.25</cbc:Measure>
>> 
>> Surely the representation as:
>> 
>>   1 1/4"
>> 
>> or
>> 
>>   1" 1/4
>> 
>> ... or any other representation is a presentation issue and not a value
>> issue.
>> 
>> Is your concern about data entry or about data presentation?  I think these
>> two areas are the only way to address your issue.  For interchange, I'm
>> confident the value must be decimal.
>> 
>> I hope this is helpful.
>> 
>> . . . . . . . . .  Ken
>> 
>> --
>> UBL and Code List training:      Copenhagen, Denmark 2010-02-08/10
>> XSLT/XQuery/XPath training after http://XMLPrague.cz 2010-03-15/19
>> XSLT/XQuery/XPath training:   San Carlos, California 2010-04-26/30
>> Vote for your XML training:   http://www.CraneSoftwrights.com/u/i/
>> Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/u/
>> Training tools: Comprehensive interactive XSLT/XPath 1.0/2.0 video
>> Video lesson:    http://www.youtube.com/watch?v=PrNjJCh7Ppg&fmt=18
>> Video overview:  http://www.youtube.com/watch?v=VTiodiij6gE&fmt=18
>> G. Ken Holman                 mailto:gkholman@CraneSoftwrights.com
>> Male Cancer Awareness Nov'07  http://www.CraneSoftwrights.com/u/bc
>> Legal business disclaimers:  http://www.CraneSoftwrights.com/legal
>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org
>> For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org
>> 
>> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org
> 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]