Re: [Gretl-users] Bug in msortby
Am 07.11.2012 21:42, schrieb Allin Cottrell:
On Wed, 7 Nov 2012, Pindar wrote:
> Indeed, on my W7 PC with the new snapshot the 'evals' are
> not the same. The order within the bins is different. I
> expected the null operation and checked other parts of the
> code until I found the reason explained. I gonna try with
> 'matrix K' instead of the ~ operation and report then.
OK, I suspect this must be a difference between the
implementation of the qsort() function in the Microsoft C
library and the GNU C library. The C standard doesn't specify
whether or not elements of an array passed to qsort() that
compare equal will remain in the original order. Apparently
glibc is preserving the original order while MS is messing
with it.
Printing test gives:
-8 0 \ 16 0 \ -6 0 \ 2 0\ -4 0 \ 0 0 \ 0 0
\ 0 0 \ 0 0 \
0 0 \ 0 0 \ 0 0 \ 0 0 \ 0 0 \ 0 0 \ 0
0 \ 0 0 \ 0 0 \
8 0 \ -3 0 \ 8 0 \ -8 0 \ -6 0\ 1 0
Here the rearrangement happens in the first and last bin.
I gonna change my script in that way that I make the assumption that the
dataset is always sorted according to FactorA.
I think that should be fine.
In many contexts I guess this won't make any relevant
difference, but in some contexts it can. If it's important to
avoid reordering of elements that compare equal we can use a
fancier comparison function that looks at the addresses of the
elements when the values compare equal.
Allin Cottrell
_______________________________________________
Gretl-users mailing list
Gretl-users(a)lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-users
Attachments:
- attachment.html (text/html — 3.1 KB)