Bug Hunting Session
Bug 61228 - TABLE: Function summe() does not sum up but returns last item
Summary: TABLE: Function summe() does not sum up but returns last item
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
3.6.3.2 release
Hardware: x86-64 (AMD64) Windows (All)
: medium minor
Assignee: Not Assigned
URL:
Whiteboard: target:5.1.0 target:5.0.4
Keywords:
: 95687 (view as bug list)
Depends on:
Blocks: Calc-Function
  Show dependency treegraph
 
Reported: 2013-02-21 11:51 UTC by Martin Vogel
Modified: 2018-09-13 10:12 UTC (History)
8 users (show)

See Also:
Crash report or crash signature:


Attachments
example document (9.43 KB, application/vnd.oasis.opendocument.text)
2013-02-21 13:47 UTC, Thomas Arnhold
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Vogel 2013-02-21 11:51:49 UTC
In the German versions of LibreOffice Writer (tested in 3.6.3.2/Windows and 3.6.4.3/Linux, both 64 bit) a function summe() exists which behaves quite strange. 

The function summe() is similar but not identical to the command sum.

=summe(<A1:A3>)

returns the sum of the cells A1 to A3, but

=<A1:A3>

does this, too. So the command sum in

=sum <A1:A3>

seems to be superfluous.

What looks weird to me is that summe() can be used only once in each formula, so

=summe(<A1:A3>)+summe(<C1:C3>)

leads to an error ** Fehlerhafter Ausdruck ** (expression is faulty). On the other hand the command sum (or its absence) works perfectly this way:

=sum<A1:A3>+sum<C1:C3>
=<A1:A3>+<C1:C3>

Things become completely strange when you try to use summe() to really sum up a list of items. The formula
 
=summe(item1;item2;item3) 

always returns item3 and not the sum of the three items. I tried it both with cell references and numbers. 

To use a comma as separator is a bit tricky, for the comma is used as a decimal point in Germany. Additional spaces have to be used. The result is the same as above.

=summe(3, 4, 5)

always returns "5".

When I entered 

=sum 3;4;5

the behaviour was the same, too. The cell showed just "5".

Having sum already identified as being useless, I tried

= 3;4;5

and got only "5", too.

This is a totally unexpected behaviour.
Comment 1 Thomas Arnhold 2013-02-21 13:47:34 UTC
Created attachment 75252 [details]
example document

Can confirm this with 4.0.0.3 on Windows 7, too. I tried both locales German und US. Curiously the US-locale also understands the =summe function.
Comment 2 Mike Kaganski 2013-08-09 04:16:41 UTC
I use Russial locale. And opening the attached document allowed me to see what you describe.

Then I entered the lext formula to the top left cell:
=abracadabra(<B2:C2>)
and the result was 12.

I conclude, that if the name of the function is not recognized, LO just ignores it -> the formula I entered is treated as
=(<B2:C2>)

I don't know if this should be regarded bug or feature...
Comment 3 Eike Rathke 2013-08-12 10:31:59 UTC
Removing myself from Cc again, this is about formula expressions in Writer which I know nothing about, only that they are completely different from Calc and don't share syntax or semantics.

Just tried that =sum(<A2:B2>)+sum(<A3:B3>) in 4.1.0 actually works as expected (note the bug was reported against 3.6.3). I think expressions like =sum(<A2:B2>;<A3:B3>) are not supported, I get a "** Expression is faulty **" for such thing.

And yes, it seems that an unknown or omitted function name is mapped to sum.
Comment 4 immanuelg 2014-07-27 19:06:18 UTC
TESTING
Windows7x64
4.3.0.3

In row 1, 4 cells: 
2	3	4	5

In cell B3, the formula
=SUM(A1:B1)+SUM(C1:D1)

returns
14

this is the expected behaviour


The bug was reported on 3.6.3.2 - can you test again with a newer version and provide details if it still fails.
Comment 5 Thomas Arnhold 2014-07-27 22:05:40 UTC
immanualg: I confirm this with Version: 4.2.5.2 on Windows. GERMAN version. There is a function "summe", not the localized one (sum in en-US). See the differing syntax with "<A1:A2>"...
Comment 6 Mike Kaganski 2014-07-28 03:47:11 UTC
Actually, the problem isn't described clearly.

Namely, there's NO function "summe" in no locale of LO writer. So, original poster described the situation where one uses arbitrary name as "function" and sees that it is ignored by writer.

When writer sees a formula like "=summe(<A1:A3>)", it parses it, finds "summe" and looks for it in its pre-defined names (functions, variables and constants), in user-defined names (variables), doesn't find it, and substitutes it with empty string. Then it has formula like "=(<A1:A3>)", and processes it normally.

When using correct syntax (i.e. pre-defined name "SUM"), it is processed correctly.

Then, what is the issue? Is it the proposal to add new function "summe" as a localized name for "SUM"? If yes, then there should be other localizations for other languages, too (and then, do it for calc as well).

Or maybe you mean that writer should not ignore unknown names (turn them into empty strings), and should instead emit an error return value (like "<ERROR>") in the cell (to notify user of possible mistake)?

It is not "NEW", until the actual problem is clarified. Setting to NEEDINFO, please set it to "UNCONFIRMED" after providing necessary clarifications.

Thank you.
Comment 7 Thomas Arnhold 2014-07-28 06:39:30 UTC
Mike, ah your explanation maked it clear to me. "summe" is not the problem. You cat try anything else, like "foo". Writer only interprets the "<A1:A3>" part of "=summe(<A1:A3>)". Looks like the angle brackets are some shortcut to sum?!

The issue is, that writer should not silently ignore the wrong function name, but display an error, that the function was not found. Then it would be clear to everyone.

As that is clarified I set it to NEW.
Comment 8 Mike Kaganski 2015-04-19 12:33:22 UTC
(In reply to Thomas Arnhold from comment #7)
> The issue is, that writer should not silently ignore the wrong function
> name, but display an error, that the function was not found. Then it would
> be clear to everyone.

I need to add to this interpretation.
Currently Writer "ignores" unknown variable names (as if they are equal to 0). That's OK, and enables writing "self-describing" formulas with comments like this:

=(1+2+3-apples)+(4+5+6-oranges+peaches)

where all the names are undefined and used there just to clarify that I added 1+2+3=6 apples and a total of 4+5+6=15 oranges and peaches. Writer will end up with 21 in that cell. "Fixing" this to emit error on that names would disable that handy trick. Well, that also mean that if a user makes a mistake writing a defined variable name, than that error could be unnoticed, silently accepting that wrong name as if it is 0 (and giving wrong result). Well, that is arguably bad, but is accepted in languages like Lisp and Basic, so the decision is up to implementors (ODF standard?).

On the other side, treatment of undefined _function_names_ is somewhat inconsistent. If the function is the last element in a formula, like in

=1+2+foo(3+4)

then the end result will be just what is inside the function, i.e. 3+4=7. Everything before it will be simply ignored.
If the function is not the last element, then an error is emitted:

=foo(3+4)+1+2

** Expression is faulty **

For consistency, this should be treated uniformly, e.g. ignore in any place (and without dropping previous data), or emit error in all cases.
Comment 9 Julien Nabet 2015-11-22 14:08:41 UTC
*** Bug 95687 has been marked as a duplicate of this bug. ***
Comment 10 Julien Nabet 2015-11-22 16:49:00 UTC
Mike: I submitted a patch for this, https://gerrit.libreoffice.org/#/c/20122/. Thought you might be interested in taking a look.
Comment 11 Commit Notification 2015-11-24 22:05:09 UTC
Julien Nabet committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=d667e3210b12c7ce3b3727e2a0e369a520fbaaa4

tdf#61228: Wrong function names in Formula Writer are considered as SUM

It will be available in 5.1.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 12 Commit Notification 2015-11-25 04:05:14 UTC
Mike Kaganski committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=a15b9b44d933ef06efbc231d66b79815ba69ceff

tdf#61228: formatting and commenting

It will be available in 5.1.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 13 Commit Notification 2015-11-26 12:27:48 UTC
Julien Nabet committed a patch related to this issue.
It has been pushed to "libreoffice-5-0":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=238a02cb567768ff0d7338ddab87441ec5e5d470&h=libreoffice-5-0

tdf#61228: Wrong function names in Formula Writer are considered as SUM

It will be available in 5.0.4.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 14 Commit Notification 2015-11-27 22:47:11 UTC
Mike Kaganski committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=e963e4788d4d4a493e02d3f6c4b1024f3091c502

tdf#61228: Unit test

It will be available in 5.2.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.