|
Thread Rules 1. This is not a "do my homework for me" thread. If you have specific questions, ask, but don't post an assignment or homework problem and expect an exact solution. 2. No recruiting for your cockamamie projects (you won't replace facebook with 3 dudes you found on the internet and $20) 3. If you can't articulate why a language is bad, don't start slinging shit about it. Just remember that nothing is worse than making CSS IE6 compatible. 4. Use [code] tags to format code blocks. |
On February 17 2017 12:11 Blisse wrote: -12 / 7 = 1 remainder -5
This part is incorrect because you used truncation division instead of Euclidian division. The remainder has to be between 0 and n-1.
The two definitions are equivalent.
|
Is anyone here Base SAS certified? I signed up to take the test and have studied a bit already.
|
edit:
ohhhh shit. i have no idea what is going on in my C program. this is weirdness I have not yet experienced in programming.
time to learn to debug I guess
edit2: if c is in an infite loop, is it normal for it to sit at an empty prompt asking for input for no reason? basically as though it was doing a scanf?
|
You're not making a lot of sense. When a process is running in your typical terminal, it will show an empty line until it's complete, you write something in the terminal, or the process writes something to stdout. There's no special interface for prompt. Why not test this yourself by writing one program with "while(1);" and one with "scanf("%d",&a);"?
|
I don't really mean a special interface. keep in mind I have no history with unix, I am not used to how you interact with the shell
it seemed very weird to me that i could sit there and type in spam and go to the new line over and over during the execution of my program
|
Yeah, all the text you enter goes into a buffer which either gets read by your process if you do read from STDIN, or is written to the terminal itself as if you wrote that after the process ended.
|
well, i successfully completed my first project a weekish early! yay (i worked really hard on it though) it was a bit harrowing C is a million times harder to debug than Java
|
one of my homeworks include implementing a pointer based list data structure (singly linked). i'm doing it in python.
while doing timing I noticed my delete was taking too long. the book we are using says it should take constant time which it wasn't.
I check and it makes sense because I was traversing the list for the previous node to have previous.next point to p.next (if p is the pointer given).
after googling, I found this which says it should be O(n) : https://www.codefellows.org/blog/implementing-a-singly-linked-list-in-python/ which was basically how it was working in my implementation.
what was given in my book basically goes like this (its in pascal but I"ll use pseudo code):
function delete (position) p=position p.next = p.next.next
and thats it lol. when using this version of delete, I get constant time but ofc it runs into issues when I try to delete from the back of the list which we are supposed to test as well.
the professor is asking for an implementation that does deletion in constant time but I don't think it's possible with the version the book references. i've already talked with the professor but seriously can't understand him and he didn't seem to understand me (he's an old russian guy and isn't very articulate).
do you guys see any flaws in my understanding of this or is the project asking for something stupid?
|
Which node are you actually deleting is probably where you're running into issues.
When you delete the final node in the list your pointer is at position p. p.next is the final node in the list and it's p.next.next value is null. When you set the node at position p's next value to null you're removing the last node in the list as expected and not causing a problem.
HEAD -> [1] -> [2] -> [3] -> [4] -> [5] -> [6] -> [7] -> null
So if I need to delete 7, I want to traverse the list until p.next == 7. p will be at 6. Then I set p.next equal to p.next.next. The resulting list:
HEAD -> [1] -> [2] -> [3] -> [4] -> [5] -> [6] -> null
Consider the difference between delete(value) and delete(pointer). In the latter you've already done the search which is causing the discrepancy. The delete(value) function runs in O(n) time because you must traverse the list to find the node. However, the function signature looks like you're telling it to delete a pointer after you've traversed the list making it a O(1) deletion time. There is no search in the pseudo code.
Same example, but with delete(pointer):
function delete(6) p=position p.next = p.next.next
p.next.next is null. Set p.next equal to null and node 7 is removed in constant time.
|
Is this the proper way to negate this statement?
statement: for all x, there exists y [x < y^2]
negation: for all y, there exists x [ x > y^2]
edit: it would be x >= y^2, huh
|
On February 18 2017 11:28 travis wrote: Is this the proper way to negate this statement?
statement: for all x, there exists y [x < y^2]
negation: for all y, there exists x [ x > y^2]
not (for all x, there exists y such that x < y^2)
there exists x, not (there exists y such that x < y^2)
there exists x, such that for all y, not (x < y^2)
there exists x, such that for all y, x >= y^2
the order is wrong and it's >=
|
the order matters?
I thought I remembered the professor saying the order matters for this, but when I conceptualized it I couldn't see the difference between
there exists x, such that for all y
and
for all y, there exists x
edit: ok nevermind after thinking it about it some more I do see the difference. in the 2nd statement it means that it is for all y this thing happens universally, and in the first one that isn't the case
thank you, Blisse
|
|
On February 18 2017 12:13 travis wrote: edit: ok nevermind after thinking it about it some more I do see the difference. in the 2nd statement it means that it is for all y this thing happens universally, and in the first one that isn't the case
Not sure what you mean by that, the 1st statement is stronger than the 2nd. (1) is false but (2) is true.
|
On February 18 2017 12:13 travis wrote: the order matters?
I thought I remembered the professor saying the order matters for this, but when I conceptualized it I couldn't see the difference between
there exists x, such that for all y
and
for all y, there exists x
edit: ok nevermind after thinking it about it some more I do see the difference. in the 2nd statement it means that it is for all y this thing happens universally, and in the first one that isn't the case
thank you, Blisse
I find it helpful to read the quantifiers out.
(1) for all y, there exists x [ x > y^2]
for every value of y, there is at least one value of x where x > y^2
(2) there exists x, such that for all y, x >= y^2
there is at least one value of x, where for every value of y it is true that x >= y^2
In this case it's clear that in (1) each y can map to a different x, whereas in (2) one x maps to all y.
|
On February 18 2017 10:49 Blitzkrieg0 wrote:Which node are you actually deleting is probably where you're running into issues. When you delete the final node in the list your pointer is at position p. p.next is the final node in the list and it's p.next.next value is null. When you set the node at position p's next value to null you're removing the last node in the list as expected and not causing a problem. HEAD -> [1] -> [2] -> [3] -> [4] -> [5] -> [6] -> [7] -> null So if I need to delete 7, I want to traverse the list until p.next == 7. p will be at 6. Then I set p.next equal to p.next.next. The resulting list: HEAD -> [1] -> [2] -> [3] -> [4] -> [5] -> [6] -> null Consider the difference between delete(value) and delete(pointer). In the latter you've already done the search which is causing the discrepancy. The delete(value) function runs in O(n) time because you must traverse the list to find the node. However, the function signature looks like you're telling it to delete a pointer after you've traversed the list making it a O(1) deletion time. There is no search in the pseudo code. Same example, but with delete(pointer): function delete(6) p=position p.next = p.next.next p.next.next is null. Set p.next equal to null and node 7 is removed in constant time.
Hi, thanks for this. So I guess my confusion comes from my 'end' function not really being the true end of the list.
For example on my list x: 1 -> 2 -> 3 -> 4
If I ask for x.end(), it will give me a pointer to 3 so I will have to do x.delete(end().next) for it to delete the last node properly.
It seems so unintuitive for me to have 'end' not really be the end of the list, but apparently it has to work that way for me to implement the rest of the functions the way the book wants it.
If I have 'end' return me a pointer to the actual last node with data in it, I can't delete the last node in constant time.
Is this correct?
edit:
I feel like this isn't quite correct either because it isn't consistent. If I have an empty list, end() will give HEAD. which is not the second to last in the list. so if I want to 'insert from the back' using end(), I would have to do x.insert(end()) for the first insertion instead of x.insert(end().next)
this seems like terrible practice.
edit2:
I'm still getting constant time for my results, but now that I think about it I guess it makes sense?
Because I'm using end() to delete from the back, which is O(n), the total time it takes to delete from the back of a list should take O(n) because of the traversal even if the deletion itself is O(1).
My traversal is basically p=p.next as long as p.next is not null.
my results on running tests on my implementation of a list with array, a list with pointers, and python default list:
traversal: all fairly similar but python>list w/ array>list w/ pointers insert in front: python> pointers >array(O(n)) insert in back: python > array > pointers(O(n)) delete from front: python > pointers > array(O(n)) delete from back: python > array > pointers(O(n))
seems fine? though I'm curious how python's default list is so much faster in every way possible
|
On February 18 2017 14:29 dsyxelic wrote:Show nested quote +On February 18 2017 10:49 Blitzkrieg0 wrote:Which node are you actually deleting is probably where you're running into issues. When you delete the final node in the list your pointer is at position p. p.next is the final node in the list and it's p.next.next value is null. When you set the node at position p's next value to null you're removing the last node in the list as expected and not causing a problem. HEAD -> [1] -> [2] -> [3] -> [4] -> [5] -> [6] -> [7] -> null So if I need to delete 7, I want to traverse the list until p.next == 7. p will be at 6. Then I set p.next equal to p.next.next. The resulting list: HEAD -> [1] -> [2] -> [3] -> [4] -> [5] -> [6] -> null Consider the difference between delete(value) and delete(pointer). In the latter you've already done the search which is causing the discrepancy. The delete(value) function runs in O(n) time because you must traverse the list to find the node. However, the function signature looks like you're telling it to delete a pointer after you've traversed the list making it a O(1) deletion time. There is no search in the pseudo code. Same example, but with delete(pointer): function delete(6) p=position p.next = p.next.next p.next.next is null. Set p.next equal to null and node 7 is removed in constant time. If I have 'end' return me a pointer to the actual last node with data in it, I can't delete the last node in constant time. Is this correct?
You could if you used a double linked list instead of a single linked list. That makes each position take up more space though since you have the element, pointer to next AND pointer to previous.
Basically a question of what action you will be performing on the list. If you add and remove at the start you don't even need an end pointer since you never need to find the last element (unless you use a check on it to see if it is the last element before doing first as null). LIFO / Stack is other terms for that type of list.
As for the rest, don't know about python so can't comment on its standard lists.
|
On February 18 2017 12:13 travis wrote: the order matters?
I thought I remembered the professor saying the order matters for this, but when I conceptualized it I couldn't see the difference between
there exists x, such that for all y
and
for all y, there exists x
edit: ok nevermind after thinking it about it some more I do see the difference. in the 2nd statement it means that it is for all y this thing happens universally, and in the first one that isn't the case
thank you, Blisse Try thinking of an example:
For all x there exists a y, such that x > y
Which one is the negation, and does the order make a difference? (1) Exists x such that for all y, x < y (2) For all x, there is a y, such that x < y
Well, let's start with the second one. Let's assume integers. Is there an integer that satisfies this condition? Yes. An example is x=4. We choose y=5 and our statement holds. However the problem is that the original statement also holds for integers. E.g. x=4 and y=3. So clearly (2) is not the negation of our original statement.
(1) says something different. It says that firstly, x is minimal and that that x exists in the set. This clearly doesn't hold for integers, because for any integer x, we can choose y=x-1, and invalidate that statement. So from an example, we can see we might be on the right track. Now let's try natural numbers. In this case, the original statement is false. Choose x=0, and you cannot find a y in N that satisfies x > y. Statement (1) still holds (statement (2) also holds, but we don't care).
Now normally you wouldn't go about it in this manner: you would simply use whatever formal system you're using to prove that (1) is the negation of the original statement (as Blisse already did), but when in doubt, filling in examples is a good way to understand what is going on.
Re Hahn: it's not true that (1) is a weaker or stronger version of (2). They say completely different things about the set. The original statement says there is no minimum element. (1) says there is a minimum element. (2) says nothing about minima, but instead says there is no maximum element. For instance, (1) is true for the set [0, 1,2], but (2) is not (and neither is the original statement).
|
On February 18 2017 16:12 Acrofales wrote: Re Hahn: it's not true that (1) is a weaker or stronger version of (2). They say completely different things about the set. The original statement says there is no minimum element. (1) says there is a minimum element. (2) says nothing about minima, but instead says there is no maximum element. For instance, (1) is true for the set [0, 1,2], but (2) is not (and neither is the original statement).
OK, but you misquoted me. I wasn't referring to these statements.
Travis:
there exists x, such that for all y
and
for all y, there exists x
Me:
Not sure what you mean by that, the 1st statement is stronger than the 2nd. (1) is false but (2) is true.
Do you disagree with me?
|
On February 18 2017 15:20 Yurie wrote:Show nested quote +On February 18 2017 14:29 dsyxelic wrote:On February 18 2017 10:49 Blitzkrieg0 wrote:Which node are you actually deleting is probably where you're running into issues. When you delete the final node in the list your pointer is at position p. p.next is the final node in the list and it's p.next.next value is null. When you set the node at position p's next value to null you're removing the last node in the list as expected and not causing a problem. HEAD -> [1] -> [2] -> [3] -> [4] -> [5] -> [6] -> [7] -> null So if I need to delete 7, I want to traverse the list until p.next == 7. p will be at 6. Then I set p.next equal to p.next.next. The resulting list: HEAD -> [1] -> [2] -> [3] -> [4] -> [5] -> [6] -> null Consider the difference between delete(value) and delete(pointer). In the latter you've already done the search which is causing the discrepancy. The delete(value) function runs in O(n) time because you must traverse the list to find the node. However, the function signature looks like you're telling it to delete a pointer after you've traversed the list making it a O(1) deletion time. There is no search in the pseudo code. Same example, but with delete(pointer): function delete(6) p=position p.next = p.next.next p.next.next is null. Set p.next equal to null and node 7 is removed in constant time. If I have 'end' return me a pointer to the actual last node with data in it, I can't delete the last node in constant time. Is this correct? You could if you used a double linked list instead of a single linked list. That makes each position take up more space though since you have the element, pointer to next AND pointer to previous. Basically a question of what action you will be performing on the list. If you add and remove at the start you don't even need an end pointer since you never need to find the last element (unless you use a check on it to see if it is the last element before doing first as null). LIFO / Stack is other terms for that type of list. As for the rest, don't know about python so can't comment on its standard lists.
Unfortunately as it is a school assignment we were told to follow the design of the example given in our CS book which in this particular case is a singly linked list.
Another part of the assignment is running time tests on our procedures. We had to test both insertion from the front and insertion from the back. Insertion from the back was giving me this issue regarding how to define end() and delete()
|
|
|
|