Change-Id: Id50533bc52f36d2daf31bfda4fabfb6d126df4b9

Change-Id: Icdc5abf9dca727a8cc312ddb5861f7a34a38bbe1

Change-Id: Icdf85d6f6f5734a3cf952def8782efe9edc7c0a9

Change-Id: I762062a4782438ec5bbcb53da9a42f44db65c40d

Change-Id: I45d6fc28e898b945c7754b9ee1f2842247a071e6

Change-Id: I15654a7aa5a99cb3aa6f8ba222cf2aa1d2f040ab

Change-Id: Iaac3618501b4e382afe8d183836a370eea699af4

Change-Id: I03db46afcc0cb5e5d7a134b1bdd327abb542e63c

Change-Id: Id3852abe9bc7bbe774331a7d691abd2a79ff59b4

Change-Id: I12290bed7e4f298ab90393b8de6e2b6e7061e53f

Change-Id: I12290bed7e4f298ab90393b8de6e2b6e7061e53f

Change-Id: I4cfbb53763001854d37fbcd304e77e65279173b6

Change-Id: I8ca272481e573bf3338c5c1b9873a39022928812

Change-Id: I2c73bb2b2edd3b830dad5d1f7d8f7bc72622b11c

Change-Id: I093b4812bf3b75d6a6f3c8ea38755619f5c9d151

Change-Id: I285bd632faba5a29a770404d6967f4faf7667b16

If a Timeout appears, while the idle scheduling is in progress.
The idle scheduler gets interrupted and the timeouts are handled.
Now the idle scheduler has a new starving protection.

Change-Id: Ic9081c647e3fb0abf3b0dc014e711a3b97e0e37d

And everything is functionating pretty well.

Change-Id: Id7f5a995362f6f7c5235f2e9facb7c7f119f3140

And everything is functionating pretty well.

Change-Id: Id7f5a995362f6f7c5235f2e9facb7c7f119f3140

Change-Id: I8a280c54d81c7da74c9ab03ff3fc788e373ca4e4

Change-Id: Id4ef36d6c80ad62306bdbaa7094c2cb0b8ff77da

Now the Idle and Timer are divided in two seperate classes. But now all changed
idles need a new import, before the programm is working again.

Change-Id: I5be7424622b6fcc993c621fa4a11fbee1b6d9bf2

Change-Id: I2e5462544d83572e8206bb1db92a2b9df032281b

Change-Id: I27985e456447ef3d71cae39c2acaf59b3aa60b83

Change-Id: I213722cc98490430378014290cb09cca9e469bbb

Instead of a bare NAN.

There are still many places in this function where the code bluntly returns a
bare NAN. That is always the wrong thing to do. However, it is not certain
that the #DIV/0! is the right error in all cases. One would need to check in
each case how to get there, and what the reference C++ implementation and
other spreadsheet products do in such a case.

Change-Id: I5454609082a92144b1afc3c1745586bfe8ef87f8

Returning a NaN with no "double error" semantic payload as such does not make
sense. "Pure" NaNs are displayed in Calc as "nan" which probably is not what
we want.

Change-Id: I85dc55328669bd27478be438dd5a9970d24cf7f9

Change-Id: Ia3e978e3fd9c0ce19ec679c41d40a34338147c37
Reviewed-on: https://gerrit.libreoffice.org/14766Reviewed-by: Lionel Elie Mamane <lionel@mamane.lu>
Tested-by: Lionel Elie Mamane <lionel@mamane.lu>

Returning -DBL_MAX doesn't make sense. The traditional C++ implementation and
other spreadsheet products return an error.

Change-Id: I71117c0b1f113d31ad6eb0c1798b74f96b3a75de

Change-Id: Ia58f19c7121dc8a835436bcefc7fd1e3789407db

Returning DBL_MAX doesn't make sense. The traditional C++ implementation and
other spreadsheet products return an error.

Change-Id: I8189c3ecf4aa7b1df00ec2fd8b91030085848bf4

Surely it doesn't make sense, but we should return zero instead?

At the two call sites, there are tests against a zero having been returned,
but not against a negative value. And the return value is even passed as the
nArrayLength parameter to a formula::DoubleVectorRefToken constructor, which
is of type size_t, thus unsigned. Passing for instance -4 to it ends up being
interpreted as 18446744073709551612, which has fun consequences.

Change-Id: Ifca97cd4bae8e921345bcf9d0ca6bb040e3c3b79

Change-Id: I252987d6c5e5da56a83742c96b4e86abbb7108c6

Having these statistical functions perform well is essential in many cases,
and their implementations seem to be correct.

Change-Id: I30afa096295cc163f8c0146e916a77aa411dd07b

Change-Id: Ib71d74d4b66b02a6a680b5ab0c905b987d59cf7f

Change-Id: I43b59b4359a010e7b64df5825ae3ce845e47fc4b

The initialism “TDF” is rather obscure still.

Change-Id: I987e96d869a5126f5d137d188a34b4ae7d4888f8

Change-Id: I11c7c94a52e4be7286a919e61818d08d5b9ad623

Change-Id: I3aacb177d209db74ffadf5284550cdd4972554de

Change-Id: Ie063071cc57d756fd5da20a15533a6857940f676