People should just read the article. Or the others like it.
edit: The confusion on calling them "references" yeah, that's the main reason why people have trouble with this.
We were closer than I think you realize. Bear in mind that the semantics for "pass by value" may change. When you do
MyObject x = new MyObject(stuff...)
someMethod(x)
There is no guarantee that x is heap allocated, which means that there is a chance that when you say it is passed by value, the entirety of a MyObject may be copied onto the stack for the call. This is what most languages refer to when they say there is pass by value. That the entire value is copied on the stack for the call. Now, what you can not do, is promote x into the value of another reference. If you could do that, along with pointer manipulation, then a swap is suddenly possible. With or without pass by reference semantics.
People should just read the article. Or the others like it.
edit: The confusion on calling them "references" yeah, that's the main reason why people have trouble with this.
We were closer than I think you realize. Bear in mind that the semantics for "pass by value" may change. When you do
MyObject x = new MyObject(stuff...)
someMethod(x)
There is no guarantee that x is heap allocated, which means that there is a chance that when you say it is passed by value, the entirety of a MyObject may be copied onto the stack for the call. This is what most languages refer to when they say there is pass by value. That the entire value is copied on the stack for the call. Now, what you can not do, is promote x into the value of another reference. If you could do that, along with pointer manipulation, then a swap is suddenly possible. With or without pass by reference semantics.
No, you're still not getting it.
You called the function by value. What you do after that is after the passing, so it is no longer pass-by-anything.
Pass-by is the style of parameter passing and nothing else.
You called the function by value. What you do after that is after the passing, so it is no longer pass-by-anything.
Pass-by is the style of parameter passing and nothing else.
Huh? I think you are purposefully thinking I am saying something I am not. Consider, even with a "by reference" passing scheme, without pointer manipulation, no swap is possible. There is nothing magical about passing a reference that makes swap possible.
The entire subject of pass by value and pass by reference, is what is copied onto the call stack. Primitives are copied on the call stack. Pointers to objects are copied onto a call stack. This isn't required and could change. It could be that the entirety of the object is copied onto the call stack, and the variable that you use in your method actually points directly at the stack. This is what happens on primitives. For objects, all pointers point towards the heap.
You called the function by value. What you do after that is after the passing, so it is no longer pass-by-anything.
Pass-by is the style of parameter passing and nothing else.
Huh? I think you are purposefully thinking I am saying something I am not. Consider, even with a "by reference" passing scheme, without pointer manipulation, no swap is possible. There is nothing magical about passing a reference that makes swap possible.
The entire subject of pass by value and pass by reference, is what is copied onto the call stack. Primitives are copied on the call stack. Pointers to objects are copied onto a call stack. This isn't required and could change. It could be that the entirety of the object is copied onto the call stack, and the variable that you use in your method actually points directly at the stack. This is what happens on primitives. For objects, all pointers point towards the heap.
You're explaining it fine, what you're saying is wrong. You say pass-by-value depends, it doesn't.
All parameters are put on the stack, because they're pass-by-value. It really doesn't matter if that is a primitive or a pointer.
edit: quoting the part so you can see what is wrong, I'm not putting words in your mouth.
You called the function by value. What you do after that is after the passing, so it is no longer pass-by-anything.
Pass-by is the style of parameter passing and nothing else.
Huh? I think you are purposefully thinking I am saying something I am not. Consider, even with a "by reference" passing scheme, without pointer manipulation, no swap is possible. There is nothing magical about passing a reference that makes swap possible.
The entire subject of pass by value and pass by reference, is what is copied onto the call stack. Primitives are copied on the call stack. Pointers to objects are copied onto a call stack. This isn't required and could change. It could be that the entirety of the object is copied onto the call stack, and the variable that you use in your method actually points directly at the stack. This is what happens on primitives. For objects, all pointers point towards the heap.
You're explaining it fine, what you're saying is wrong. You say pass-by-value depends, it doesn't.
All parameters are put on the stack, because they're pass-by-value. It really doesn't matter if that is a primitive or a pointer.
What I am saying, is that there is no guarantee that what is copied to the call stack is a reference to your object. Work is being done to make it so that the object itself is allocated on the stack and possibly copied in full in the call stack. This has the advantage of preventing a lock on the heap for garbage collection. If Java had introduced value objects, then this would be the default for value objects, but they did not. (Thankfully.)
Edit: In other words, "pass by value" does not depend. But what is actually being copied as the "value" does. That make sense?
What I am saying, is that there is no guarantee that what is copied to the call stack is a reference to your object.
I'm not saying you're stupid, you appear far from it. Which is why I say you seem to not be "getting it" because pass-by doesn't give a damn if it's a pointer or not, it's not what the discussion is about let alone needing any guarantees.
What I am saying, is that there is no guarantee that what is copied to the call stack is a reference to your object.
I'm not saying you're stupid, you appear far from it. Which is why I say you seem to not be "getting it" because pass-by doesn't give a damn if it's a pointer or not, it's not what the discussion is about let alone needing any guarantees.
I think I see the confusion. When I say it "depends" I mean it depends in Java semantics. What is copied to the stack "depends" on several things in Java. That make sense? And again, this is all fairly new. Used to be, when you made a call in java, what was copied to the call stack was the value of the reference to the object. Now, it could actually be that object. Nothing changes, in that you still can't write a swap method, but it gets trickier to describe. You can no longer say "when making a function call in java, what is copied to the call stack are primitive values and pointer values."
Edit: I think this does a decent job explaining the distinction.
Used to be, when you made a call in java, what was copied to the call stack was the value of the reference to the object. Now, it could actually be that object.
Where can you actually copy the object directly at all in Java? Because you always work with references (pointers) so you don't even have the option afaik.
See the balloon analogy at http://www.yoda.arachsys.com/java/passing.html also at that site, you can't directly access (touch) a balloon so you're always dealing with the strings tied to them. How do you propose that you are actually touching the balloon?
Used to be, when you made a call in java, what was copied to the call stack was the value of the reference to the object. Now, it could actually be that object.
Where can you actually copy the object directly at all in Java? Because you always work with references (pointers) so you don't even have the option afaik.
See the balloon analogy at http://www.yoda.arachsys.com/java/passing.html also at that site, you can't directly access (touch) a balloon so you're always dealing with the strings tied to them. How do you propose that you are actually touching the balloon?
Right, that was why I tried to emphasis the lack of reference manipulation and no way to promote/create a reference to a reference.
My whole point being, if you are writing java, you shouldn't care what the pass by semantics are. Simply knowing that there is no reference manipulation and no references to references is enough. If you want to be able to do anything that requires those, you have to explicitly code it in your object representations. Knowing the actual call structure is important for the JVM people, but should be far from it for most programmers.
Used to be, when you made a call in java, what was copied to the call stack was the value of the reference to the object. Now, it could actually be that object.
Where can you actually copy the object directly at all in Java? Because you always work with references (pointers) so you don't even have the option afaik.
See the balloon analogy at http://www.yoda.arachsys.com/java/passing.html also at that site, you can't directly access (touch) a balloon so you're always dealing with the strings tied to them. How do you propose that you are actually touching the balloon?
Right, that was why I tried to emphasis the lack of reference manipulation and no way to promote/create a reference to a reference.
My whole point being, if you are writing java, you shouldn't care what the pass by semantics are. Simply knowing that there is no reference manipulation and no references to references is enough. If you want to be able to do anything that requires those, you have to explicitly code it in your object representations. Knowing the actual call structure is important for the JVM people, but should be far from it for most programmers.
The original point was that you can't do a swap(a, b) in Java because there is no pass-by-reference and people were very muddied on that.
I'm curious what you were referencing with actually passing the entire object on the call, since that doesn't seem possible given Java's object handling nor ever necessary.
I think he's saying that the Java standard doesn't specify the mechanics of passing objects into functions, so they could copy the objects when they're passed in.
I doubt that's true though... It would break a lot of stuff if it were true.
Used to be, when you made a call in java, what was copied to the call stack was the value of the reference to the object. Now, it could actually be that object.
Where can you actually copy the object directly at all in Java? Because you always work with references (pointers) so you don't even have the option afaik.
See the balloon analogy at http://www.yoda.arachsys.com/java/passing.html also at that site, you can't directly access (touch) a balloon so you're always dealing with the strings tied to them. How do you propose that you are actually touching the balloon?
Right, that was why I tried to emphasis the lack of reference manipulation and no way to promote/create a reference to a reference.
My whole point being, if you are writing java, you shouldn't care what the pass by semantics are. Simply knowing that there is no reference manipulation and no references to references is enough. If you want to be able to do anything that requires those, you have to explicitly code it in your object representations. Knowing the actual call structure is important for the JVM people, but should be far from it for most programmers.
The original point was that you can't do a swap(a, b) in Java because there is no pass-by-reference and people were very muddied on that.
I'm curious what you were referencing with actually passing the entire object on the call, since that doesn't seem possible given Java's object handling nor ever necessary.
Right... I can not but confess I complicated things irritably*. Apologies to everyone reading.
You can do basic escape analysis in java 1.6. "-XX:+DoEscapeAnalysis " This does not do anything for method calls, though. My understanding from stuff I recall, but not from where, is that they are looking to increase the scope that this can work on to catch more and more short lived objects. It makes things much easier for the garbage collector.
*I can also confess to possibly have misused some terms. Brevity of forum posts really drains my abilities. I have a ton of respect for people that are fast at posting, and typically accurate.
I think he's saying that the Java standard doesn't specify the mechanics of passing objects into functions, so they could copy the objects when they're passed in.
I doubt that's true though... It would break a lot of stuff if it were true.
I think he's saying that the Java standard doesn't specify the mechanics of passing objects into functions, so they could copy the objects when they're passed in.
I doubt that's true though... It would break a lot of stuff if it were true.
What would it break?
If you could bypass Java's reference system and access objects directly, you could break garbage collection for one.
And basically "break" it in the way that C can break things out of careless pointer manipulation.
I think he's saying that the Java standard doesn't specify the mechanics of passing objects into functions, so they could copy the objects when they're passed in.
I doubt that's true though... It would break a lot of stuff if it were true.
What would it break?
It would break things that are expecting a passed pointer. For example,
public class lol {
public static void main(String[] args) {
SomeClass lol = new SomeClass("foo");
method(lol);
System.out.println(lol.field);
}
protected static void method(SomeClass a) {
a.field = "bar";
}
}
class SomeClass {
String field;
SomeClass(String field) {
this.field = field;
}
}
This prints "bar". If it had copied the SomeClass object, it would print "foo".
I think he's saying that the Java standard doesn't specify the mechanics of passing objects into functions, so they could copy the objects when they're passed in.
I doubt that's true though... It would break a lot of stuff if it were true.
What would it break?
If you could bypass Java's reference system and access objects directly, you could break garbage collection for one.
And basically "break" it in the way that C can break things out of careless pointer manipulation.
That is only true if you can manipulate the references. Just because they could live elsewhere doesn't change much. You should never rely on any knowledge of where an object is. Though, as you can see, if you can set it up so that the objects are not heap allocated, you can get a speed increase. Optimization caveats and all of that.
you can tell it's pass-by-value because if you have
public class lol {
public static void main(String[] args) {
String foo = "foo";
method(foo);
System.out.println(foo);
}
protected static void method(String foo) {
foo = "bar";
}
}
it would print "foo", not "bar". If it were pass-by-reference, it would print "bar".
Your example is correct, but with your comment I'm not sure you understand what is actually happening here.
The "bar" creates an explicit 2nd string and stores it's address in the foo(local) reference, which so far was storing the address of the "foo" object.
The JVM does not even know what a "value" is with regard of variables.
Edit: Assuming it is, it's the reference that is being passed by value, not the object. It's not internally equivalent to the pass by value used in languages that create a copy of the instance.
I think he's saying that the Java standard doesn't specify the mechanics of passing objects into functions, so they could copy the objects when they're passed in.
I doubt that's true though... It would break a lot of stuff if it were true.
What would it break?
It would break things that are expecting a passed pointer. For example,
Which is why we are lucky that we can take advantage of the fact that it is a VM. You don't write code expecting values or references, because the actual details of function calls are not visible in your code. The VM can change some details as it runs. So, you simply know that in the confines of running your method, you are manipulating some variables. Whether those variables are stack/heap based/etc is an implementation detail.
you can tell it's pass-by-value because if you have
public class lol {
public static void main(String[] args) {
String foo = "foo";
method(foo);
System.out.println(foo);
}
protected static void method(String foo) {
foo = "bar";
}
}
it would print "foo", not "bar". If it were pass-by-reference, it would print "bar".
Your example is correct, but with your comment I'm not sure you understand what is actually happening here.
The "bar" creates an explicit 2nd string and stores it's address in the foo(local) reference, which so far was storing the address of the "foo" object.
That's exactly my point. The foo is a local variable, and has no attachment to the variable that was passed in (except that at the start of "method" it points to the same thing). If it were pass-by-reference, then modifying the address of foo (to wherever "bar" is stored) would modify the version in main as well.
The JVM does not even know what a "value" is with regard of variables.
I'm not sure what you mean by this? Certainly it does, in the sense that the value of every variable (primitive and object) is stored somewhere. It's just a question of whether you have access to it or not.
Edit: Assuming it is, it's the reference that is being passed by value, not the object. It's not internally equivalent to the pass by value used in languages that create a copy of the instance.
I think the clearest way to think about it, is that whenever you see
Object someObject = ...;
that is translated to
Object* someObject = ...;
and someObject.method() is translated to someObject->method().
you can tell it's pass-by-value because if you have
public class lol {
public static void main(String[] args) {
String foo = "foo";
method(foo);
System.out.println(foo);
}
protected static void method(String foo) {
foo = "bar";
}
}
it would print "foo", not "bar". If it were pass-by-reference, it would print "bar".
Your example is correct, but with your comment I'm not sure you understand what is actually happening here.
The "bar" creates an explicit 2nd string and stores it's address in the foo(local) reference, which so far was storing the address of the "foo" object.
That's exactly my point. The foo is a local variable, and has no attachment to the variable that was passed in (except that at the start of "method" it points to the same thing). If it were pass-by-reference, then modifying the address of foo (to wherever "bar" is stored) would modify the version in main as well.
The problem comes in explaining how mutable types fit with this. Consider:
public class lol {
public static void main(String[] args) {
StringBuffer foo = new StringBuffer();
method(foo);
System.out.println(foo);
}
protected static void method(String foo) {
foo.append("bar");
}
}
Why is it the change there is visible? Has very little to do with by-value and by-reference. Especially considering the fact that if you simply moved the contents of "method" into "main" in either case, nothing changes of the outcomes.
Edit: Assuming it is, it's the reference that is being passed by value, not the object. It's not internally equivalent to the pass by value used in languages that create a copy of the instance.
I think the clearest way to think about it, is that whenever you see
Object someObject = ...;
that is translated to
Object* someObject = ...;
and someObject.method() is translated to someObject->method().
etc, etc.
But this is where I was saying confusion comes in. This is not at all guaranteed. As shown by the escape analysis optimizations, the very existence of "someobject" may be eliminated and all of the values it would have held can be essentially created as local values for the method.
Now, this is all completely invisible to the programmer.
And I get what it actually means. But I don't know exactly what I'm supposed to be doing to check the invariant. Is it an actual condition I MAKE, or is it a variable?
What is the actual question you are looking at? I know I said it earlier, but usually identifying loop invariants is simply a way to optimize said loops.
Ah, I see I was wrong in what you were even referring to. My apologies.
The wikipedia article does a job of explaining loop invariants. I'm curious what the question you are being asked specifically is.
Edit: Actually, I am not sure I was off on what you were originally referring to. It seems that you are basically using a logic language to describe the following:
for (i = 0; i < n; ++i) {
x = y + z;
a[i] = 6 * i + x * x;
}
You could write the above as follows:
x = y + z;
for (i = 0; i < n && (x==y+z); ++i) {
x = y + z;
a[i] = 6 * i + x * x;
}
Nothing has changed in that code now, the same results will result. You can then flat out remove the x=y+z from the loop altogether.
I'm starting to warm to indents in Python. Now how do I strip stuff out of a string?
I've got a thread or post ID coming in from a form that's always supposed to be an int. I tried casting using int(), but it fusses if there's anything other than numbers in there. Everything I'm reading about int() says that it's supposed to extract the number from the string, but it's not. I thought about RegEx, but it and I have never seen eye to eye. I should probably learn it.
Oh hey, am I too late? Well, if we want to add another language to the OP, here it is. Ruby is my "main" language now, in that it is what pays the bills, so I figure that's what I'll talk about if people have questions.
Language: Ruby
Frameworks: Are for sissies, but Rails and Sinatra
Purpose: Web Programming and Server Scripting
Ruby is Perl for Human Beings. It has an extremely flexible syntax with incredibly powerful metaprogramming elements. While you can write Ruby code however you want, generally there is a "Ruby Way" to do something in an elegant manner. With everything truly being an object, one is able to really use the flexibility of OO to keep yourself DRY. With the heavy community emphasis on testing and the ability to easily fit into other agile practices, it has become quite popular with the whole Agile Development crowd.
Rails is the behemoth MVC web framework that does everything. Yes, even that. It is great for getting an application up off the ground quickly, and provides all the tools you need to continue to grow it. It is *very* opinionated about how to do business, and if you follow along your life is super easy. While they aren't bad rules to follow, if you aren't used to working exactly the Rails way, you may find yourself uncomfortable.
Sinatra is a super lightweight web framework that does nothing more than allow you to make an application that responds to web requests. It works well for light sites, services, or if you want to make your own framework.
Posts
We were closer than I think you realize. Bear in mind that the semantics for "pass by value" may change. When you do
There is no guarantee that x is heap allocated, which means that there is a chance that when you say it is passed by value, the entirety of a MyObject may be copied onto the stack for the call. This is what most languages refer to when they say there is pass by value. That the entire value is copied on the stack for the call. Now, what you can not do, is promote x into the value of another reference. If you could do that, along with pointer manipulation, then a swap is suddenly possible. With or without pass by reference semantics.
No, you're still not getting it.
You called the function by value. What you do after that is after the passing, so it is no longer pass-by-anything.
Pass-by is the style of parameter passing and nothing else.
Huh? I think you are purposefully thinking I am saying something I am not. Consider, even with a "by reference" passing scheme, without pointer manipulation, no swap is possible. There is nothing magical about passing a reference that makes swap possible.
The entire subject of pass by value and pass by reference, is what is copied onto the call stack. Primitives are copied on the call stack. Pointers to objects are copied onto a call stack. This isn't required and could change. It could be that the entirety of the object is copied onto the call stack, and the variable that you use in your method actually points directly at the stack. This is what happens on primitives. For objects, all pointers point towards the heap.
You're explaining it fine, what you're saying is wrong. You say pass-by-value depends, it doesn't.
All parameters are put on the stack, because they're pass-by-value. It really doesn't matter if that is a primitive or a pointer.
edit: quoting the part so you can see what is wrong, I'm not putting words in your mouth.
What I am saying, is that there is no guarantee that what is copied to the call stack is a reference to your object. Work is being done to make it so that the object itself is allocated on the stack and possibly copied in full in the call stack. This has the advantage of preventing a lock on the heap for garbage collection. If Java had introduced value objects, then this would be the default for value objects, but they did not. (Thankfully.)
Edit: In other words, "pass by value" does not depend. But what is actually being copied as the "value" does. That make sense?
I'm not saying you're stupid, you appear far from it. Which is why I say you seem to not be "getting it" because pass-by doesn't give a damn if it's a pointer or not, it's not what the discussion is about let alone needing any guarantees.
I think I see the confusion. When I say it "depends" I mean it depends in Java semantics. What is copied to the stack "depends" on several things in Java. That make sense? And again, this is all fairly new. Used to be, when you made a call in java, what was copied to the call stack was the value of the reference to the object. Now, it could actually be that object. Nothing changes, in that you still can't write a swap method, but it gets trickier to describe. You can no longer say "when making a function call in java, what is copied to the call stack are primitive values and pointer values."
Edit: I think this does a decent job explaining the distinction.
Where can you actually copy the object directly at all in Java? Because you always work with references (pointers) so you don't even have the option afaik.
See the balloon analogy at http://www.yoda.arachsys.com/java/passing.html also at that site, you can't directly access (touch) a balloon so you're always dealing with the strings tied to them. How do you propose that you are actually touching the balloon?
public class lol { public static void main(String[] args) { String foo = "foo"; method(foo); System.out.println(foo); } protected static void method(String foo) { foo = "bar"; } }it would print "foo", not "bar". If it were pass-by-reference, it would print "bar".
Right, that was why I tried to emphasis the lack of reference manipulation and no way to promote/create a reference to a reference.
My whole point being, if you are writing java, you shouldn't care what the pass by semantics are. Simply knowing that there is no reference manipulation and no references to references is enough. If you want to be able to do anything that requires those, you have to explicitly code it in your object representations. Knowing the actual call structure is important for the JVM people, but should be far from it for most programmers.
The original point was that you can't do a swap(a, b) in Java because there is no pass-by-reference and people were very muddied on that.
I'm curious what you were referencing with actually passing the entire object on the call, since that doesn't seem possible given Java's object handling nor ever necessary.
I doubt that's true though... It would break a lot of stuff if it were true.
Right... I can not but confess I complicated things irritably*. Apologies to everyone reading.
You can do basic escape analysis in java 1.6. "-XX:+DoEscapeAnalysis " This does not do anything for method calls, though. My understanding from stuff I recall, but not from where, is that they are looking to increase the scope that this can work on to catch more and more short lived objects. It makes things much easier for the garbage collector.
*I can also confess to possibly have misused some terms. Brevity of forum posts really drains my abilities. I have a ton of respect for people that are fast at posting, and typically accurate.
What would it break?
If you could bypass Java's reference system and access objects directly, you could break garbage collection for one.
And basically "break" it in the way that C can break things out of careless pointer manipulation.
It would break things that are expecting a passed pointer. For example,
public class lol { public static void main(String[] args) { SomeClass lol = new SomeClass("foo"); method(lol); System.out.println(lol.field); } protected static void method(SomeClass a) { a.field = "bar"; } } class SomeClass { String field; SomeClass(String field) { this.field = field; } }This prints "bar". If it had copied the SomeClass object, it would print "foo".
Found a good link.
That is only true if you can manipulate the references. Just because they could live elsewhere doesn't change much. You should never rely on any knowledge of where an object is. Though, as you can see, if you can set it up so that the objects are not heap allocated, you can get a speed increase. Optimization caveats and all of that.
Your example is correct, but with your comment I'm not sure you understand what is actually happening here.
The "bar" creates an explicit 2nd string and stores it's address in the foo(local) reference, which so far was storing the address of the "foo" object.
The JVM does not even know what a "value" is with regard of variables.
Edit: Assuming it is, it's the reference that is being passed by value, not the object. It's not internally equivalent to the pass by value used in languages that create a copy of the instance.
Which is why we are lucky that we can take advantage of the fact that it is a VM. You don't write code expecting values or references, because the actual details of function calls are not visible in your code. The VM can change some details as it runs. So, you simply know that in the confines of running your method, you are manipulating some variables. Whether those variables are stack/heap based/etc is an implementation detail.
That's exactly my point. The foo is a local variable, and has no attachment to the variable that was passed in (except that at the start of "method" it points to the same thing). If it were pass-by-reference, then modifying the address of foo (to wherever "bar" is stored) would modify the version in main as well.
I'm not sure what you mean by this? Certainly it does, in the sense that the value of every variable (primitive and object) is stored somewhere. It's just a question of whether you have access to it or not.
A wizard copied the pointers.
I think the clearest way to think about it, is that whenever you see
Object someObject = ...;
that is translated to
Object* someObject = ...;
and someObject.method() is translated to someObject->method().
etc, etc.
I put on my globals and ^.
EDIT: especially when we all probably agree and are just misinterpreting others' statements.
The problem comes in explaining how mutable types fit with this. Consider:
public class lol { public static void main(String[] args) { StringBuffer foo = new StringBuffer(); method(foo); System.out.println(foo); } protected static void method(String foo) { foo.append("bar"); } }Why is it the change there is visible? Has very little to do with by-value and by-reference. Especially considering the fact that if you simply moved the contents of "method" into "main" in either case, nothing changes of the outcomes.
But this is where I was saying confusion comes in. This is not at all guaranteed. As shown by the escape analysis optimizations, the very existence of "someobject" may be eliminated and all of the values it would have held can be essentially created as local values for the method.
Now, this is all completely invisible to the programmer.
This is what I was arguing all along. ;-)
I am just correcting the use of pass-by-value and pass-by-reference so that people don't fuck em up.
(The change is visible there of course because it should! Has nothing to do with calling convention as you say.)
Right, this is what I was horribly trying to point out, as well. Which is why I thought what we were saying was very close.
What is the actual question you are looking at? I know I said it earlier, but usually identifying loop invariants is simply a way to optimize said loops.
I think I'm starting to get the hang of it.
Ah, I see I was wrong in what you were even referring to. My apologies.
The wikipedia article does a job of explaining loop invariants. I'm curious what the question you are being asked specifically is.
Edit: Actually, I am not sure I was off on what you were originally referring to. It seems that you are basically using a logic language to describe the following:
for (i = 0; i < n; ++i) { x = y + z; a[i] = 6 * i + x * x; }You could write the above as follows:
x = y + z; for (i = 0; i < n && (x==y+z); ++i) { x = y + z; a[i] = 6 * i + x * x; }Nothing has changed in that code now, the same results will result. You can then flat out remove the x=y+z from the loop altogether.
^ is a logical AND. v is a logical OR. the sideways L in front of B on that one condition is logical NOT.
It's just the symbols for those operations in math/logic land.
So that last one is { LI AND NOT B }
:^:
Wow, I'm a freaking idiot. I completely blocked out my discrete math class.
And thank you for further explaining it taeric.
I've got a thread or post ID coming in from a form that's always supposed to be an int. I tried casting using int(), but it fusses if there's anything other than numbers in there. Everything I'm reading about int() says that it's supposed to extract the number from the string, but it's not. I thought about RegEx, but it and I have never seen eye to eye. I should probably learn it.
Language: Ruby
Frameworks: Are for sissies, but Rails and Sinatra
Purpose: Web Programming and Server Scripting
Ruby is Perl for Human Beings. It has an extremely flexible syntax with incredibly powerful metaprogramming elements. While you can write Ruby code however you want, generally there is a "Ruby Way" to do something in an elegant manner. With everything truly being an object, one is able to really use the flexibility of OO to keep yourself DRY. With the heavy community emphasis on testing and the ability to easily fit into other agile practices, it has become quite popular with the whole Agile Development crowd.
Rails is the behemoth MVC web framework that does everything. Yes, even that. It is great for getting an application up off the ground quickly, and provides all the tools you need to continue to grow it. It is *very* opinionated about how to do business, and if you follow along your life is super easy. While they aren't bad rules to follow, if you aren't used to working exactly the Rails way, you may find yourself uncomfortable.
Sinatra is a super lightweight web framework that does nothing more than allow you to make an application that responds to web requests. It works well for light sites, services, or if you want to make your own framework.
Further reading: Why's Poignant Guide to Ruby, Ruby on Rails 15-Minute Blog
EDIT: Also, on the SCM front, Git is pretty great. And vim is the only text editor you ever need.
3DS Friend Code: 2707-1614-5576
PAX Prime 2014 Buttoneering!