[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 think the important point is that the numerics carried in these documents are used not generally used for arithmetic. when someone orders 1/3 of an inch of something or 5/16 of a pint these are effectively text (ie presentation). I am not sure I have seen a case in EDI or UBL for actually knowing that 1/4 is really the same as 0.25 or that 1/3 is a bit more than 1.333 or for knowing two times 1/6 is 1/3 etc... Perhaps we need a use case for the problem statement? Jon Bosak wrote: > 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 >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org > For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org > >
begin:vcard fn:Tim McGrath n:McGrath;Tim org:Document Engineering Services Ltd. email;internet:tim.mcgrath@documentengineeringservices.com title:Managing Director tel;work:+45 36 95 33 58 tel;cell:+61 438 352228 url:www.documentengineeringservices.com version:2.1 end:vcard
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]