-
Posts
807 -
Joined
-
I very much doubt that. To clarify, though it will be arguable that the robot we create is living or not, a bipedal robot with AI sufficient to sufficient to drive it as well as interact with us in terms we can relate to as human-like is a certainty. We're already on that path.
-
Quote:...Until some disgruntled programmer programs in "Take a chance!" that is.I find it hard to believe that any primitive (but sentient) AI could relate at all to humanity or organic life. It would either view life/us as hostile (not having the same ends) and/or utterly irrational. The presuppositions that we as humans have toward virtually everything would not be passed on unless done in a hard "programmed" way, in which case, the AI doesn't have free will and I would argue is no longer on the same level as sentient creatures.
-
Quote:And I paraphrase...The only indication that she is dead is the use of the word "late". That's pretty thin soup.
Her death isn't a certainty but it's the way to bet; I think any attempt for Conan Doyle to have used her in a subsequent story (other than a reference to the past adventure) would be not very credible. Of course....he did just that with Holmes in The Adventure of the Empty House, who also was offed offscreen in The Final Problem. -
Quote:It's important to me, I actually want my computer to be sentient enough to be able to help me with stuff, or even converse with to work stuff out with. There aren't many people around with my goals and skillsets, and I'm the guy people usually go to help them with their stuff, so I always end up having to work alone...and talking to trees (they're not good conversationalists either, but at least they listen).All this talk about the potential discovery of advanced intelligence and sentience and the importance that it could mean...
And I tend to think of how it could/should point to the unimportance of it.
Sentience/shmentience... eat some food, lookit the stars, grow up, die, blah blah blah. -
-
Quote:That looks way cool. I find it funny one of the people quoted that they should be spending resources to cure cancer than the these robots. Pft, its like he doesn't realize that cancer will be cured once these robots replace humans.Petman Robot - article & video
http://singularityhub.com/2011/12/21...minator-video/ -
-
Quote:Yeah, I probably shouldn't have done this from scratch. But I had a problem with lack of resources and equipment for a full 3D project so I decided the best way to complete the project was 2D objects on a 3D plane. Doing it from scratch seemed best as I can control the graphics scaling better for best quality since the objects are basically 2D sprites. Also, for now, the window itself only needs to pan up, down, left, and right, therefore this seemed the way to go.In any event, nobody goes through the derivations from scratch anymore except as a learning process. We do this 3d stuff with matrix-based transformations now. That type of 3d code is more transferrable to accelerated graphics APIs.
But for something as straight-forward as this, I'd stick with the simple linear transform: touch.y = 640 * [500 / (z + 500)]
The next 3D project I do for sure I'll do with 3D graphics APIs.
Quote:The other thing is never over-optimize calculations. That's what the computers are for. Unless you have a specific performance issue, algorithmic simplicity is better than overoptimized calculations. Its easier to debug code that is algorithmically transparent. -
Pretty much. I removed a lot of variables used in the calulations (like the size of window and such) on my original post as it didn't pertain to what I needed at the time, and make it even more confusing to anyone reading the posts. But they were accounted for when I coded in the formula.
BTW before I posted the initial solve, I had already coded it and tested it thoroughly, the formula as it stands works perfectly. I could broaden its features, but I'm trying to keep it as simple as what is needed for the project I'm working on. Maybe later, I'll expand on it should it be needed. -
I always do when I code, I was just going along with Durakken in the post.
Actually, my variables go even further by designing its type. So for instance x, y, z would be fX, fY, fZ the "f" stating that the variables are floating point variables. -
Quote:That's right, it is mentioned in A Scandal in Bohemia that Irene Adler dies at some unchronicled point.*
and that woman was the late Irene Adler, of dubious and questionable memory.
Here's an interesting comics tidbit: In Marvel Comics, Irene Adler goes on to become the blind supervillain Destiny. It is also strongly hinted that Sherlock Holmes was actually Mystique.
*Not really a spoiler since its on the first paragraph of the story in which Irene Adler first appears. -
Quote:Here you go, from Wikipedia:1.) Holmes isn't a fighter/boxer like he's depicted in the movies
Holmes is described as a formidable bare-knuckle fighter. In The Sign of the Four, Holmes introduces himself to a prize-fighter as:
"The amateur who fought three rounds with you at Alison's rooms on the night of your benefit four years back".
McMurdo responds by saying, "Ah, you're one that has wasted your gifts, you have! You might have aimed high, if you had joined the fancy".
Holmes engages in hand-to-hand combat with his adversaries on occasions throughout the stories, inevitably emerging the victor. It is mentioned also in "Gloria Scott" that Holmes trained as a boxer, and in "The Yellow Face" Watson comments that "he was undoubtedly one of the finest boxers of his weight that I have ever seen."
The only major point the movies deviate from the stories concerns Watson's wife Mary Morstan. Mary Morstan in the stories was a client of Holmes in The Sign of Four when she meets Watson. In the first movie, Mary is introduced to Holmes by Watson after they are already engaged. -
Quote:Because the rise of the variable was set for the window already in b=500.0. What the formula is trying to do is either turn b into 0 or get the difference if the window is panned up or down hence b-500. y=640 put into the code is fine though.if i understand what you are saying then i would make both 500s variables.
I don't see why making 640 be y is a problem...don't you want that coordinate to always be on the ground thus why you are making it 640 to begin with?
As far as the multiply is concerened, c++ needs the * symbol to designate mulitiplication, the compiler would read d2 as a variable in itself instead of d*2.
v = 500;
y = 640;
z = (v(y-b)/(a+(b-500)-b))-v;
x = (c-d2)*((z+v)/v)+d;
or in c++ code:
v=500.0f;
y=640.0f;
z=(v*(y-b)/(a+(b-500.0f)-b))-v;
x=(c-d*2)*((z+v)/v)+d; -
Hmm, you might be right. The only problem I see is that the 640 is a y coordinate for the ground. And there are actually two different values that equal 500. One is the point of view rise of the window, and the other is an arbritrary value set to designate the distance between the window and the viewer. If I represented the latter with a variable of v the simplified formula would look like this:
v = 500;
z = (v(640-b)/(a+(b-500)-b))-v;
x = (c-d2)*((z+v)/v)+d;
or in c++ code:
v=500.0f;
z=(v*640.0f-b)/(a+(b-500.0f)-b))-v;
x=(c-d*2)*((z+v)/v)+d; -
-
Quote:I suppose I could change it to look like this to make my intent clearer, but it doesn't really make a difference.After using the y touch location to solve for z, I didnt need to use the value for anything else so I put the y value back to its constant 640.0 plane (the ground where the puck slides) on the third line.
z = touch.y + (window.y - 500); z = ((500 * (640.0 - window.y)) / (z - window.y)) - 500;
x = touch.x - window.x; x = ((x - window.x) * ((z + 500) / 500)) + window.x;
y = 640.0; -
Quote:I put the touch values modified by the viewpoint of the window to get the correct x,y values at a z of 0.0 (the screen/window as understood by the renderer and which is not always the same a the mouse/touch pointer value as the viewpoint can change). I then used that value into pretty much the same formula used to render the world modified to solve for z instead of x or y (in this case using y to solve for z).>.> I know he said you solved this but I'm still having trouble understanding because that is just calculating a triangle where the triangle can be at a different angle from the ground and that's pretty easy and i'm sure the math you're using is overly complex...
also just have to point this out as i just realized it
"y = touch.y + (window.y - 500); z = ((500 * (640.0 - window.y)) / (y - window.y)) - 500;
x = touch.x - window.x; x = ((x - window.x) * ((z + 500) / 500)) + window.x;
y = 640.0;"
if this is your programming it's messed up because you are a setting y to touch.y plus the math and then setting it again to 640.0 making the original statement pointless... unless you're only doing it for setting z, but then y and z would be broken so >.>
The second part after the ";" of the second line calculates for x based on the location of the touch at z of 0 (first part) and then the value derived for z, since I'm shooting at a location ahead x has to be modified by the z value to get a correct target.
After using the y touch location to solve for z, I didnt need to use the value for anything else so I put the y value back to its constant 640.0 plane (the ground where the puck slides) on the third line.
These lines are basically to set the ending location of a projectile sliding forward along the ground that's straight. The values that may change other than touch is the view point of the window/screen which can pan the world left right up an down, therefore modifies the targeting. -
Quote:It's all good. Tenjoy got your back and helped me solve the issue. Thanks anyway!Strangely I had to work yesterday on my supposed day off. Normally I break from the forums on days I have off and its interesting to see that God had a plan B for ensuring I was going to be doing calculations on Monday no matter what happened.
-
Nothing if it wasn't so overused in the Mission Impossible movies (especially the second one). It became the basis for all their missions. I don't remember a mask being used in this new one, I know they were gonna use them but the mask making machine couldn't finish in time. I was happy to see them do a mission without them.
-
-
The one thing I really love about Mission: Impossible - Ghost Protocall, NO FRIGGING MASKS! HALELUYAH FINALLY! Its about time.
-
The final solution BTW, thanks to Tenjoy was:
y = touch.y + (window.y - 500); z = ((500 * (640.0 - window.y)) / (y - window.y)) - 500;
x = touch.x - window.x; x = ((x - window.x) * ((z + 500) / 500)) + window.x;
y = 640.0;
Ugh, I hate math even though I used to teach it. Hehehehe -
Ok I found my mistake and reran the numbers on an Excel sheet and I'm getting a perfect result. Sweet thanks, Tenjoy! Now I just got to figure out how to work in the window offset of 500.0 into it.
-
Quote:Hmmm something is backwards here...with this the puck seems to end up higher on the screen the lower I point on the screen.Since we know the y component of your puck (it is moving in the y=640 plane), this is rather easy. Start with [/color]
touch.y = 640 * 500 / (z + 500)
and you will find that
z = (640 * 500 / touch.y) - 500
Hope this helps,
10joy
Edit: I saw where you were going with this so I did some recalculating myself, and got the same solution as you. However, when I tried the solution, the z ended up with higher numbers than expected causing the puck to appear to go higher the lower I touch. Ugg...back to the mind grinder. -
Quote:Yes exactly what I'm asking! I'll get back to you on this after some tests. Thanks for clearing it up, as I said my brain has been through the grinder on this.Let's see whether I understood you:
Assuming that positive numbers move you to the right and to the bottom (the usual screen coordinates), and positive z coordinates go "into" the screen, you are "simulating" depth by scaling x and y down (in other words, in the direction of the viewpoint).
The puck doesn't start directly at the point of your touch, but at a fixed plane with y=640. It is supposed to travel forward ("into the screen"). Since your current viewpoint is (0; 500), it will be seen from above. As it moves away from "you", it will seem to "rise" on the screen because its increasing z component will cause its 2d transformation y coordinates to move closer to the viewpoint.
Now you're asking for the distance the puck needs to travel "into" the screen to reach the position indicated by touch.y? (Of course, this will only work if touch.y is still below the viewpoint, otherwise the puck will never reach your finger.)
You didn't explicitly state so in your post, but I assume that the puck is launched from a z=0 position, i. e. from your screen. So you're asking for a backwards transformation, giving you the z component of the 2d coordinates given by touch.x and touch.y, assuming you are pointing at the "floor" plane.
Since we know the y component of your puck (it is moving in the y=640 plane), this is rather easy. Start with
touch.y = 640 * 500 / (z + 500)
and you will find that
z = (640 * 500 / touch.y) - 500
Hope this helps,
10joy