search for: motl

...t: 10000000000010996 10000000000011000 When we sort the data in the increasing order, we get the correct result. If we sort the data in the decreasing order, we get a result that is off by 4. Shouldn't the sort be in the increasing order rather than in the decreasing order? Best regards, Jan Motl PS: This post is based on discussion on https://stackoverflow.com/questions/47847295/why-does-chisq-test-sort-data-in-descending-order-before-summation and the response from the post to r-help at r-project.org.

> On 28 Dec 2017, at 13:08 , Kurt Hornik <Kurt.Hornik at wu.ac.at> wrote: > >>>>>> Jan Motl writes: > >> The chisq.test on line 57 contains following code: >> STATISTIC <- sum(sort((x - E)^2/E, decreasing = TRUE)) > > The preceding 2 lines seem relevant: > > ## Sorting before summing may look strange, but seems to be > ## a sensib...

>>>>> Jan Motl writes: > The chisq.test on line 57 contains following code: > STATISTIC <- sum(sort((x - E)^2/E, decreasing = TRUE)) The preceding 2 lines seem relevant: ## Sorting before summing may look strange, but seems to be ## a sensible way to deal with rounding issues...

...: 10000000000010996 10000000000011000 When we sort the data in the increasing order, we get the correct result. If we sort the data in the decreasing order, we get a result that is off by 4. Shouldn't the sort be in the increasing order rather than in the decreasing order? Best regards, Jan Motl PS: This post is based on discussion on https://stackoverflow.com/questions/47847295/why-does-chisq-test-sort-data-in-descending-order-before-summation <https://stackoverflow.com/questions/47847295/why-does-chisq-test-sort-data-in-descending-order-before-summation>. [[alternative HTML...