Array.Sort() problem

BlitzMax Forums/BlitzMax Programming/Array.Sort() problem

Suco-X(Posted 2006) [#1]
Hi
This small code shows you the problem. I need an array that can have "null" fields. I get an error with Array.Sort().
What can I do?
Thanks.

Strict 

Type TTemp
End Type

Local Temp:TTemp[10]
Temp.Sort()


Dont forget, I need an Array, no Lists.
Mfg Suco


FlameDuck(Posted 2006) [#2]
What can I do?
Implement your own sorting algorithm. Since Null objects cannot sensibly be said to be less than or greater than any 'other' objects, sorting them is meaningless.


Koriolis(Posted 2006) [#3]
Just to nitpick, I have to disagree. What if two instances compare equal? Then they will just be side by side once sorted. Sort could very well do the same for Null references: they could end up side by side in the final sorted array (say at the start or end. It just *happens* that it's not done like that.


FlameDuck(Posted 2006) [#4]
Sort could very well do the same for Null references: they could end up side by side in the final sorted array
Yes, you could in theory make a sort routine that would sort an entire array of Null objects. But there would be little point as the array would already, by definition, be sorted.

(say at the start or end.
So which is it, and what mathematical basis do you have for putting "Null" as the absolute highest value possible, or the absolute lowest value possible?

It just *happens* that it's not done like that.
Yes, but it happens for a reason. That reason happens to be because Null is undefined, and thus ordering it in relation to defined objects is meaningless. Kind of like how you can't tell if sqrt(-1) (or i or j depeding on which notation you prefer) is higher than 0 or lower than 0. It simply isn't meaningful to compare imaginary, and non-imaginary numbers.


Koriolis(Posted 2006) [#5]
<super nitpick mode on>
Yes, you could in theory make a sort routine that would sort an entire array of Null objects. But there would be little point as the array would already, by definition, be sorted.
I will pretend I really think you just misunderstood. I wasn't talking about sorting an array with only null references. I was talking about the orginal poster's issue : an array which *can* contain null references.

So which is it, and what mathematical basis do you have for putting "Null" as the absolute highest value possible, or the absolute lowest value possible?
This would obviously be arbitrary (but to answer I'd put it at the end). In any case that would rarely be worse than a null pointer exception don't you think?

Yes, but it happens for a reason.
Indeed. And I do think it's good as it is.
That reason happens to be because Null is undefined,
Undefined? Explain me that.
It simply isn't meaningful to compare imaginary, and non-imaginary numbers.
Totally true. But to come back to the null reference issue, when do you need to compare a null value to a real instance when sorting an array that may contain null refernces? Never. So that's not an issue.
Really, the only issues are that not treating null values as an error when sorting an array could potentially delay the detection of a program error, and that it would add some (though negligible) overhead.

Just as a record, my nitpick was about that sentence:
Since Null objects cannot sensibly be said to be less than or greater than any 'other' objects, sorting them is meaningless.
There is placce for nitpicking because what is actually sorted is an array of *references* to objects. Not an array of objects. That's some subtle difference. It just happens that (quite logically) the references to real objects (ie non null) is done based on the object's value.

The problem is the language/compiler (as it is) cannot possibly know if a given references is supposed to always point to a real object, or could if it is semantically correct for it be Null. This knowledge is all in the programmer's head and nowhere else.
Same for an array of references, which means that Sort cannot possibly "guess" what to do with null references.

Now let's be clear, the real intent of Sort (from mark's point of view) is certainly to only sort containers of non null references. That's Mark's design choice, that would also probalby be my design choice, and the one of most sensible people (as there are pretty few uses of keeping null values). But the other choice is not totally stupid/unsensible either.
</super nitpick mode on>
I probably beaten my own nitpick record here.


Dreamora(Posted 2006) [#6]
Problem with your thinking how it should work: It is simply not OO.

In OO the sorting is done using a compare method and the problem is that a NULL object can't be used to call its NULL method.

In theory you could work around that by simply bubblesort NULL objects up until the next non-NULL appears ... but thats quite ineffective if half of the array is NULL

If you want something like this with NULLs you better use TList ... there no NULLs exist and for sorting you can get an array from it, sort this and make a TList out of it again (there are given functions within TList for both conversion steps)


N(Posted 2006) [#7]
In theory you could work around that by simply bubblesort


You sicken me...

On another note: http://blitzbasic.com/codearcs/codearcs.php?code=1601


Dreamora(Posted 2006) [#8]
Does this take user defined compare methods into account? (don't think as it is a c wrapper and thus sorts the pointer values instead of the actual objects or am I wrong?)


ImaginaryHuman(Posted 2006) [#9]
Why would your array have null objects and some non-null objects? Maybe you can extra the non-null objects to a second array and sort that?


N(Posted 2006) [#10]
Does this take user defined compare methods into account? (don't think as it is a c wrapper and thus sorts the pointer values instead of the actual objects or am I wrong?)


If you'd actually looked you'd see that it did.


Koriolis(Posted 2006) [#11]
And if he had read anything he wouldn't even have posted that first reply. "It's simply not OO" *sigh*
Well we all post without really thinking at one moment or another.


Dreamora(Posted 2006) [#12]
I checked the link Noel.
But the code there does not show the implementation and I don't download modules I don't need so the next time you want to show something show it or let it ... links to links to downloads are not really that usefull for showing how something could be done!


Koriolis(Posted 2006) [#13]
Well maybe you should have a new look at it. You have the source code.
Hint: "cmpObj".

EDIT: I see where this is going, it's going toward the harsher side and I don't quite like that. I think I'll move on and leave this thread.
Then again, phrases like "problem with your thinking..." followed by nonsense are quite amusing.
EDIT2: @ Noel: in cmpObj you probably meant to do "If Not c And Not d" rather than "If Not (c And d)".


FlameDuck(Posted 2006) [#14]
Undefined? Explain me that.
An object is defined by three things. Identity, State, and Behavior. Null objects have neither of these, thus from an OO perspective they are undefined.

In OO the sorting is done using a compare method and the problem is that a NULL object can't be used to call its NULL method.
That's just a matter of language syntax. You could have a rule that stated that the default way of comparing objects was by comparing addresses. Thus any Null objects would have the value '0'. Ofcourse this would mean that all Null objects would get sorted to the front of the array, and since I generally agree with Koriolis' assertion that it's more useful to have Null objects at the end of the array, well that's hardly ideal either.

But the other choice is not totally stupid/unsensible either.
I didn't mean it in that way. I meant that comparing Null objects to real objects is meaningless (and thus has to be defined by an arbitrary rule), not that there wheren't valid reasons for hanging on to Null objects.


N(Posted 2006) [#15]
@ Noel: in cmpObj you probably meant to do "If Not c And Not d" rather than "If Not (c And d)".


Woops, yeah. That's what I get for posting code at 1am. Thanks :)