in reply to Really slow sort, but useful.

I like the idea, but it has a couple of flaws. First off, it's quite possible for humans to give inconsistent choices, such that a>b && b>c && a<c. Obviously, such a set of choices will not give well-sorted output. Worse, it will cause a segfault with some perls. Secondly, it won't neccessarly give the same ordering that different pairs, or considering things in groups, would give, because humans aren't really exact in these things. Thirdly, in this purticular case, there's a fully automatic method you could use -- render the character to a bitmap of some sort, and take the mean color of the bitmap. (This has faults, though -- which is lighter, '-' or '!'. Since the bounding-box of the ! is tight, it's very dark. The bounding-box of the - is much looser, because bbs of chars are always computed as being a fixed height, so it's ratehr light. However, a human would probably call them about even.)

Warning: Unless otherwise stated, code is untested. Do not use without understanding. Code is posted in the hopes it is useful, but without warranty. All copyrights are relinquished into the public domain unless otherwise stated. I am not an angel. I am capable of error, and err on a fairly regular basis. If I made a mistake, please let me know (such as by replying to this node).

Replies are listed 'Best First'.
Re: Re: Really slow sort, but useful.
by BrowserUk (Patriarch) on Nov 29, 2002 at 05:21 UTC

    Dealing with the last point first. As the comparison was for a CLI, the bounding box are always the same as its fixed pitch fonts I'm dealing with. I did consider trying to grab bitmaps and determine it that way, but given that the use is for human perception rather than machine perception that is difficult. Even dealing with monochrome becomes dependant not just on the number of pels that are on relative to those off, it also depends on the concentration of those pels. It further depends on the way the pels in adjacent cells intereact.

    I found that but not trying to hard to judge it, but rather reacting to the obvious choices as appropriate and opting for "the same" whenever I didn't immediately perceive a difference, I ended up with a fairly good result. It probably wasn't perfect, but then no lives were dependant upon the accuracy of the conclusion:) For my purposes I only needed to grade them approximately as I then chose the two from the ends, space and #, and then 6 roughly evenly spaced throughout the range.

    I did find that it helped if I reduced the size of the font to the smallest available on my system (5pt Lucida TT or a 4x6 raster) as when I could no longer make out what the chars were and stopped trying to decide which was darker on the basis of logic and just went with my visual perception.

    Your right that humans aren't consistant, but that would always be true, regardless of the method used to marshall and record the decisions made.

    I have not been able to create a seg fault even when I just deliberately tried to make inconsistant decisions. I am unsure as to how that would occur? It's not like the sort would 'remember' my decisions, It's only ever comparing two values at a time?

    YMMV as they say:)... I wouldn't rely upon it for anything important, but it served it purpose.

    Okay you lot, get your wings on the left, halos on the right. It's one size fits all, and "No!", you can't have a different color.
    Pick up your cloud down the end and "Yes" if you get allocated a grey one they are a bit damp under foot, but someone has to get them.
    Get used to the wings fast cos its an 8 hour day...unless the Govenor calls for a cyclone or hurricane, in which case 16 hour shifts are mandatory.
    Just be grateful that you arrived just as the tornado season finished. Them buggers are real work.

[reply]
      Oh, sort does remember you choices. It's not that it keeps a record, but it is remembered in the way the data is shuffled around. Otherwise, there wouldn't be O (n log n) sorts.

      As for the segfaults, pre-5.6 perls used the qsort available in your C libraries. And that might segfault when given inconsistent choices. 5.6.x has its own quicksort, which will not segfault when given inconsistent choices. From 5.8 on, you can actually choice between mergesort (default) and quicksort.

      Abigail

[reply]
[d/l]
[select]

        I bow to your (and theorbtwo's) longer association with Perl. I wasn't exactly challenging theorbtwo's statement, just questioning how/why it would occur.

        I still have a problem conceiving of the circumstance that would cause the segfault though? Obviously the effect of your choices is retained, but at any given point, the sort algorithm ony has the state of the stack and two values to consider. I can see how the result could be a non-useful outcome of the sort, but can't see what would cause the segfault.

        I remember the recent thread where someone was using rand within sort to effect a shuffle. I assume that in pre-5.6 perls this would also have caused a problem? Though I don't recall mention of it at the time.

        Okay you lot, get your wings on the left, halos on the right. It's one size fits all, and "No!", you can't have a different color.
        Pick up your cloud down the end and "Yes" if you get allocated a grey one they are a bit damp under foot, but someone has to get them.
        Get used to the wings fast cos its an 8 hour day...unless the Govenor calls for a cyclone or hurricane, in which case 16 hour shifts are mandatory.
        Just be grateful that you arrived just as the tornado season finished. Them buggers are real work.

[reply]
[d/l]

In Section Cool Uses for Perl