Date: prev next · Thread: first prev next last
2012 Archives by date, by thread · List index


Hi Winfried,

On Thursday, 2012-12-13 09:59:38 +0100, Winfried Donkers wrote:

The coding of this function seems to be going nicely, but for the string to double conversion I 
would like some pointers/interpretations.
1. ODFF1.2 refers to 'xsd:float' and conversion 'according to the definition provided in XML 
Schema, Part 2, Section 3.2.4'. I don't think I found that particular type and section. Could you 
give links to these?

http://www.w3.org/TR/xmlschema-2/#float
Note however that our data type is double, not float, so
http://www.w3.org/TR/xmlschema-2/#double

Personally I think that xsd:float and section 3.2.4 are awkward and it
should be xsd:double and section 3.2.5 instead, but float may be there
to have a common least denominator, I don't remember. This NUMBERVALUE()
definition is the only place mentioning float, earlier versions of the
draft referenced IEEE 754 double at several other places but those got
removed as well.

Short essence: use rtl::math::stringToDouble() to convert, include
rtl/math.hxx

First check if DecimalSeparator appears in GroupSeparator and bail out
if so.

Slightly different processing as given in steps 1-4 of ODFF because
stringToDouble() handles one group separator and this doesn't need extra
processing if there are <=1 characters in GroupSeparator:

If GroupSeparator is not present or empty, call
rtl::math::stringToDouble( X, DecimalSeparator[0], 0, ...)

If GroupSeparator contains one character (length==1), call
rtl::math::stringToDouble( X, DecimalSeparator[0], GroupSeparator[0], ...)

If GroupSeparator contains more than one character, remove all
characters before the first DecimalSeparator in the number string that
match one of GroupSeparator, and call
rtl::math::stringToDouble( X, DecimalSeparator[0], 0, ...)

NOTE: the GroupSeparator OUString/String may contain UTF-16 encoded
      Unicode surrogate pairs, so OUString::iterateCodePoints() should
      be used on the numberstring if that is the case.

Theoretically DecimalSeparator might as well, but stringToDouble()
doesn't handle that. If that really was a problem we'd have to craft
some additional method that takes the full Unicode range.. which I'd
avoid for now.

Of course do the trailing percent sign processing for all cases before
calling stringToDouble().

2. ODFF1.2 mentions under VALUE() that dates should be recognised, as well as fractional numbers, 
e.g. '2 3/8'. I'm not sure if NUMBERVALUE() should recognise that too. For dates it is as good as 
impossible (no separator, language and order is known); but fractional numbers could be 
recognised. What is your judgement on this?

Don't. NUMBERVALUE() is not defined for other cases.

Btw, "2 3/8" could be 23.8 with DecimalSeparator='/' and
GroupSeparator=' ' ;-)

3. Currently I am putting the code for the string to double conversion in de function 
ScNumberValue() itself as i can't find accessable stringtodouble functions that do not ask for 
language settings. Now would be a very good time to tell that I have overlooked the accessible 
stringtodouble function :).

See above ;-)  and sal/inc/rtl/math.hxx

  Eike

-- 
LibreOffice Calc developer. Number formatter stricken i18n transpositionizer.
GnuPG key 0x293C05FD : 997A 4C60 CE41 0149 0DB3  9E96 2F1A D073 293C 05FD
Support the FSFE, care about Free Software! https://fsfe.org/support/?erack

Attachment: pgpYskopm8QvG.pgp
Description: PGP signature


Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.