Brad Chamberlain wrote:
>
> Hi Greg --
>
> Sorry for the delayed response. We had some network reconfigurations
> going on Friday which made it a good day to avoid email and get some
> other work done.
>
>> 1. What does the declaration of an array as a return type look like?
>> 'proc p() : [] int { }' doesn't seem to work, but you can leave
>> off the type in the declaration and do 'return arrayvar;' and
>> that gets figured out.
>
> At present, I believe that the only two forms are a fully-specified
> array type, e.g.:
>
> proc p(): [D] int { ... }
>
> or a fully inferred one:
>
> proc p() { ... }
>
> Ultimately, I think we'd like to support more inferred forms as well,
> such as the form you show or:
>
> proc p(): [D] { ... } // infer array's element type, not domain
> proc p(): [] { ... } // infer both domain and elt type
>
>
>> 2. Is this a wise thing to do? Can you return an array that's been
>> created in a sub-routine?
>> We had thought about doing was get a list of results from one
>> sub-routine, where the number wasn't known in advance, for
>> processing by another. The code might look like
>> var matches : [] 2*(2*int);
>> matches = find_matching_points(pts1, pts2);
>> where find_matching_points counts the number of matches, creates
>> an array to hold them, and then copies the matches into the result
>> before returning it. We weren't sure if this would work, though,
>> and took another approach.
>
> Yes, you can return an array that's been created in a subroutine, and I
> think this is something we're going to want/need to continue to support.
> One motivating example, similar to yours, is a helper routine that reads
> an array in from a file without knowing how large that array is going to
> be.
>
> As you may have seen in other threads, we're currently revamping the way
> our automated-memory management is being implemented, and as part of
> that, we're reconsidering how this case is implemented today (and how it
> should be in the future), but I don't anticipate the feature going away.
>
> Here's a toy sample program that demonstrates creating and returning an
> array in a helper routine:
>
> ---
>
> proc createarray(n) {
> var D = {1..n, 1..n};
> var A: [D] real;
> forall (i,j) in D do A[i,j] = i: real + j / 10.0;
> return A;
> }
>
> var B = createarray(3);
> writeln(B);
> writeln(B.domain);
> writeln(typeToString(B.eltType));
>
> var C = createarray(5);
> writeln(C);
> writeln(C.domain);
> writeln(typeToString(C.eltType));
>
> ---
>
>
>> 3. It seems to be a bad idea to put arrays inside records that are
>> passed as arguments, because of the pass-by-value behavior. Is
>> this a fair statement, or should it be safe?
>
> Barring any bugs, records should be passed by 'const ref' by default, so
> should not be copied when being passed around, nor should any array
> fields within them. I wouldn't shy away from putting array fields in
> records for this reason.
>
>> One sub-routine used an inout intent on a record with arrays that
>> it populated.
>
> Note that 'inout' means "copy the record in; copy the record out", as
> compared to (say), 'ref' or 'const ref' which says to pass a reference
> to the record in/out. (So passing records by 'inout' would result in
> copies of their fields).
>
>> It would cause the program to segfault or die with
>> a nil dereference about half the time.
>
> I'm not sure what would be causing this, and would be interested in
> getting a copy of such a test to look into it further.
>
Can do. This one is actually in the repository ...
>
>
>> 5. The spec (p. 170) says that domain.exterior(), interior(), and
>> translate() can take a single integer argument, but this causes
>> a compilation error.
>> const dom : domain(rank=2) = { 1..10, 1..10 };
>> writeln("exterior(2,2) ", dom.exterior(2,2));
>> writeln("exterior(2) ", dom.exterior(2));
>> The first call is accepted, the second produces
> [errors]
>
> Huh, you're right... I could've sworn we used to support the
> single-integer form of these, so either my memory is off or else someone
> retired them without updating the spec. I assume you'd find the
> single-argument form a nice convenience? If so, I can dig deeper and
> see if they were removed (and if so, why) or if I'm misremembering.
>
This was something that came up in an example using the functions.
One of the programs was a convolution and we were generating the
interior of a larger array to iterate over. Since the kernels
were square we tried the single argument method, which failed.
Greg
------------------------------------------------------------------------------
_______________________________________________
Chapel-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/chapel-users
