| www.ClassicTW.com http://classictw.com/ |
|
| Simple read file to an array http://classictw.com/viewtopic.php?f=15&t=30674 |
Page 1 of 4 |
| Author: | Helix [ Sat Nov 27, 2010 3:42 pm ] |
| Post subject: | Simple read file to an array |
Does anyone have a simple example of reading a file into an array? Helix |
|
| Author: | Promethius [ Sat Nov 27, 2010 3:56 pm ] |
| Post subject: | Re: Simple read file to an array |
# $myFigs will be the size of the array I believe, and $myFigs[1] the first element setVar $figsFile GAMENAME & "figs.figs" fileExists $exists $figsFile if ($exists) readtoArray $figsFile $myFigs else echo ANSI_12 "** Figs file does not exist!!! Halting." halt end |
|
| Author: | Helix [ Sat Nov 27, 2010 3:58 pm ] |
| Post subject: | Re: Simple read file to an array |
Thanks Prom H |
|
| Author: | Helix [ Sat Nov 27, 2010 4:39 pm ] |
| Post subject: | Re: Simple read file to an array |
This is what I am working on. This only does the first element in the array then stops, where I am I screwing up? I have checked the variables and they are all in the array, its just not incrementing. Code: # init variables setVar $sectorList "" setVar $tradeSector "" setVar $i 1 setVar $shopFile "ports.txt" fileExists $exists $shopFile if ($exists) readtoArray $shopFile $myPorts else echo ANSI_12 "** Figs file does not exist!!! Halting." halt end # setup a loop to move through the sectors :loopStart # get the sector to warp to getword $myPorts[$i] $tradeSector $i while ($tradeSector > 0) # warp to sector send "s" waitfor "Citadel command (?=h" send "p" waitfor "lanet to? (Q to Abort)" send $tradeSector "*" waitfor "shall we engage?" send "y" gosub :sellBuy add $i 1 getword $myPorts[$i] $tradeSector $i end |
|
| Author: | Big D [ Sat Nov 27, 2010 4:42 pm ] |
| Post subject: | Re: Simple read file to an array |
you are incrementing your $i variable but not the $tradesector variable, but you are testing your loop with the $tradesector variable. To read a file to an array, you can basically just do this: readToArray $filename $arrayname To process your data you'll need to loop it. setVar $i 0 while ($i <= $arrayname) add $i 1 (do whatever you need to do here) end setVar $i 0 |
|
| Author: | Singularity [ Sat Nov 27, 2010 6:34 pm ] |
| Post subject: | Re: Simple read file to an array |
There's a few conceptual issues to work out. The biggest is how do you loop thru the ports effectively? Right now you're just working sector by sector on the list, but that is not the most effective approach. Here is the basis of a nearest port ptrader. You can adapt this to do basically anything you need. Code: # --------------------------------------------------------- # Set this to the appropriate filename setVar $ports_file "" # --------------------------------------------------------- # Promptify send #145 waitFor #145 setVar $currentline CURRENTLINE stripText $currentline #8 stripText $currentline #145 getWord $currentline $prompt 1 if ($prompt <> "Citadel") send "'This script must run from the Citadel!*" halt end # Read ports file setVar $ports_count 0 setArray $ports_list SECTORS fileExists $exists $ports_file if ($exists > 0) readToArray $ports_file $list setVar $i 1 while ($i <= $list) getWord $list[$i] $word 1 isNumber $num $word if ($num > 0) if (($word > 10) AND ($word <= SECTORS)) add $ports_count 1 setVar $ports_list[$word] TRUE end end add $i 1 end end if ($ports_count < 1) send "'No valid ports to visit!*" end # Now we have a hash array that specifies whether # a given sector is or is not a port to hit. Its # already clean, so we don't have to re-test each # sector later. # --------------------------------------------------------- # Top loop :top_loop killAllTriggers # Scan sector send "s* " waitFor "<Scan Sector>" waitFor "Sector :" getWord CURRENTLINE $this_sector 3 waitFor "Citadel command (?=help)" # Find the next port to hit getNearestWarps $stack $this_sector setVar $next_port 0 setVar $i 1 while ($i <= $stack) setVar $this $stack[$i] if ($ports_list[$this] = TRUE) setVar $next_port $this goto :found_next_port end add $i 1 end if ($next_port = 0) send "'Out of ports!*" end :found_next_port # Pwarp there killtrigger nofiglock killtrigger toolilore killtrigger alreadyth killtrigger rdy_to_go setTextLineTrigger nofiglock :cant_go "You do not have any fighters in" setTextLineTrigger toolilore :no_fuel "You do not have enough" setTextLineTrigger alreadyth :p_ready "You are already in that sector!" setTextLineTrigger rdy_to_go :p_ready "All Systems Ready, shall we engage?" send "p" & $next_port "*y" pause :cant_go killtrigger nofiglock killtrigger toolilore killtrigger alreadyth killtrigger rdy_to_go echo ANSI_12 & "Sector " & $next_port & " has no fig down!*" setVar $ports_list[$next_port] FALSE goto :top_loop :no_fuel killtrigger nofiglock killtrigger toolilore killtrigger alreadyth killtrigger rdy_to_go send "'Planet is too low on ore to continue!*" halt :p_ready killtrigger nofiglock killtrigger toolilore killtrigger alreadyth killtrigger rdy_to_go # - - - - - - - - - - - - - - - - - - - - - - - - - - - - - # Your code goes here to do whatever you need to do # - - - - - - - - - - - - - - - - - - - - - - - - - - - - - # Clear from the list and hit the next setVar $ports_list[$next_port] FALSE goto :top_loop # --------------------------------------------------------- halt # --------------------------------------------------------- |
|
| Author: | Parrothead [ Sat Nov 27, 2010 7:29 pm ] |
| Post subject: | Re: Simple read file to an array |
Or you can pre-optimize your list and just feed it in. Depends on how flexable you want your planet jumper to be. Nearest ports are fine for ptrading normally but you might want a mega/buyer sell then nearest wont work as you need to set your list in pairs. Same with blue ptrading maxed ports. |
|
| Author: | Singularity [ Sat Nov 27, 2010 8:09 pm ] |
| Post subject: | Re: Simple read file to an array |
Parrothead wrote: Or you can pre-optimize your list and just feed it in. Depends on how flexable you want your planet jumper to be. Actually, from an ore efficiency standpoint, pre-calculating to the same detail as the above code is neigh impossible. Algorithmically, we're talking about an A* search, and trying to predict things that may not be predictable. For instance what happens if the fig gets taken out at the last minute? How do you adjust most efficiently? Now if you can find an optimized non-greedy way of searching ports (ie: not assuming that the shortest sum distance is the sum of the shortest distances) then by all means let me know. Parrothead wrote: Nearest ports are fine for ptrading normally but you might want a mega/buyer sell then nearest wont work as you need to set your list in pairs. Same with blue ptrading maxed ports. No you don't. I have a megarob/buydown script that does not pair ports at all. Instead I maintain two lists, buyers and sellers, and I traverse down them using the same method. Set for set, it burns equal to or less ore than pre-pairing. Nearest ports is actually the best known optimal method for solving the blue ptrade problem. Of course there could always be a solution outside of the greed assumption, but now we're talking NP-hard or NP complete (see above about the 'let me know' thing). |
|
| Author: | Parrothead [ Sun Nov 28, 2010 1:53 am ] |
| Post subject: | Re: Simple read file to an array |
Well my mega script doesn't use a list at all Sing. But I wasn't talking about "MY" script but Helix's which does use a list. Maybe he wanted to bbl trade or add port or planet upgrades..or strip figs from planets along the way. I am sure he has a reason for using a list in his script. In which case it is a straightforward thing to optimize for gas use before importing depending on his application and will give him good value for gas used missing figs aside. As for ptrade only scripts? Well a bfs search for nearest filtered port is good but not ideal and you need 100% of the info. Going into deadend's(1 warpin and 1 warpout which are the same sector) to trade my be fine also but does not get you the best in gas efficiency because you need to back track. So analyzing all the ports equidistant from your current position for both the port info you want (percentage , total's , does it sell gas or not and mcic's) AND the distance to the port after will bump efficiency.Also the amount of potential "unknown" information between port a and port b can be given a value and taken into consideration in a ptrade as the amount of information via dsan can be given a value in per unit of gas. There are a few others things as well but I think I made the point. |
|
| Author: | Singularity [ Sun Nov 28, 2010 2:20 am ] |
| Post subject: | Re: Simple read file to an array |
Parrothead wrote: Well my mega script doesn't use a list at all Sing. You can feed from the CIM, but that requires you to only trade ports on your CIM. That isn't always the case when you've got multiple people on a corp. Same is true with EP's MCIC settings DB. Parrothead wrote: But I wasn't talking about "MY" script but Helix's which does use a list. Maybe he wanted to bbl trade or add port or planet upgrades..or strip figs from planets along the way. I am sure he has a reason for using a list in his script. In which case it is a straightforward thing to optimize for gas use before importing depending on his application and will give him good value for gas used missing figs aside. I think he was making an upgrade script, but you'd have to ask him. It's actually not so simple to pre-sort the list by distance, because that assumes that quite a bit about the starting position of the script, and that all of the pre-sorted list will remain constant during the run. Should anything interrupt that, you lose optimality. For instance consider what happens if the script hangs and needs reset at a port. You have to re-sort all of the information, and you gain no advantage in doing a pre-sort. Parrothead wrote: As for ptrade only scripts? Well a bfs search for nearest filtered port is good but not ideal and you need 100% of the info. Computationally speaking, this is incorrect. The idea of a recursive BFS forms the backbone of something called a Dijkstra's algorithm. A* search, which is currently one of the best respected algorithms for this type of problem, is based on that and adds some heuristics. Basically it gains efficiency by reducing the graph down to a smaller subset, but that's going to get complicated quickly. Parrothead wrote: Going into deadend's(1 warpin and 1 warpout which are the same sector) to trade my be fine also but does not get you the best in gas efficiency because you need to back track. Using a recursive BFS, the actual node/vertex setup of the graph is largely immaterial. There are some heuristics that can improve performance, but they don't work this way. The goal here is to trade X number of ports, where-ever they may be, as optimally as possible. Yes, picking ports in the right areas of the universe will improve the overall efficiency, but that is vastly outside of the scope of this problem, and the end result will be that a near port search will still be as (or more) efficient than any other method in TW today. Parrothead wrote: So analyzing all the ports equidistant from your current position for both the port info you want (percentage , total's , does it sell gas or not and mcic's) AND the distance to the port after will bump efficiency. Uhm, not really. Provided you only trade ports with requisite MCICs, it doesn't matter whether you trade them highest to lowest or not. Infact, that tends to burn more ore and since all of the ports are still traded, the net result is actually worse performance. If you're argument is that removing bad MCICs from the trading list improves performance, well yes, that much is obvious. But that's outside of the scope of a port efficiency algo. Percentage is, also, a true/false condition. Either the % is high enough to trade or it isn't. You can filter the list by % if you want (and I do, usually), but that's also outside of the scope of this particular problem. And selling gas is a tangent. Whether it sells gas or not has nothing to do with burning the least possible gas on the route. Granted it's a place to refill, but if it takes more ore to reach it then it the sum total path still burns more ore and is less efficient. Parrothead wrote: Also the amount of potential "unknown" information between port a and port b can be given a value and taken into consideration in a ptrade as the amount of information via dsan can be given a value in per unit of gas. There are a few others things as well but I think I made the point. While there are some filter criteria regarding ports, I don't see how how "unknown" information affects the one thing that matters here: distance. The goal is to trade X ports by burning the lowest amount of ore possible. That's all this algo is concerned with, everything else is a tangent. A dscan has no relationship to units of gas when you have a fixed set of ports to trade. There is no relationship there at all. |
|
| Author: | Parrothead [ Sun Nov 28, 2010 2:46 am ] |
| Post subject: | Re: Simple read file to an array |
Sorry Sing but you simplify the issue to much. Planet trading simply from bfs will not get you the most bang for the buck here. Run through it yourself. I have gone thru this six ways from sunday and have written a much more efficient ptrader because of it. A simple bfs will not get you the most efficient route to sell product off. Either in terms of cash/turn or cash/unit fuel which comes close to the same thing here as buying the fuel you use takes 97% of the turns approx. As far as "unknown" info.....What has more value...a new port with a unkown mcic at distance 3 from your current position or one with a mcic of 30 at same distance.Perhaps the new port is a 25 MCIC but maybe its a 60...either way the information is more valuable and therefore will increase the efficiency next time. Also given that 100% of information is NOT known you cannot base a model as if you DID know all the info. GOing from point A to Point B costs X amount in gas...The information gathered between the 2 points affects the math as you go and must be considered. If you don't consider these things then a bfs ptrader will go to the EXACT SAME PORTS every time if you start in same place. And this will NOT result in the most gas efficient route to sell off the entire load either in terms of gas used OR in cash/turn. TOTAL DISTANCE for the whole run determine's efficiency on a fuel only basis not Distance between ports. Also Increased distance can result in increased cash from the run by filtering the mcic's and this gives you a cash/turn or cash/gas used equation which is closer to the mark for a ptrader than product sold/gas used. As far as the gas along the way being irrelevant? Gas bought along the way can be bought down as a percentage of total depending on need to replace..this produces gas for less cash than buying down from a full port at the beginning or end of run. Also the need to move the planet to or from such a gas port is using gas. There are cases where its irrelevant..unlom's or builder games where the colos produce ore enough to sell the product and it is easy enough to remove the gas portion of the equation if it is the case but in general a ptrade script would need to consider this. Especially if it needs to buy the gas to complete the run...and with low gas to start and low port density is often the case. |
|
| Author: | Helix [ Sun Nov 28, 2010 3:22 am ] |
| Post subject: | Re: Simple read file to an array |
Not to bust the dialog but I already know the ports at which I will be trading. That was the point of reading the file. H |
|
| Author: | Singularity [ Sun Nov 28, 2010 3:23 am ] |
| Post subject: | Re: Simple read file to an array |
We had this discussion a while back. The problem you posed was a single port decision, not the sum decision of a set of ports. I know for 100% certainty that I'm correct here, I can prove it mathematically. I've actually studied this class of problems in depth. I'd be happy to go thru it if you want, but this isn't a good forum for that depth level. Your assumption is that the actual net cash of each port matters in the decision. When you have to trade the same ports regardless, this no longer matters. The actual value of the port does not matter when you have 10 ports to trade, and must trade all 10 of them. Think about it. Lets say have enough product to sell off to 10 ports. They produce the following cash values: 5.0m 3.4m 4.0m 3.6m 5.2m 4.1m 3.7m 3.8m 4.2m 4.7m How much money will all of those ports produce? 41.7m It doesn't matter what order you trade them, whether 1 thru 10, or 1 thru 10 odds, then evens, or whatever. No combination will produce more than the sum. That is a mathematical fact. Now you can argue for removing ports from the list, but that isn't the same thing. We're talking about having X ports that you must trade, removing a port from the list reduces the ore cost, but also reduces X. You still must trade the new list as efficiently as possible, regardless of list size. Cash/ore is not the the appropriate measure here. Cash/unit fuel only matters when you have discretion over whether to trade a port or not. In that, then, it becomes only a filter for the list and not a criteria for order. Ie: If you have 5 ports to trade, and only 1 or 2 must be hit, which ones do you hit? This all goes to the "greedy" assumption. The idea that the sum of all decisions yields the optimal result. Neither mine nor yours will do so, that I can prove, but my approach will get closer to the optimal sum than yours will. Quote: If you don't consider these things then a bfs ptrader will go to the EXACT SAME PORTS every time if you start in same place. Assuming the ports are still on the list, yes. And while there are cases that might give B an advantage over A in terms of efficiency if you only must choose one, if you must trade both B and A, the cash result does not matter. Quote: Also Increased distance can result in increased cash from the run by filtering the mcic's and this gives you a cash/turn or cash/gas used equation which is closer to the mark for a ptrader than product sold/gas used. No, it won't. If you must trade all of the ports on the list, then it does not matter what the next choice pays. Since it is compulsory to trade it, it must be traded either soon or later. Total profit cannot exceed the sum profit of the ports. Yes you can filter the list as you go, but this only reduces the number of ports on the list, it does not reduce the need to trade the remaining ports efficienctly. Quote: this produces gas for less cash than buying down from a full port at the beginning or end of run. Also the need to move the planet to or from such a gas port is using gas. This is tangential to the problem at hand, but relevant to the net cash question. In that sense, what matters is that you have enough ore to reach one of the ore ports on the list. For my mega rob script, I only have it buy ore from megarob ports prior to the mega. Still, that does not affect the net ore cost for the run, it only ensures that there's enough ore to meet that cost. As such, this particular issue does not have anything to do with the method of searching for the next target, but rather only has to do with list selection. List selection is a completely different issue. |
|
| Author: | Big D [ Sun Nov 28, 2010 3:33 am ] |
| Post subject: | Re: Simple read file to an array |
Helix wrote: Not to bust the dialog but I already know the ports at which I will be trading. That was the point of reading the file. H Looks like a case of to much information. laff |
|
| Author: | Singularity [ Sun Nov 28, 2010 3:36 am ] |
| Post subject: | Re: Simple read file to an array |
Big D wrote: Looks like a case of to much information. laff Laff. It's actually relevant to the problem tho. Helix had a set of ports that he must visit. That condition changes everything. On the other hand, if you have 5000 ports on your CIM and only need to trade 200 of them to sell off EQ, then the problem is very different and MCIC does matter. |
|
| Page 1 of 4 | All times are UTC - 5 hours |
| Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group http://www.phpbb.com/ |
|