Hi everyone,<br><br>I think Matt is right on this. The piter function is powerful and simple. It gives you full control over parallel functionality and also just hands users each pf, which makes writing new analysis much easier. It may be counterproductive to continue to maintain the AnalysisTask functionality.<br>
<br>Britton<br><br><div class="gmail_quote">On Wed, Jul 11, 2012 at 8:14 PM, Matthew Turk <span dir="ltr"><<a href="mailto:matthewturk@gmail.com" target="_blank">matthewturk@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi all,<br>
<br>
Sorry for being a bit out of touch the last couple days.<br>
<br>
So this is in place for exactly the reasons Britton outlines -- it's<br>
because in theory, the time series data is meant to have a flexible<br>
set of return values. For instance, while John notes that the<br>
*default* behavior is to cycle through the list multiple times, you<br>
can also call "eval" on TimeSeries to make it operate much more in<br>
sequence on a series of operators.<br>
<br>
In practice, I think that this method is not ... as necessarily useful<br>
as the more generic .piter() method. Initially I thought, well, let's<br>
make it so that you can swap out a pf for a ts and still expect to get<br>
similar or identical return values. In retrospect, this is overly<br>
clever. Reading the source, I can't imagine anyone dealing with an<br>
actual AnalysisTask, or anything like that, when the much more<br>
convenient .piter() is available, with the storage keyword.<br>
<br>
The reason that the list is of additional dimensionality is to ensure<br>
that during the par_combine_object, the lists are concatenated<br>
correctly and mapped back in the right order to the original items.<br>
<br>
So, I guess what I've talked myself into proposing is that we strip<br>
off a lot of the overly clever stuff, and reduce TimeSeries back to<br>
being just a convenient way of addressing multiple objects, ditching<br>
the AnalysisTask stuff and retaining .piter(). Once we have that, we<br>
can also start adding on more interesting things, like inter-timestep<br>
correlations and whatnot.<br>
<br>
Thoughts?<br>
<br>
-Matt<br>
<div class="HOEnZb"><div class="h5"><br>
On Wed, Jul 11, 2012 at 8:48 AM, John ZuHone <<a href="mailto:jzuhone@gmail.com">jzuhone@gmail.com</a>> wrote:<br>
> Hi Britton,<br>
><br>
> The place to look is the eval function for TimeSeriesData. On line 125 of<br>
> yt/data_objects/time_series.py, store.result is initialized to a list and<br>
> all return values are appended to that list on line 141. This looks to me<br>
> to be handling tasks called with piter that have multiple return values. If<br>
> you add something like:<br>
> if len(store.result) == 1: store.result = store.result[0]<br>
> just outside of the "for task in tasks" loop, it produces the behavior that<br>
> we discussed. However, now that I understand why this was done, I'm not so<br>
> sure it should be changed. Having tasks dispatched with piter send back<br>
> their return values in a list is a desired feature I think, and so I think<br>
> that generality should be preserved. Perhaps there is a solution that could<br>
> only affect getting parameters through params, but I think we should let<br>
> Matt chime in on this, since he is the most knowledgeable about this area of<br>
> the code.<br>
><br>
><br>
> However, this also seems to affect things not in params in an undesirable<br>
> way. For example:<br>
><br>
> from yt.mods import *<br>
> all_files = glob.glob("*/*.hierarchy")<br>
> all_files.sort()<br>
> ts = TimeSeries.from_filenames(all_files)<br>
> sphere = ts.sphere("max", (1.0, "pc"))<br>
> L_vecs = sphere.quantities["AngularMomentumVector"]()<br>
><br>
> L_vecs gets returned as something like:<br>
><br>
> [[array([l1,l2,l3])],<br>
> [array([l4,l5,l6])],<br>
> ...<br>
> [array([ln,lm,lo])]]<br>
><br>
> Where once again you have lists of one object, namely in this case the NumPy<br>
> arrays which are the angular momentum vector. So, generically speaking you<br>
> are always getting an extra list in there you don't need, it seems.<br>
><br>
> John<br>
><br>
</div></div><div class="HOEnZb"><div class="h5">> _______________________________________________<br>
> yt-dev mailing list<br>
> <a href="mailto:yt-dev@lists.spacepope.org">yt-dev@lists.spacepope.org</a><br>
> <a href="http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org" target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org</a><br>
><br>
_______________________________________________<br>
yt-dev mailing list<br>
<a href="mailto:yt-dev@lists.spacepope.org">yt-dev@lists.spacepope.org</a><br>
<a href="http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org" target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org</a><br>
</div></div></blockquote></div><br>