https://bz.apache.org/ooo/show_bug.cgi?id=126754

Wolfgang Jäger <[email protected]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[email protected]

--- Comment #11 from Wolfgang Jäger <[email protected]> ---
As I was quoted (I am 'Lupp' in the forum.openoffice.org), I want to also post
my actual view of this.
The issue is not at all related to any application of TEXT and/or LEFT and to
the bahaviour of these functions. They do their job as they are specified to
do. 

The issue is exclusively one of implicit conversion from text into number in a
very specific case. Let me explain: 
"1E0" in the position of an operand of an arithmetic expression will implicitly
convert into the number 1. The same if placed on a parameter position specified
to accept a number. This is correct.

The one (many) in charge of implementing the implicit conversion did it in a
way allowing for an empty exponent when given a number in "scientific
notation", and interpreting this missing of an exponent as a 0 intended. Thus 
"1E", "1E+", "1E-" are treated equivalent to "1E0" on conversion. 

As there is no explicit specification about how numbers to enter/import or to
be created by conversion from text in Calc should look, we have to resort to
the specification of numbers for the persistent representation, and apply it
with the least possible modifications needed under any specific locale. In any
case we should not accept empty exponents for the scientific notation. 

Another approach may be that the implicit conversion should, as near as
possible, accept by the same syntax as the explicit conversion by the VALUE
function and the recognition routine to apply to edited cells do.

Finally even the implicit conversion as is, does not accept an empty exponent
(for 0) if applied on a number in scientific notation when a decimal fraction
part is included. 

This very inconsistent behaviour should be cleaned out. LibreOffice does not
behave this way (at least since V3.5.2; it still did in V3.3). The
interoperability can surely not be re-established by LibO taking over the
inconsistencies.
 I did not test myself but was told that even Excel is sound with this respect.

-- 
You are receiving this mail because:
You are the assignee for the issue.

Reply via email to