Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Messages - Fat Cerberus
2491
No, I know what he means. Passing multiple arguments isn't the issue, the issue is keeping track of all the array indices across recursive calls. I could probably figure it out, but I'm not on my laptop at the moment...
2492
BTW, retarget is a completely optional feature.
No no, I know that. I just meant not to overthink the API for it, since it's not going to be needed at all 95% of the time.
Any reason why the lambda for Link.create only gets the immediate index as an argument and not a full set of coordinates? Like I said, it sounds very useful for creating lookup tables on the fly, but you need to know all the indices to do that.
2493
That's a neat feature. The ability to pass a lambda was a smart move; I could see this being very useful for initializing lookup tables.
As for retargeting, I wouldn't lose sleep over it. Now that I think about it even real LINQ has you specify a specific collection as part of the query, and for purposes of readability it's better to write queries on different arrays separately, the same way as if you were for-looping through them.
Just out of curiosity, why is this in the Resources forum instead of Libraries?
As for retargeting, I wouldn't lose sleep over it. Now that I think about it even real LINQ has you specify a specific collection as part of the query, and for purposes of readability it's better to write queries on different arrays separately, the same way as if you were for-looping through them.
Just out of curiosity, why is this in the Resources forum instead of Libraries?
2494
Just a quick question, can queries be built ahead of time and reused multiple times later, as in actual LINQ? For example:
That was... well, horrifically contrived, but you get the idea.
Edit: Now that I think about it, even better would be the ability to build a bare query ahead of time and then pass in an array only when you actually want to run the query on it. That is to say, have the endpoints accept an array as argument, rather than the Link context. This way you could run the same query on multiple sets of data.
Code: (javascript) [Select]
var evens = Link(numbers).where(even);
assert(evens.none(odd));
if (!evens.contains(2)) alert("That's weird, there's no 2 here...");
if (!evens.contains(8)) alert("Did the number 8 get... ate?");
evens.each(function(num) {
print(num);
});
That was... well, horrifically contrived, but you get the idea.
Edit: Now that I think about it, even better would be the ability to build a bare query ahead of time and then pass in an array only when you actually want to run the query on it. That is to say, have the endpoints accept an array as argument, rather than the Link context. This way you could run the same query on multiple sets of data.
2495
I would debate that point. Your method essentially rebuilds the entire array twice. Given that, on average in the Specs engine, only one battler acts per cycle (in rare cases more than one, if multiple units happen to have an equal CV) and likewise only one unit generally dies in a single cycle, the splice operation amounts to rebuilding only half of the array on average (anything before the insertion point need not be touched), versus your two full rewrites above. I fail to see how that is faster, unless some crazy optimization is happening behind the scenes I don't know about.
Granted all this is moot seeing as my battler arrays amount to 3 items each, max--beyond trivial to rebuild--but for huge arrays, if you're only deleting one or two items, splice is still going to be faster I would think.
Granted all this is moot seeing as my battler arrays amount to 3 items each, max--beyond trivial to rebuild--but for huge arrays, if you're only deleting one or two items, splice is still going to be faster I would think.
2496
In my opinion, a library like this is all about improving readability and maintainability, preferably with minimal impact on performance. Some amount of aliasing is expected. reject(), for example, often makes the intent of a query more clear than a negative where(). Same for every() versus none().
2497
Suggestion for new endpoint: none(), which does the opposite of every(). Right now you can get the same functionality by using every() with a negative predicate, but it would be great to be able to reuse the same predicate I use for where(). For example:
isUnitAlive was a function I created to be used in earlier queries, so it'd be awesome to be able to re-use it for this test. Currently I have to create a separate isUnitDead predicate and use every() with that.
Note that none() should probably return true if the array is empty.
Code: [Select]
if (Link(this.playerUnits).none(isUnitAlive)) {
// game over handling
}isUnitAlive was a function I created to be used in earlier queries, so it'd be awesome to be able to re-use it for this test. Currently I have to create a separate isUnitDead predicate and use every() with that.
Note that none() should probably return true if the array is empty.
2498
I guess that's true, since splice essentially rebuilds the array each time anyway. There is one advantage to splice, however: it doesn't change the identity of the array. Which I don't think matters in this particular case (I don't do any reference equality checks for these arrays), but important to keep in mind.
2499
Not a feature request, but I vote to rename/alias expand() to unroll(). "Unroll" makes it clearer what it's actually doing, especially when the results are treated as a one-dimensional array thereafter (i.e. flattening, or "unrolling" the original 2D array). "Expand" suggests only that you're widening the scope of the search, which while technically true, doesn't paint the whole picture. So yeah, Expand should be called Unroll. 
Oh, and while I'm here, I might as well ask. How much of a performance hit am I taking by doing the following?
I do that at the end of a CTB cycle to remove dead battlers from the fight. Originally, I was running a for loop through the unit lists and removing dead battlers in-place using splice(). Here, I'm recreating the whole array with a query. I know that must be a lot more expensive, I'm just wondering by how much.
Oh, and while I'm here, I might as well ask. How much of a performance hit am I taking by doing the following?
Code: (javascript) [Select]
var isUnitAlive = function(it) { return it.isAlive(); };
this.playerUnits = Link(this.playerUnits).where(isUnitAlive).toArray();
this.enemyUnits = Link(this.enemyUnits).where(isUnitAlive).toArray();I do that at the end of a CTB cycle to remove dead battlers from the fight. Originally, I was running a for loop through the unit lists and removing dead battlers in-place using splice(). Here, I'm recreating the whole array with a query. I know that must be a lot more expensive, I'm just wondering by how much.
2500
Now the true test will be when I start doing some actual queries. 
2501
Just have to say, this thing is awesome. My six-line for loop above turned into this:
I'm loving it already! In theory Expand can be chained as well for 3+ dimensional arrays, right?
Code: (javascript) [Select]
Link(unitLists).expand().invoke('beginCycle');I'm loving it already! In theory Expand can be chained as well for 3+ dimensional arrays, right?
2502
It's not quite so good! I think we need more people to try it out.
Green is my favorite color so that's awesome! (Yes, I know it's not supposed to do that, just felt like being a wise-ass
)
2503
What does pluck do, exactly? Really thinking this thing needs some proper documentation. The readme helps, but it's a bit lacking in its description of a lot of query operations. For example, is there any difference between first() and take()? They both look like they do the same thing. Same for filter() and where().
And regarding my question above and the response: I'm aware Link won't make this particular use case any faster. However, the turn resolver in Specs isn't all that complicated to begin with so I'll gladly accept a bit of overhead in favor of improved readability and, more importantly to me, scalability. I don't have to filter anything now, but I can see myself having to do so later on (prioritizing certain battlers, etc.). Besides, I'm a hands-on kind of guy so this will give me practice using Link in a real-world scenario.
And regarding my question above and the response: I'm aware Link won't make this particular use case any faster. However, the turn resolver in Specs isn't all that complicated to begin with so I'll gladly accept a bit of overhead in favor of improved readability and, more importantly to me, scalability. I don't have to filter anything now, but I can see myself having to do so later on (prioritizing certain battlers, etc.). Besides, I'm a hands-on kind of guy so this will give me practice using Link in a real-world scenario.
2504
Can Link work with multi-dimensional arrays? I have a few for loops that look like this one in my battle engine:
...which isn't too bad as-is, but it gets a little hairy when the cycle actually gets underway further down. I'm wondering if there's any way to express such a loop with Link, or if I have to do some remodeling first.
Code: (javascript) [Select]
for (var iList = 0; iList < unitLists.length; ++iList) {
for (var i = 0; i < unitLists[iList].length; ++i) {
var unit = unitLists[iList][i];
unit.beginCycle();
}
}...which isn't too bad as-is, but it gets a little hairy when the cycle actually gets underway further down. I'm wondering if there's any way to express such a loop with Link, or if I have to do some remodeling first.
2505
The image is created from an existing surface, so it's probably just reusing the surface for the image bitmap, perhaps with some copy-on-write magic to prevent disasters. Not quite the same as doing a LoadImage() every frame.