BESSELJ

Quirk found

Category: Engineering · Last tested 2026-09-01

Real compatibility results for the BESSELJ function: executed in Excel for the web, Google Sheets and LibreOffice Calc, with desktop Excel behavior from Microsoft’s official documentation (we do not run desktop Excel — Excel for the web is a different application and is executed separately). Syntax and links to that documentation are below.

Support matrix

Engine	Documented	Live-tested	Verdict
Excel (desktop)	Yes	No — documented only	n/a
Excel for the web	—	Yes (recalc, 2026-09-01)	Quirk found
Google Sheets	No	Yes (Drive import, 2026-08-31)	Unsupported (not recognized)
LibreOffice Calc	Yes	Yes (25.8.7.3, 2026-08-31)	Quirk found

LibreOffice version history

We executed the same test cases under each LibreOffice release to show exactly when BESSELJ’s support changed — not documentation claims, real results.

LibreOffice version	Verdict	Tested
24.2.0.3	Quirk found	2026-08-31
24.8.7.2	Quirk found	2026-08-31
25.2.0.3	Quirk found	2026-08-31
25.8.7.3	Quirk found	2026-08-31

Why isn't BESSELJ working in LibreOffice?

BESSELJ exists in LibreOffice 25.8.7.3, but it is not a drop-in match for Excel — our executed tests found real behavioral differences (detailed in the test results on this page). If a formula that works in Excel or Google Sheets misbehaves in LibreOffice, compare your usage against the failing cases above before assuming your data is wrong.

Why isn’t BESSELJ working in Google Sheets?

Google Sheets does not implement BESSELJ: we imported the formula into Sheets on 2026-08-31 and every case came back #NAME? (unrecognized function). Sheets is a rolling service with no version to pin, so this is a statement about the service on that date, and Google’s own function list does not document it either. Rewrite the formula with a documented Sheets equivalent — see the Excel ↔ Sheets equivalents table.

Discovered quirks

=ROUND(BESSELJ(0,0),9) on Excel for the web returned 1.000000003, but the documented/expected result is 1.0.
Provenance
Follows from the documented series definition on the page: J_0(0) is the k=0 term (-1)^0/(0! * Gamma(1)) * (0/2)^0 = 1, with every later term carrying a positive power of x/2 and vanishing. Independently verified with mpmath: besselj(0, 0) = 1.0 exactly; MISMATCH vs expected: expected 1.0, got 1.000000003
=ROUND(BESSELJ(1.9,2),6) on Google Sheets returned #NAME?, but the documented/expected result is 0.329926.
Provenance
Microsoft's page publishes this example's result as 0.329925829, but that figure is WRONG in the 7th decimal place. Re-derived to 20 significant digits with mpmath: besselj(2, 1.9) = 0.32992572769238721660 (scipy.special.jv agrees to machine precision), which differs from the published 0.329925829 by 1.01e-07 -- far larger than the ~1e-10 rounding residue seen on the sibling BESSELY page. Asserting at 6 dp (0.329926) is the deepest precision at which the published figure and the mathematically correct value still agree, so this case tests the function rather than Microsoft's typo; MISMATCH vs expected: expected 0.329926, got '#NAME?'
=ROUND(BESSELJ(1.9,2.7),6) on Google Sheets returned #NAME?, but the documented/expected result is 0.329926.
Provenance
Excel documents "If n is not an integer, it is truncated", so order 2.7 must behave exactly as order 2. Independently verified with mpmath: besselj(2, 1.9) = 0.3299257276923872, while a genuine fractional-order besselj(2.7, 1.9) would be about 0.16248, so this case separates truncation from fractional-order evaluation; MISMATCH vs expected: expected 0.329926, got '#NAME?'
=ROUND(BESSELJ(0,0),9) on Google Sheets returned #NAME?, but the documented/expected result is 1.0.
Provenance
Follows from the documented series definition on the page: J_0(0) is the k=0 term (-1)^0/(0! * Gamma(1)) * (0/2)^0 = 1, with every later term carrying a positive power of x/2 and vanishing. Independently verified with mpmath: besselj(0, 0) = 1.0 exactly; MISMATCH vs expected: expected 1.0, got '#NAME?'
=BESSELJ(1.9,-1) on Google Sheets returned #NAME?, but the documented/expected result is #NUM!.
Provenance
Excel documents: "If n < 0, BESSELJ returns the #NUM! error value."; MISMATCH vs expected: expected '#NUM!', got '#NAME?'
=BESSELJ("abc",2) on Google Sheets returned #NAME?, but the documented/expected result is #VALUE!.
Provenance
Excel documents: "If x is nonnumeric, BESSELJ returns the #VALUE! error value."; MISMATCH vs expected: expected '#VALUE!', got '#NAME?'
=BESSELJ(1.9,-1) on LibreOffice Calc returned #VALUE!, but the documented/expected result is #NUM!.
Provenance
Excel documents: "If n < 0, BESSELJ returns the #NUM! error value."; MISMATCH vs expected: expected '#NUM!', got '#VALUE!'

Executed test cases

Excel for the web (executed 2026-09-01 via OneDrive recalculation)

These values come from Excel for the web, not from desktop Excel. They are two different implementations of the calculation engine, and this run measured only the web one: the corpus was uploaded to OneDrive as .xlsx, recalculated by Excel for the web on open, and downloaded again for readback. Excel for the web is a rolling service with no pinnable version, so the run is identified by its date. Where a value here disagrees with the Expected column — which is Microsoft’s documentation of the desktop product — we cannot tell you whether the web engine diverges from the desktop one or the documentation is wrong about both, because we do not run desktop Excel.

Formula	Description	Result	Expected	Verdict
=ROUND(BESSELJ(1.9,2),6)	Microsoft's documented worked example: Bessel function J at x=1.9, order 2	0.329926	0.329926 Provenance Microsoft's page publishes this example's result as 0.329925829, but that figure is WRONG in the 7th decimal place. Re-derived to 20 significant digits with mpmath: besselj(2, 1.9) = 0.32992572769238721660 (scipy.special.jv agrees to machine precision), which differs from the published 0.329925829 by 1.01e-07 -- far larger than the ~1e-10 rounding residue seen on the sibling BESSELY page. Asserting at 6 dp (0.329926) is the deepest precision at which the published figure and the mathematically correct value still agree, so this case tests the function rather than Microsoft's typo	Matched
=ROUND(BESSELJ(1.9,2.7),6)	A non-integer order, which the documentation says is truncated toward zero	0.329926	0.329926 Provenance Excel documents "If n is not an integer, it is truncated", so order 2.7 must behave exactly as order 2. Independently verified with mpmath: besselj(2, 1.9) = 0.3299257276923872, while a genuine fractional-order besselj(2.7, 1.9) would be about 0.16248, so this case separates truncation from fractional-order evaluation	Matched
=ROUND(BESSELJ(0,0),9)	The order-0 Bessel function at the origin	1.000000003	1.0 Provenance Follows from the documented series definition on the page: J_0(0) is the k=0 term (-1)^0/(0! * Gamma(1)) * (0/2)^0 = 1, with every later term carrying a positive power of x/2 and vanishing. Independently verified with mpmath: besselj(0, 0) = 1.0 exactly	Mismatch
=BESSELJ(1.9,-1)	A negative order	#NUM!	#NUM! Provenance Excel documents: "If n < 0, BESSELJ returns the #NUM! error value."	Matched
=BESSELJ("abc",2)	A non-numeric x argument	#VALUE!	#VALUE! Provenance Excel documents: "If x is nonnumeric, BESSELJ returns the #VALUE! error value."	Matched

Google Sheets (executed 2026-08-31 via Drive import)

Google Sheets is a rolling service with no pinnable version, so this run is identified by its date. The corpus was imported to Drive as .xlsx, recalculated by Sheets, and exported back for readback.

Formula	Description	Result	Expected	Verdict
=ROUND(BESSELJ(1.9,2),6)	Microsoft's documented worked example: Bessel function J at x=1.9, order 2	#NAME?	0.329926 Provenance Microsoft's page publishes this example's result as 0.329925829, but that figure is WRONG in the 7th decimal place. Re-derived to 20 significant digits with mpmath: besselj(2, 1.9) = 0.32992572769238721660 (scipy.special.jv agrees to machine precision), which differs from the published 0.329925829 by 1.01e-07 -- far larger than the ~1e-10 rounding residue seen on the sibling BESSELY page. Asserting at 6 dp (0.329926) is the deepest precision at which the published figure and the mathematically correct value still agree, so this case tests the function rather than Microsoft's typo	Mismatch
=ROUND(BESSELJ(1.9,2.7),6)	A non-integer order, which the documentation says is truncated toward zero	#NAME?	0.329926 Provenance Excel documents "If n is not an integer, it is truncated", so order 2.7 must behave exactly as order 2. Independently verified with mpmath: besselj(2, 1.9) = 0.3299257276923872, while a genuine fractional-order besselj(2.7, 1.9) would be about 0.16248, so this case separates truncation from fractional-order evaluation	Mismatch
=ROUND(BESSELJ(0,0),9)	The order-0 Bessel function at the origin	#NAME?	1.0 Provenance Follows from the documented series definition on the page: J_0(0) is the k=0 term (-1)^0/(0! * Gamma(1)) * (0/2)^0 = 1, with every later term carrying a positive power of x/2 and vanishing. Independently verified with mpmath: besselj(0, 0) = 1.0 exactly	Mismatch
=BESSELJ(1.9,-1)	A negative order	#NAME?	#NUM! Provenance Excel documents: "If n < 0, BESSELJ returns the #NUM! error value."	Mismatch
=BESSELJ("abc",2)	A non-numeric x argument	#NAME?	#VALUE! Provenance Excel documents: "If x is nonnumeric, BESSELJ returns the #VALUE! error value."	Mismatch

LibreOffice Calc 25.8.7.3 (tested 2026-08-31)

Formula	Description	Result	Expected	Verdict
=ROUND(BESSELJ(1.9,2),6)	Microsoft's documented worked example: Bessel function J at x=1.9, order 2	0.329926	0.329926 Provenance Microsoft's page publishes this example's result as 0.329925829, but that figure is WRONG in the 7th decimal place. Re-derived to 20 significant digits with mpmath: besselj(2, 1.9) = 0.32992572769238721660 (scipy.special.jv agrees to machine precision), which differs from the published 0.329925829 by 1.01e-07 -- far larger than the ~1e-10 rounding residue seen on the sibling BESSELY page. Asserting at 6 dp (0.329926) is the deepest precision at which the published figure and the mathematically correct value still agree, so this case tests the function rather than Microsoft's typo	Matched
=ROUND(BESSELJ(1.9,2.7),6)	A non-integer order, which the documentation says is truncated toward zero	0.329926	0.329926 Provenance Excel documents "If n is not an integer, it is truncated", so order 2.7 must behave exactly as order 2. Independently verified with mpmath: besselj(2, 1.9) = 0.3299257276923872, while a genuine fractional-order besselj(2.7, 1.9) would be about 0.16248, so this case separates truncation from fractional-order evaluation	Matched
=ROUND(BESSELJ(0,0),9)	The order-0 Bessel function at the origin	1	1.0 Provenance Follows from the documented series definition on the page: J_0(0) is the k=0 term (-1)^0/(0! * Gamma(1)) * (0/2)^0 = 1, with every later term carrying a positive power of x/2 and vanishing. Independently verified with mpmath: besselj(0, 0) = 1.0 exactly	Matched
=BESSELJ(1.9,-1)	A negative order	#VALUE!	#NUM! Provenance Excel documents: "If n < 0, BESSELJ returns the #NUM! error value."	Mismatch
=BESSELJ("abc",2)	A non-numeric x argument	#VALUE!	#VALUE! Provenance Excel documents: "If x is nonnumeric, BESSELJ returns the #VALUE! error value."	Matched

Docs & syntax

Excel (desktop): official documentation
LibreOffice Calc: official documentation

Where BESSELJ behaves differently

When the documentation is wrong: 29 vendor doc defects found by execution
Independent derivation across 586 executed functions found 29 places where a vendor's own page is contradicted by its own inputs, its own table, or the live engine: 23 Microsoft, 5 Google, 1 LibreOffice. Includes T.INV.2T's doubly-wrong Remark, DISC's stale figure, ISDATE's page against the live engine, and RAWSUBTRACT's help against LibreOffice's own result.