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.
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.
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...
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.
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.
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>"...
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.
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.
(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.
*** Bug 95687 has been marked as a duplicate of this bug. ***
Mike: I submitted a patch for this, https://gerrit.libreoffice.org/#/c/20122/. Thought you might be interested in taking a look.
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.
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.
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.
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.