in reply to Re: Really slow sort, but useful.
in thread Really slow sort, but useful.

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.

Replies are listed 'Best First'.
Re: Really slow sort, but useful.
by Abigail-II (Bishop) on Nov 29, 2002 at 10:20 UTC
    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

      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.

        Internally, in the C library, the qsort routine is working with pointers, and lots of them. You may think all the world is a stack, but in reality, it isn't. It's C, it's pointers, and the comparison function is assumed to behave. Of course you'll run the risk of following a pointer to no-no land if the function doesn't behave. C isn't Perl.

        Abigail