[Swift-devel] Re: [Swift-user] assigning file variables
Michael Wilde
wilde at mcs.anl.gov
Thu Feb 26 01:05:35 CST 2009
(Im moving this back from swift-user to swift-devel)
--
Another aspect of where I'm stuck at the moment is this:
Recall (from previous posts ;) that I have 3 nested loops:
foreach protein in plist {
iterate {
foreach i in [1:N]
randomlyFoldProtein()
}
} until convergence or limit reached
}
In testing the "simulated" version of this (my oops8e.swift example) I
had to put the inner folding "round" into a function, in order to force
the closing of the array of result files returned by the inner foreach.
That was fine, with simple_mapper, because I had pre-mapped the entire
2D result[][] array with simple_mapper, and Swift still let me return an
inner array and assign it to a member of the outer array:
foreach p, pn in protein {
file result[][]
<simple_mapper; prefix=@strcat("output/",p,"/"),suffix=".pdt">;
iterate i {
result[i] = doRound(p,i);
} until (roundDone(result[i],pn) == 1);
}
But, that test was over-simplified, because it didnt handle the fact
that these returns are really 6-file structs, which motivated me to try
ext mapper.
But that decision led me back in circles, bouncing between Swift
limitations:
- ext-mapper cant pre-map a dynamic output structure with any dimensions
whose size cant be passed to the mapper (I think?)
- arrays can only be closed via return from functions
- files and structs with files have limitations on assignments
- I cant set a mapping any time I want on any member (field or element)
of any structure.
Here's a related question: Is it the case that if a function returns an
array, that array *must* be declared and mapped in the calling function,
*not* in the called function? Eg, I cant dynamically declare and map an
array *within* a function and return that array out? (I'll try this in
the morning).
I think I can solve my problems by retreating from ext mapper and
accepting the naming conventions of simple_mapper, but the set of
restrictions was interesting.
This makes me more determined to re-open the discussion on the nature of
object, variables, handles, scope, and lifetime, as it seems to me that
part of the problem comes from an object model thats almost, but not
quite, as regular as it should be.
- Mike
On 2/26/09 12:13 AM, Michael Wilde wrote:
> Can you clarify how the ext mapper behaves differently from say the
> simple_mapper for output files, and if the following is correct?
>
> It seems that for the simple_mapper, the mapper parameters define a
> prefix/suffix, and these strings are used wherever necessary at runtime
> to form a mapping for any object composed of (possibly nested) structs
> and arrays, by bracketing the dynamically-constructed object path.
>
> But when the ext mapper is used for output, it is expected, in a single
> call, to map the entire structure (and hence can only do static mappings)?
>
> I thought I had my problem solved using the ext mapper, but the
> combination of restrictions on assigning file variables and getting the
> right info to the ext mapper seems to be forcing me back to simple_mapper.
>
> (I'll try to assemble examples when I have more time)
>
> On 2/25/09 9:50 AM, Ben Clifford wrote:
>> On Wed, 25 Feb 2009, Mihael Hategan wrote:
>>
>>> it would be preferable to map t to what m is mapped to
>>> from the start
>>
>> right. often (always?) the desire to do this kind of assignment comes
>> from insufficient expressiveness in our mapping semantics. in the
>> foreach case, I think my email suggests a reasonable alternative to
>> assignments that allows mapping to be generated inside of Swift. In
>> the iterate{} case, that in-swift expression is not possible at the
>> moment, but could be. For example, soemthing like the ext mapper that
>> only maps output files, not inputs, and calls a specified swift
>> procedure to do that mapping. (thates something that has been
>> discussed before, I think)
>>
> _______________________________________________
> Swift-user mailing list
> Swift-user at ci.uchicago.edu
> http://mail.ci.uchicago.edu/mailman/listinfo/swift-user
More information about the Swift-devel
mailing list