Empty Set doesn't exist

If you cant sense it, then it doesnt exist.

You cant see emptiness, therefore emptiness doesnt exist.

>>119-120
I'll shut up, because you don't seem to understand some very simple concepts and there is no reason for me to waste my time on an argument which isn't ``even wrong''. As for scrubbing toilets, I thought that was your new job?

>>121
No, you clearly have no clue what you're talking about. The concept of "contract" comes from OOP. What I'm talking about extends to your non OOP languages.

So again, what happens if I do the following in the Java main() method...

for (int i = 0; i < mylist.length; i++) {
  int index = (int) (Math.random() * mylist.length)
}

Where is the "contract" in this case? Now what happens if I want to delete the 3rd item in this array. This means all the unordered numbers are in the same order up until the point in quesetion. What happens to the numbers after that? Exactly.

You don't know because you have zero fucking clue as to what you're talking about. Again, you're stupid. And again, you have no possible future as a computer programmer.

>>122
*until the point in question.*

>>122
So again, what happens if I do the following in the Java main() method...
for (int i = 0; i < mylist.length; i++) {
  int index = (int) (Math.random() * mylist.length)
}

Not the guy you're flaming but what happens is that you assign some int to index each iteration of the loop and do nothing with it and then the loop terminates.

>>122
The concept of "contract" comes from OOP. What I'm talking about extends to your non OOP languages.
It is used with that meaning in some OO languages, but what I was talking about is more general, for example, in more low-level languages like C or assembly, you could imagine a header file that states that some linked list or array is to be treated as unordered by all code and anyone depending on the ordering is doing so at his own risk (because other functions that operate with it may change it in ways which are not specified in this "contract"). In the context of programming, it's merely what a programmer promises about the behavior of the code he's written and what the intended usage is - the language is irrelevant.

I'm not entirely sure what the argument in the rest of the post is about, the java code you posted can be optimized away (to nothing) as the code does not change any state, nor does it return any values.

Again, you seem to be forgetting that this whole conversation was only tangentially related to programming and that some particular implementation of some concept isn't the same thing as the concept.

To better explain this, consider 2 examples:
1) Some programmer defined a file format or a network protocol and implemented it, the implementation is proprietary and closed-source, but some parts of the format(s) are freely available for all to see. His implementation is mostly correct, but in some cases, he made some mistakes which lead to his programs behaving a bit differently than he promised they would in the documentation - this isn't yet known to either him or the audience (such as the users of the programs). I notice some peculiarities in the way the program constructs the data (which is supposed to fit the official document), I then proceed to disassemble his closed-source software and I'm not aware of all kinds of implementation details that not even the author was aware of. I can now write a document describing exactly what the program does, not what the programmer intended for the program to do. I can also point out how the "is" differs from the "should" in this particular case. A lot of programming bugs happen when one confuses the should with the is. There's many deeper questions about should vs is, outside the programming-related meaning I just explained, but I'll stop because it would be widely off-topic.
2)Numbers define progressions. In some interpretation I could use sticks to talk about natural numbers, in another I could use a Turing Machine to encode them, in another I could use C, Lisp, Java, whatever works. In a less usual interpretation I could even consider non-standard numbers which represent infinite quantities, yet still obey Peano's Axioms, but are most certainly not what one means by the "standard interpretation" of arithmetic. They are all valid interpretations that match a valid "contract" (in this case some axioms), but they are also very different things, some so different that even different properties and truths are possible, while still matching the "contract".

>>124
Right. But the point is that each element in this array now has some random number. These random numbers may or may not be in any kind of order. Now the problem arises when I want to delete say, the third item in this array.

What happens to all the random numbers after the deletion? Do I preserve the preexisting order of all the random numbers or not? Exactly.

s/I'm not aware of all kinds of implementation details/ I'm now aware of all kinds of implementation details//

>>125
>you could imagine a header file that states that some linked list or array is to be treated as unordered by all code and anyone depending on the ordering is doing so at his own risk (because other functions that operate with it may change it in ways which are not specified in this "contract").

A linked list preserves an order of a list. Even if the items in that list are unordered. Cripes, get a freaking data structures book and look how insert() and deletion() are done on the list.

*and look at how*

>>128
I know very well how a linked list works, or how an array or various other more complex data structures work. That is however irrelevant as far as what one promises to do with some particular data structure. I could easily imagine someone who instead of inserting an element on the head of a linked list (O(1)) decides to insert the element in the middle or at the end (up to O(n), where n is the length of the list) - this isn't about efficiency, but about how someone - anyone - uses your data. For a programmer such as yourself that seems to pride himself in working in an ENTERPRISE, you sure know very little about keeping your own code abstracted and separate from other people's code as well as respecting their own contracts and expecting them to respect your own contracts.

>>130
The order of the list depends on the abstract data type you fag. What happens if the ADT is a Linked List? Then the order of the list would have to be preserved when I do operations line insert() and delete(). Now whast happens if the ADT is a bag? Then I don't have to work about the order being preservd when doing stuff like insert() and delete().

>>131
*Then I don't have to worry*

>>130
With that, what I was trying to point out is that sometimes you have to preserve the order of an unordered list.

>>131,133
Only if you're directly working with it and not through some other interface. It of course makes sense when you are the one writing the implementation.
>>133
In set theory, when someone wants order in an unordered set they can just make a set of ordered pairs, in the sense:
ordered {a,b,c} - would be {(1,a),(2,b),(3,c)}, of course this isn't that much different from just defining a function f:{1,2,3}->{a,b,c}.

>>134
It's pretty much a no brainer to convert an exisiting list to a set. Seriously. All I would have to do is something like...

for(int i = 0; i < size; i++) {
    if(!newList.contains(data[i])) {
        newList.add(data[i]);
    }
}

>>135
Yup, gotta keep one step ahead of the filters by changing my name ).

>>135
Now what gets kind of interesting is when I don't know the exact size. How would I remove all the duplicate items in this set? In other words, OMFG, could it be. Yes. There is a finite set of duplicate items in an uncountable set!

>>126
So what you meant was

for (int i = 0; i < mylist.length; i++) {
  int index = (int) (Math.random() % mylist.length) // * -> %
  mylist[index] = i;
}

or

for (int i = 0; i < mylist.length; i++) {
  int index = (int) (Math.random() * mylist.length)
  mylist[i] = index;
}

something to that effect?

Kodak seems happy today, less insults than usual.

>>139
He got his toilet scrubbed today.

>>140
Sounds lemony fresh.

>>140
I wonder if he ever thinks about /prog/ when he meets the person who scrubs his toilets.

>>135
not pythonic

>>138
Yeah. The point is you don't need any kind of "contract". Now I'm suspecting that the minimum wage idiot who wrote this was buzzing from the pinesol or whatever else the janitors use these days.

>>144
I didn't read any of the other crap you or any of the other people wrote, I'm a programmer so I looked at the code, it's the only thing that interests me.

>Unordered set

>delete third item

Nope

>Unordered set

>Array full of randoms

Still nope (It still has a defined order)

>>146
Have you ever written a single line of code in your entire life you idiot? Probably not. Here's an example from work you dumb mental midget. I want to delete an item from the array. The ADT is such that I don't care about the order.

The list looks something like the following

[doug, alice, nancy, ted, vandee, sue]

Now I want to remove alice from the list. Since I don't care about order, I can just move sue to alice's spot and then put null in sue's place. After this happens, the list looks like

[doug, sue, nancy, ted, vandee, null]

Now what happens if I would have imposed a defined order? Well you stupid fuck, the list would have been

[doug, nancy, ted, vandee, sue, null]

Now shut up and go scrub another toilet.

>>146
And of course this would have been easy to see if you would have written some actual code instead of "googling" shit. Oh wait, you're too fucking stupid to code. That's why you work as a janitor!

printf('wonder if kodak looks sexy when she mad...');

|| [doug, sue, nancy, ted, vandee, null]

showing order of unordered sets ^^ so clever! =)

>>149
pull my finger

>>149
And look ma, there is no "contract" involved!

All computerized sets would be 'ordered implementations of unordered sets' ^^ i win

you could delete the third item in the 'ordered imp.', but the third item in an unordered set should be undefined

btw does that mean you is a girl?
(if so Can i ask is index finger longer than ring finger...?)

>>150-151
mailto:sage
What the fuck did just happen?

>>152
The are certain situations when you would want do have null in a list, instead of say, at the end of it.

>>153
Dis just happen.

>>125
implementation of some concept isn't the same thing as the concept.
Please, "implement" the concept of "God" or the concept of "Infinity".

I see it as nonsense to talk about concept without prior implementation.

>>125
programmer defined a file format or a network protocol and implemented it, the implementation is proprietary and closed-source,
You can reverse engineer it.

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　

>>156

Concept implemented as a concept ^^

also, implement implemented as a concept ^^

btw crazy sexy cool >now maps to> mad sexy kodak

can i get a picture as proof of concept? ^^