[Swift-user] suggestion for program flow control
Michael Wilde
wilde at mcs.anl.gov
Wed Jun 11 17:51:32 CDT 2008
My understanding was that MikeK was not trying to do this for
performance, but was simply unsure of how to pass a large set of files
from one function to the next.
When he said "I do not want to pass a result file for each of the
thousand processed files in the loop" I think he was talking about a
coding issue, not a performance issue.
I did not yet look at his latest Swift code, but suggested he forward it
to the list to ask for advice on how best to express the data flow.
I suspect that one of the existing mappers and correct use of a dataset
type can solve his problem and eliminate the need to for localhost "file
waiting" script. Unless he's tripping into the issue of having an
non-predetermined number of files in the dataset.
Its not clear to me if, when he does that, that new performance issues
wont arise. But lets at least first look at how best to express the problem.
Also, I think the discussion of fold(y) and reduce(y) concepts is likely
very cryptic to non-functional programmers.
- MikeW
On 6/11/08 4:50 PM, Ben Clifford wrote:
>> Since I do no want to pass a result file for each of the thousand
>> processed files in the loop, I have added an additional localhost script
>> that checks to see if X number of results file have been produced and
>> then generates a text file that is passed into the swift function that
>> parses the results.
>
>>From a swift-purist perspective, you shouldn't be saying "I do not want to
> pass files around" without substantial justification (eg. evidence that it
> hurts performance - which it presumably does?). More interesting is to see
> how stuff works entirely file-based and figure out what is going wrong
> with that approach.
>
> What you post sounds like there's some foldy stuff that has been talked
> about before - its probably interesting to talk about that a bit more - eg
> imagine if you could write what you are doing in SwiftScript and point out
> what is going wrong at the moment.
>
More information about the Swift-user
mailing list