sfx2 « fi « source - lo/translations - LibreOffice 界面翻译代码仓库

Mode	Name	Size
-rw-r--r--	messages.po	68190	log plain

Age	Commit message (Collapse)	Author
2022-09-21	rework handling of empty cells in opencl code	Luboš Luňák
	Some of the code handling ranges of cells wants empty cells to be zero, some wants to skip them, and few want special handling. So just make three generic cases that handle these, which somewhat simplifies this while still allowing flexibility where needed. Also handle better Test::testFuncSUMXMY2, which works on a pair of ranges, sets a cell in one to a value and another is empty, in this case it is necessary to iterate over this pair with SkipEmpty even if for the second one it's beyond GetArrayLength(). Change-Id: I6c8edaaadb02ffe2a6a7a9399347909008ea188e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140249 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2022-09-20	fix opencl AND() to treat empty cell in svSingleVectorRef as core does	Luboš Luňák
	Functions_Excel_2016.fods incorrectly used "=AND(Sheet2.C22;C33)" instead of the correct "=AND(Sheet2.C22:C33)" (colon vs semicolon), and C33 is an empty cell. The return however was true because empty cells get special treatment because of Excel compatibility. Change-Id: I6d0b28280059fd6fc945e77c7b5d714b5e4727a2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140224 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2022-09-13	reduce opencl copy&paste in op_addin.cxx and op_logical.cxx	Luboš Luňák
	The svDoubleVectorRef stuff in OpAnd etc. didn't make sense, those operators are required to do implicit intersection (which can be done in sc core in ScCompiler::HandleIIOpCodeInternal()). Change-Id: Ic970c8e649a651f6a804b5ed265fe2e08ff29681 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139485 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2022-09-01	make sure opencl generated code doesn't lose numbers precision	Luboš Luňák
	The default precision of both iostreams and stdio is 6 decimal places. This means that e.g. =POWER(1.0000001,2) becomes 1, since buf << number will write that first number simply as '1'. Moroever some generated code actually doesn't compile because ambiguous overloads, because '1' is an integer and not a double, thus floor(1) is ambiguous, as there are only floating point overloads (and C/C++ are stupid about these conversions). So force using a wrapper class that forces a higher precision and the decimal separator. For debug builds, also avoid excessive precision. Apparently, neither iostreams nor stdio are capable of simply printing a reasonable floating point representation that wouldn't be too precise or imprecise. Change-Id: Ifa045712d90e6a6bbe5781ac3c805c989673dc8e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139073 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-03-23	tdf#124176 Use pragma once in s*	Vincent LE GARREC
	sc, scaddins, sccomp, scripting Change-Id: Ia99fec9e238033821cb784810edd4762c09bd5db Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112049 Tested-by: Jenkins Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
2020-05-09	compact namespace in sc	Noel Grandin
	Change-Id: I05ffad6b92883d3eb6d337fe75f5fc7864485861 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93860 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2018-11-29	make OpenCL bail out if it can't handle multi-column refs	Luboš Luňák
	The opencl code splits SvDoubleRef into subarguments by each column, but many functions simply treat each subargument as one argument for the function, thus possibly getting things wrong (e.g. SUMPRODUCT would make a product of each column and sum those, rather than making a product of the whole SvDoubleRef). So bail out if multi-column SvDoubleRef is encountered, unless the function is known to handle this case properly (either it takes extra care, such as VLOOKUP, or it doesn't matter, such as SUM, AND, MAX). Change-Id: Ied89a2fc252fb35fe49796140489ff4588038e25 Reviewed-on: https://gerrit.libreoffice.org/64238 Reviewed-by: Michael Meeks <michael.meeks@collabora.com> Tested-by: Michael Meeks <michael.meeks@collabora.com>