Bug 66319 - returned complex numbers use decimal point regardless of locale
Summary: returned complex numbers use decimal point regardless of locale
Status: ASSIGNED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: Other All
: low minor
Assignee: Andreas Heinisch
URL:
Whiteboard:
Keywords:
: 156420 (view as bug list)
Depends on:
Blocks: Number-Format
  Show dependency treegraph
 
Reported: 2013-06-28 13:08 UTC by Andras Timar
Modified: 2024-02-01 20:04 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Andras Timar 2013-06-28 13:08:01 UTC
For example, if you apply this formula:
=IMPOWER("2+3i";1/2)

Result is:
1.67414922803554+0.895977476129838i

When for Croatian locale it should be:
1,67414922803554+0,895977476129838i 

Code pointer:
::GetString() in source/analysis/analysishelper.cxx
Comment 1 Mikeyy - L10n HR 2013-06-28 21:04:23 UTC
It's same with other formulas which work with complex numbers, for example IMPRODUCT.

I tested this on croatian, HR, locale, but there is report that portuguese language have same problems.
Comment 2 QA Administrators 2015-03-16 23:29:48 UTC Comment hidden (obsolete)
Comment 3 Mikeyy - L10n HR 2015-03-17 06:25:42 UTC
Yes, it's still present in 4.4.2.1 on Windows 8.1 64bit.
It's also present in 3.3.2 so I guess it's bug from OO.
Comment 4 tommy27 2016-04-16 07:22:50 UTC Comment hidden (obsolete)
Comment 5 Andras Timar 2016-04-16 09:02:56 UTC
On Linux, if we start LibreOffice with for example:
   LC_NUMERIC=hr_HR.UTF-8 instdir/program/scalc
Then =IMPOWER("2+3i";1/2) will be printed as 
   1,67414922803554+0,895977476129838i 
Because the decimal separator in format code of snprintf at http://opengrok.libreoffice.org/xref/core/scaddins/source/analysis/analysishelper.cxx#972 depends on the LC_NUMERIC part of the locale. At least this is the case under Linux. I'm not sure about Windows.

Anyhow, LibreOffice has its own locale setting, ideally it should be used instead of LC_NUMERIC and snprintf.
Comment 6 Mikeyy - L10n HR 2016-04-16 09:58:57 UTC
(In reply to Andras Timar from comment #5)
> At least this is the case under Linux. I'm not sure about Windows.
> 
> Anyhow, LibreOffice has its own locale setting, ideally it should be used
> instead of LC_NUMERIC and snprintf.

On windows it's dot instead of comma. Tested with latest 5.1.2.
Why enhancement when it's bug?
Comment 7 Andras Timar 2016-04-16 10:48:01 UTC
(In reply to Mikeyy - L10n HR from comment #6)
> On windows it's dot instead of comma. Tested with latest 5.1.2.
Thanks for testing.

> Why enhancement when it's bug?
OK, it's a minor bug then. In fact, it should depend on the cell's language.
Comment 8 QA Administrators 2017-05-22 13:22:17 UTC Comment hidden (obsolete)
Comment 9 Thomas Lendo 2019-07-07 17:59:20 UTC
Still valid.

Version: 6.3.0.0.beta1
Build ID: a187af327633f5f00363be5131bd21a13e0f1a7b
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; 
Locale: de-AT (de_AT.UTF-8); UI-Language: en-US
Comment 10 QA Administrators 2021-07-07 04:02:52 UTC Comment hidden (obsolete)
Comment 11 Andras Timar 2021-07-07 06:30:27 UTC
Still valid.
Version: 7.2.0.0.alpha1+ / LibreOffice Community
Build ID: 4fbc246c7021248e4e9689f59b030b4b8f526954
Comment 12 Diana Vides 2023-07-04 05:19:47 UTC
This bug is still present in Version: 7.5.3.2 (X86_64) / LibreOffice Community
Build ID: 9f56dff12ba03b9acd7730a5a481eea045e468f3
CPU threads: 6; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win
Locale: hr-HR (en_US); UI: en-US
Calc: threaded

It is also present in Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 105f057f5b994b7d79a55ca719240839c2d45b54
CPU threads: 6; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win
Locale: hr-HR (en_US); UI: en-US
Calc: CL threaded
Comment 13 ady 2023-07-22 11:20:50 UTC
*** Bug 156420 has been marked as a duplicate of this bug. ***
Comment 14 ady 2024-02-01 16:44:21 UTC
FWIW, are we all sure that we want a different decimal separator dependent on locale settings for complex numbers? Are other spreadsheet tools also have such distinction?
Comment 15 Jean-Claude Arbaut 2024-02-01 20:04:14 UTC
(In reply to ady from comment #14)
> FWIW, are we all sure that we want a different decimal separator dependent
> on locale settings for complex numbers? Are other spreadsheet tools also
> have such distinction?

I can only speak for Excel on Windows, with a French locale: indeed, the results of complex functions follow the regional settings. By default the decimal separator is a comma, and it's a comma in complex numbers in Excel as well. If the regional settings are changed to something else in Windows parameters, the change is reflected in Excel, including the results of complex functions.