Difference between revisions of "Talk:GravityWave/Versions"

From Robowiki
Jump to navigation Jump to search
(→‎Future Position: My painful attempt (includes code))
m (Using <syntaxhighlight>.)
 
(4 intermediate revisions by 2 users not shown)
Line 5: Line 5:
 
: Ah, ok... Well, I was hoping my more readable wrapper code would make it more clear how it works. =) Any specific questions? A MovSim represents a robot state at a point in time, basically get one of those back from the simulator and use it as input for the next tick's simulation... --[[User:Voidious|Voidious]] 22:19, 12 June 2009 (UTC)
 
: Ah, ok... Well, I was hoping my more readable wrapper code would make it more clear how it works. =) Any specific questions? A MovSim represents a robot state at a point in time, basically get one of those back from the simulator and use it as input for the next tick's simulation... --[[User:Voidious|Voidious]] 22:19, 12 June 2009 (UTC)
 
: I made a Point2D.Double function that calls the MovSim and returns the projected x and y fine. It's just then getting it to work like the function in [[BasicSurfer]]. This is how it's set up:
 
: I made a Point2D.Double function that calls the MovSim and returns the projected x and y fine. It's just then getting it to work like the function in [[BasicSurfer]]. This is how it's set up:
<pre>
+
<syntaxhighlight>
 
public Point2D.Double predictPosition(AdvancedRobot _robot, int future) {
 
public Point2D.Double predictPosition(AdvancedRobot _robot, int future) {
 
if (moveSimulator == null) { moveSimulator = new MovSim(); }
 
if (moveSimulator == null) { moveSimulator = new MovSim(); }
Line 16: Line 16:
 
return nextPosition;
 
return nextPosition;
 
}
 
}
</pre>
+
</syntaxhighlight>
 
Now I know this is the problem, this is how I call it:
 
Now I know this is the problem, this is how I call it:
<pre>
+
<syntaxhighlight>
 
int index = getFactorIndex(surfWave,
 
int index = getFactorIndex(surfWave,
 
             predictPosition(this, 1));
 
             predictPosition(this, 1));
</pre>
+
</syntaxhighlight>
 
I'm thinking I'm going to need to write a new getFactorIndex to better suit the MovSim function. I'm not sure though. --[[User:J Litewski|Jacob Litewski]] 23:27, 12 June 2009 (UTC)
 
I'm thinking I'm going to need to write a new getFactorIndex to better suit the MovSim function. I'm not sure though. --[[User:J Litewski|Jacob Litewski]] 23:27, 12 June 2009 (UTC)
 +
 +
That way you only predict 1 tick in future. The wave surfer need to predict every tick until the wave hit. And the fact that [[FuturePosition]] is really complicated. If you sure you want to use this, using Voidious' is much easier. (I read them in order to find how to calculate stop position) Anyway why do you need to use FuturePosition instead of Apollon's? That one work fine enough. If you want the maxVelocity then a bit codework is enough (add 2 more lines really). When you are wave surfer with wall smoothing, it is not nescessary to check for the wall. If you want to do distanceRemaining, grab getVelocity from RobotPeer method and replace in Apollon's will work fine. I think my one at [[User:Nat/Free Code]] have match features except the wall collisions, and it is much more readable I think. &raquo; <span style="font-size:0.9em;color:darkgreen;">[[User:Nat|Nat]] | [[User_talk:Nat|Talk]]</span> &raquo; 05:46, 13 June 2009 (UTC)
 +
 +
==  Linked Lists vs Arrays ==
 +
 +
The advantage of arrays over linked lists is that accessing a specific element ("random access") in an array is way faster. An array (or ArrayList) is a contiguous block in memory, so to find element X, you can deduce its memory location using X and the size of an element. Not so for a linked list - each element just contains a pointer to the next one, so you have to traverse the list every time (X times to find the Xth element). But it can grow in size very easily, without having to reallocate a new block of memory and copy everything over (something ArrayList does internally). Also, some lists are just meant for traversal, so I'd use a linked list in those cases just for clarity.
 +
 +
In Komarious, it saves bytes to call getFirst() instead of get(0), I originally never used any random access, and the performance hit for random access is pretty negligible in this case, anyway.
 +
 +
--[[User:Voidious|Voidious]] 23:12, 18 June 2009 (UTC)

Latest revision as of 09:34, 1 July 2010

Future Position

I use Future Position in Dookious and Diamond. I just made the main simulation method public, so I can change movement tick by tick (as one needs to in simulating Wave Surfing), then some additional wrapper methods in DUtils and DiaUtils, if you want to take a look. --Voidious 20:25, 12 June 2009 (UTC)

I did, which is where I got the idea. I'm just having problems making it work. --Jacob Litewski 21:02, 12 June 2009 (UTC)
Ah, ok... Well, I was hoping my more readable wrapper code would make it more clear how it works. =) Any specific questions? A MovSim represents a robot state at a point in time, basically get one of those back from the simulator and use it as input for the next tick's simulation... --Voidious 22:19, 12 June 2009 (UTC)
I made a Point2D.Double function that calls the MovSim and returns the projected x and y fine. It's just then getting it to work like the function in BasicSurfer. This is how it's set up:
public Point2D.Double predictPosition(AdvancedRobot _robot, int future) {
	if (moveSimulator == null) { moveSimulator = new MovSim(); }
	System.out.println(future);
	if(future <= 0) { future = 1; }
	
	MovSimStat[] next = moveSimulator.futurePos(future, _robot); //predict into the future
	Point2D.Double nextPosition = new Point2D.Double(next[future-1].x, next[future-1].y);
	
	return nextPosition;
}

Now I know this is the problem, this is how I call it:

int index = getFactorIndex(surfWave,
            predictPosition(this, 1));

I'm thinking I'm going to need to write a new getFactorIndex to better suit the MovSim function. I'm not sure though. --Jacob Litewski 23:27, 12 June 2009 (UTC)

That way you only predict 1 tick in future. The wave surfer need to predict every tick until the wave hit. And the fact that FuturePosition is really complicated. If you sure you want to use this, using Voidious' is much easier. (I read them in order to find how to calculate stop position) Anyway why do you need to use FuturePosition instead of Apollon's? That one work fine enough. If you want the maxVelocity then a bit codework is enough (add 2 more lines really). When you are wave surfer with wall smoothing, it is not nescessary to check for the wall. If you want to do distanceRemaining, grab getVelocity from RobotPeer method and replace in Apollon's will work fine. I think my one at User:Nat/Free Code have match features except the wall collisions, and it is much more readable I think. » Nat | Talk » 05:46, 13 June 2009 (UTC)

Linked Lists vs Arrays

The advantage of arrays over linked lists is that accessing a specific element ("random access") in an array is way faster. An array (or ArrayList) is a contiguous block in memory, so to find element X, you can deduce its memory location using X and the size of an element. Not so for a linked list - each element just contains a pointer to the next one, so you have to traverse the list every time (X times to find the Xth element). But it can grow in size very easily, without having to reallocate a new block of memory and copy everything over (something ArrayList does internally). Also, some lists are just meant for traversal, so I'd use a linked list in those cases just for clarity.

In Komarious, it saves bytes to call getFirst() instead of get(0), I originally never used any random access, and the performance hit for random access is pretty negligible in this case, anyway.

--Voidious 23:12, 18 June 2009 (UTC)