=IFERROR(LET(a_1;1;a_1);"ERROR") This formula produces "ERROR", while the formula "=LET(a_1;1;a_1)" produces the expected "1".
repro in Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: a8ec21adf255b70bb6eeb0a1717190df303d8b26 CPU threads: 16; OS: Windows 10 X86_64 (build 19045); UI render: Skia/Vulkan; VCL: win Locale: ru-RU (ru_RU); UI: ru-RU Calc: CL threaded but the result is #NULL! in Version: 24.8.0.3 (X86_64) / LibreOffice Community Build ID: 0bdf1299c94fe897b119f97f3c613e9dca6be583 CPU threads: 16; OS: Windows 10 X86_64 (10.0 build 19045); UI render: Skia/Vulkan; VCL: win Locale: ru-RU (ru_RU); UI: ru-RU Calc: CL threaded and in Version: 25.2.0.3 (X86_64) / LibreOffice Community Build ID: e1cf4a87eb02d755bce1a01209907ea5ddc8f069 CPU threads: 16; OS: Windows 10 X86_64 (10.0 build 19045); UI render: Skia/Vulkan; VCL: win Locale: ru-RU (ru_RU); UI: ru-RU Calc: CL threaded Mike, is it an implementation error for LET function?
The formula =ABS(LET(a_1;1;a_1)) is interpreted as an array formula and returns #NULL! . The same applies to other numeric functions (instead of ABS). Version: 24.8.4.2 (X86_64).
(In reply to Vladimir Sokolinskiy from comment #2) This is bug 164998.
Maybe related. I found this bug when searching for a bug with the combination of an if statement and let. I tried: IF B46>0,B46,LET...) which produces a #NULL! while the LET.. produces a valid result and the IF B46>0,B46,"boo"), produces the expected "boo" The full formula is =IF(B46>0,B46,LET(a,XLOOKUP(1,$B$1:$B45<>0,$B$1:$B45,"",0,-1),b,XLOOKUP(1,$B47:$B$1000<>0,$B47:$B$1000),rowa,MATCH(a,$B$1:$B$1000) ,rowb,MATCH(b,$B$1:$B$1000) , a+(b-a)/(rowb-rowa)*(ROW(B46)-rowa))) Which should interpolate missing data in a list of numbers in B1:B100
Balazs Varga committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/157a3629b30ec66b4998f63ea21d3ae1881c582d tdf#164997 - sc refactor and optimize LET function calculation It will be available in 25.8.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Using a debug build including 157a3629b30ec66b4998f63ea21d3ae1881c582d, I still see =IFERROR(LET(a_1;1;a_1);"ERROR") resulting in "ERROR". Comment 0 still isn't addressed; I don't see it fixed.
(In reply to Mike Kaganski from comment #6) > Using a debug build including 157a3629b30ec66b4998f63ea21d3ae1881c582d, I > still see > > =IFERROR(LET(a_1;1;a_1);"ERROR") > > resulting in "ERROR". Comment 0 still isn't addressed; I don't see it fixed. Thanks for the feedback Mike. Hmm thats interesting, I even added the same unit test case to the example document: =IFERROR(LET(a_1;1;a_1);"ERROR") which produce the correct result: 1. And tried it many times after recalculate everything on the spreedsheet. Also Gábor confirmed in the comment: https://gerrit.libreoffice.org/c/core/+/181662/comments/92e516ec_030b1695 (I guess he tried on linux) Interesting that you still get the wrong "ERROR" result with that example. :(
Just in case, I made sure to 'make clean' then 'make' again, and double-checked. It still produces ERROR. May it be related to locale? Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: cf8cf72bae481b35eecab97e8a6094e83f8ad9fa CPU threads: 24; OS: Windows 11 X86_64 (build 26100); UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-GB Calc: CL threaded
(In reply to Mike Kaganski from comment #8) > Just in case, I made sure to 'make clean' then 'make' again, and > double-checked. It still produces ERROR. > > May it be related to locale? > > Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community > Build ID: cf8cf72bae481b35eecab97e8a6094e83f8ad9fa > CPU threads: 24; OS: Windows 11 X86_64 (build 26100); UI render: > Skia/Vulkan; VCL: win > Locale: en-US (en_US); UI: en-GB > Calc: CL threaded Thanks for the version details. I also set the Local to en_US now, but still have the good results after a make clean (pull) and build. Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 696c241c03d3773fd82cedc390192dfa784c2493 CPU threads: 20; OS: Windows 11 X86_64 (build 26100); UI render: Skia/Raster; VCL: win Locale: en-US (hu_HU); UI: en-US Calc: CL threaded Also I tried with an older version on a different Windows PC: Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: b0d4b4664a295631ce4d8dee2ceb5cd94ae12edb CPU threads: 8; OS: Windows 11 X86_64 (build 26100); UI render: Skia/Vulkan; VCL: win Locale: en-US (hu_HU); UI: en-US Calc: CL threaded and still got the correct results. Probably not related to local setting but related to something else, have no idea so far what can be the difference, but surely something can be still wrong if you have a wrong result.
Created attachment 199242 [details] Let function result screenshot