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


I believe the problem is that we don't have a data type for
rationals, just integers and reals (simulated to a certain
precision).  Without native rationals, this is not just a
presentation issue; you can't capture 1/3 with complete
precision using a finite-length floating-point representation.

Mathematically, we could model any rational with two integers
(numerator and denominator), so that the examples so far would
work out like this:

1 1/4 = 5/4
1 1/3 = 4/3
1 foot 1 1/3 inches = 40/3 inches or 10/9 feet

Of course, this would require support in conforming software; but it
shouldn't be that hard.

What users would really like, though, would be a way to enter the
measurements the way they're used to seeing them: feet and inches,
for example.  The problem there is that there are a large number
of special cases: pounds and ounces, hundredweights (of 112
pounds) and stones, pounds/shillings/pence, etc.  These "mixed
numbers" *could* be dealt with as a kind of presentation issue in
the sense that a U.S. builder (for example) could have a plug-in
that converted feet and inches to fractions of inches as above and
another plug-in that displayed the fractional form in feet and
inches.  But this would require a data type for fractions.

Is there really no CCTS data type for that?

Jon

Rick Marshall wrote:
> 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
>>
> 
> 
> ---------------------------------------------------------------------
> 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]