Hmm .. rather than talking about doing "textual comparisons on numbers", why not say "BigInt"( BigNum)?
There are lots of packages out there that already deal in infinite-precision numbers, together with methods for converting them to and from strings, and for doing arithmetic on them too, as well as doing comparisons. > -----Original Message----- > From: Arnold, Curt [SMTP:[EMAIL PROTECTED] > Sent: Thursday, January 06, 2000 9:27 PM > To: '[EMAIL PROTECTED]' > Subject: RE: PROPOSAL: Perform min/max validation of numeric types > without con verting to numeric type > > Say we are on a hypothetical platform where double's maximum value was > 1E100 but the user either not interested in the value (just validation) or > was bringing the textual representation into a > symbolic math processor or into a MathML presentation document. > > The schema author is unaware of this platform and writes a constraint like > > <datatype type="someval" source="double"> > <!-- for some physical reason the value can't exceed 1e200 --> > <maxInclusive value="1e200"/> > </datatype> > > If you did conversion on a platform that used IEEE double or used the > approach that I described, then you would expect 0.9E200 to be legal and > 1.1E200 to not be legal. > > However, if you used conversion on a platform where double ranged was > limited to 1E100, then there is no way have a different result for the > range check for 0.9E200 and 1.1E200. You either have to > reject both or accept both. > > A text comparision would avoid rounding issues. For example, if the > schema author indicated that there was a minExclusive limit of 1.0, a text > comparison would allow > 1.00000000000000000000000000000000000000001 where conversion to a double > would have lost that trailing 1 and indicated that the value violated that > range. > > Avoiding use of the C RTL floating point facility should be a major plus. > It appears that Xerces-C on VC 6 is currently built to suppress > initialization of C RTL floating point since I have not been > able to coerce any of the text to double routines to work properly. > > Definitely if we were needing to do any other floating point operations, > then conversion to a numeric type would be necessary. However, for > validation, all that is necessary is comparision and that > should be fairly simple to write robustly. > > > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Thursday, January 06, 2000 12:40 PM > To: [EMAIL PROTECTED] > Subject: Re: PROPOSAL: Perform min/max validation of numeric types > without con verting to numeric type > > > > > > I understand your objectives here; but, looking further down the road, > there might be complicated issues. One of the big advantages of Schema is > that the client program can know that say an attribute is an integer value > between -31.38913 and +34.1233. In many instances, they are going to use > this knowledge to convert that number to a binary themselves. If that > result does not agree with the result gained via the lexical comparison, > things could get wierd, right? So the lexical comparison of any text > encoded binary values would have to absolutely match the results that > would > occur when the value is actually converted, or you might get conflicting > results. > > So I guess a question is whether it is more important to be consistent on > a > particular platform or not. If it is, then doing the conversion, warts and > all, would insure that consistent results are gained. By the time you > write > the code to insure that you've handled all the platform specific rounding > issues in the lexical comparison, might you not have come back to the same > place you were attempting to avoid, just with more work? > > For integral or cardinal values of course this is not such a big deal and > a > lexical comparison would work. But if Schema ever allowed a statement like > (10 / 3) as a value in a range check, then similar issues would come up > again. > > I don't know that any of will really be a big deal in the end. I'm just > playing Devil's Advocate so people will consider all the wierd angles. > > ---------------------------------------- > Dean Roddey > Software Weenie > IBM Center for Java Technology - Silicon Valley > [EMAIL PROTECTED] > > > > "Arnold, Curt" <[EMAIL PROTECTED]> on 01/06/2000 09:26:38 AM > > Please respond to [EMAIL PROTECTED] > > To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]> > cc: > Subject: PROPOSAL: Perform min/max validation of numeric types without > con > verting to numeric type > > > > I would recommend that when someone starts working on implementing min/max > validation of integers and reals that we attempt to implement the > comparision operation without converting the string into a > primitive numeric type. This would avoid problems with the C RTL has not > been initialized and avoid different validation behavior on different > machines. I also believe that it may be faster than > conversion to a numeric type and a numeric comparision. I think something > like the following would be effective (unchecked C++ code). If this type > of approach was successful, the XML Schema could be > greatly simplified by removing all the details of the implementation of > IEEE 754 from Schema and leave the binding to a specific implementation > type to the type-aware DOM initiative. > > // > // the same class could be used for both real and integer types > // > class ValidationNumeric > { > public: > // > // string is assumed to stay valid for lifetime of this object? > ValidationNumeric(const XMLCh* string); > inline long getExponent() const { return m_exponent; } > bool getIsPositive() const { return m_isPositive; } > bool getIsNaN() const { return m_isNaN; } > bool getIsInfinity() const { return m_isInfinity; } > const XMLCh* getMostSignificantDigit() const { return > m_mostSignificantDigit; } > > enum compareResult { isEqual, isLess, isGreater, isInvalid }; > > compareResult compare(const ValidationNumeric& other) > // > // first shot, logic might not quite be right > if(getIsNaN() || other.getIsNaN()) > { > if(getIsNaN() && other.getIsNaN()) return isEqual; > return isInvalid; > } > if(getIsPositive()) > { > if(!other.getIsPositive()) return isLess; > if(other.isInfinity()) > { > if(isInfinity()) > return isEqual; > else > return isGreater; > } > if(getExponent() > other.getExponent()) return isLess; > if(getExponent() < other.getExponent()) return isGreater; > // > // walk through both strings starting with most > significant digit (skipping over .'s) > > } > ... > } > > bool operator>=(const ValidationNumeric& other) > { > compareResult result = compare(other); > if(result == isEqual || result == isGreater) return true; > return false; > } > > private: > const XMLCh* m_mostSignificantDigit; > bool m_isPositive; > bool m_isNaN; > bool m_isInfinity; > long m_exponent; > }; > > >
