4 ms·

This is a strange complaint. Quicksort isn't stable in most implementations either. The docs are exactly where I'd look to see if a particular sort method was s

by rfrey 12y ago

This is a strange complaint. Quicksort isn't stable in most implementations either. The docs are exactly where I'd look to see if a particular sort method was stable... where else? I really don't mean to be condescending, but are you interpreting "stable" to mean "crash free"?

deleted 12y ago
[deleted]
benologist 12y ago
I don't think it is reasonable to blame me for encountering a bug in their code, the problem is in their code. Please read the success story - the person advocating for it describes plenty of time spent compensating for it for reasons much more diverse than this one example. This is a common experience - mentioned in several comments here too.
- jonasmalaco 12y ago
  Well, it simply isn't a bug. Most sort algorithms aren't stable, and the only thing a generic _sort_ algorithm is supposed to guarantee is a sorted output according to the comparison function you supply it with. If however the method was called "stableSort", the situation would be very different... The default Array.sort stability is inconsistent across targets _because_ guaranteeing it would prevent reusing implementations already available in the targets. And differently than what you claimed, many languages (and most Haxe targets) don't guarantee sort stability in their default "sort" APIs: C, C++, C#, JS, PHP and Neko. Also, any remark placed in the official api docs for "Array" or in that very module, just next to sort method, can't be said to be "buried" in the docs.
  - benologist 12y ago
    It is not important we agree on this being a bug or not. If you have had a smooth experience you don't have to look further than the linked success story to find a counter-example.
    - jonasmalaco 12y ago
      Respectfully, it is important to understand whether sort stability is as bug or not. Particularly since you seem to have experienced exceptions on Android, and assuming that the problem was in the sort stability may have mislead you.
      - benologist 12y ago
        It's still reproducible just by substituting the top function for the stable alternative we use: http://pastebin.com/D3S6SYBM http://pastebin.com/D3S6SYBM. Haxe 3.1.3 on OSX.
        jonasmalaco 12y ago
        Do you have the same problem with a deterministic comparison function? I'm not dismissing the existence of a bug just because of this (although the issue may be related to it), but non-deterministic comparison functions are problematic with many sort _algorithms_. You might experience (other) problems when using implementation independent "sort" APIs, since many algorithms need to rerun the comparison function several times and expect consistent behaviour; I would expect certain algorithms to, for instance, never complete.
        benologist 12y ago
        The haxe people are the ones you need to discuss it further with. My pastebin expires in a week so you might want to clone it before you link to it.
        jonasmalaco 12y ago
        Hm... No.
        deleted 12y ago
        [deleted]
        12y ago

by rfrey 12y ago

deleted 12y ago

[deleted]

benologist 12y ago

I don't think it is reasonable to blame me for encountering a bug in their code, the problem is in their code. Please read the success story - the person advocating for it describes plenty of time spent compensating for it for reasons much more diverse than this one example. This is a common experience - mentioned in several comments here too.

jonasmalaco 12y ago
Well, it simply isn't a bug. Most sort algorithms aren't stable, and the only thing a generic _sort_ algorithm is supposed to guarantee is a sorted output according to the comparison function you supply it with. If however the method was called "stableSort", the situation would be very different... The default Array.sort stability is inconsistent across targets _because_ guaranteeing it would prevent reusing implementations already available in the targets. And differently than what you claimed, many languages (and most Haxe targets) don't guarantee sort stability in their default "sort" APIs: C, C++, C#, JS, PHP and Neko. Also, any remark placed in the official api docs for "Array" or in that very module, just next to sort method, can't be said to be "buried" in the docs.
- benologist 12y ago
  It is not important we agree on this being a bug or not. If you have had a smooth experience you don't have to look further than the linked success story to find a counter-example.
  - jonasmalaco 12y ago
    Respectfully, it is important to understand whether sort stability is as bug or not. Particularly since you seem to have experienced exceptions on Android, and assuming that the problem was in the sort stability may have mislead you.
    - benologist 12y ago
      It's still reproducible just by substituting the top function for the stable alternative we use: http://pastebin.com/D3S6SYBM http://pastebin.com/D3S6SYBM. Haxe 3.1.3 on OSX.
      - jonasmalaco 12y ago
        Do you have the same problem with a deterministic comparison function? I'm not dismissing the existence of a bug just because of this (although the issue may be related to it), but non-deterministic comparison functions are problematic with many sort _algorithms_. You might experience (other) problems when using implementation independent "sort" APIs, since many algorithms need to rerun the comparison function several times and expect consistent behaviour; I would expect certain algorithms to, for instance, never complete.
        benologist 12y ago
        The haxe people are the ones you need to discuss it further with. My pastebin expires in a week so you might want to clone it before you link to it.
        jonasmalaco 12y ago
        Hm... No.
        deleted 12y ago
        [deleted]
        12y ago