Newsgroups: comp.lang.apl
Path: watmath!watserv2.uwaterloo.ca!torn!cs.utexas.edu!uunet!mcsun!chsun!bernina!hoesel
From: hoesel@igc.ethz.ch (Frans van Hoesel)
Subject: Re: what about func(a,a,a)
Message-ID: <1992Dec4.111043.20054@bernina.ethz.ch>
Sender: news@bernina.ethz.ch (USENET News System)
Organization: University of Groningen, the Netherlands
References: <1992Dec3.120841.9774@bernina.ethz.ch> <1992Dec3.170007.16358@csi.jpl.nasa.gov>
Date: Fri, 4 Dec 1992 11:10:43 GMT
Lines: 82

In article <1992Dec3.170007.16358@csi.jpl.nasa.gov> sam@csi.jpl.nasa.gov (Sam Sirlin) writes:
>
>In article <1992Dec3.120841.9774@bernina.ethz.ch>, hoesel@igc.ethz.ch (Frans van Hoesel) writes:
>|> So I'm writing another language that does array processing (don't blame
>|> me for that please). 
>
>Without any implicit blame I'd still like to ask why.

I'm writing data -processing software, and at the point of writing a completle
new version. (due to populary demand). Now the old version had a function
called fft. The user can call this with a 1D array or a multi-D array, but
the difference is handled by some hardcoding inside the subroutine.
I would like to change this behaviour, so one could simply code a 1D
version of fft, and still call it with multi-D arrays. Now fft has an extra
parameter: size, specifying the size of the result (done by zero-filling the
original data). so calling fft(1darray, scalarsize) no problem
calling fft(2darray, scalarsize) no problem... loop over the rows in the array
calling fft(1darray, 1dsize) (make a 2-d result... note this would
					be impossible, just by the fact
					that the size is different, so I
					should change this example to
					something more realistic, but you'll get
					the picture)
calling fft(2darray, 1dsize) (make a 3d result)

but now a function sum(int a[*], b[*]) (note the '*' indicates 1D array
call sum(1darr, 1darr)  no problem... 1d result (adding correspondiing elem)
call sum(2darr, 1darr)  no problem ... 2dresult
call sum(2darr, 2darr)  2d result expected (added corr. elem.) but in analogy
			with fft the result would be 3d!

>
>|> Suppose that a user write[s] a function myfunc
>|> int[] myfunc(int a[], int b[])
>|> the function is expected to work with 1D arrays. 
>
>How is this specified? This is a hint towards a solution.
 
int a[*] --> 1D argument expected, int a[*,*] --> 2d. so actually
I should have added the '*' in the above example.
>
>|> If it is called
>|> with a 2D array, then the compiler will generate an implied loop
>|> repeatedly calling the function with all the rows in the
>|> 2D array. What must happen if I call the function with both arguments
>|> being a 2D array?
>|> Should one expect  a loop over a loop, or just one loop running in
>|> parallel over both the arguments?, what if the shape of the arrays
>|> isn't the same?
>
>All of the above, of course! What you want is the concept of rank in
>J. I'd recommend you get the documentation, since $30 or so isn't too
>much of an investment when you're building a new language. 

ok, but can you tell me how to order it from the netherlands. I have the 
doc's that came with J-6 (ftp-ed)
>
[deleted long, but useful example of inproduct]

so  inproduct(2darr, 1darr) gives a 2d result, whee as
    inproduct(1darr, 2darr) gives a 1d result.
This may be fine for J, but strikes me when use inside a normal (?)
function call, and this comes back to the question what about
func(a,a,a)
>
>Of course all verbs (functions that act on nouns [numbers or
>characters]) have a monadic, left, and right rank, so I can actually
>specify these separately, for example:
>
>   m i"0 1 n
> 3.5       7
>7.75 10.3333
>
This one I didn't get sam, can you translate it in english?

-- frans


-- 
      ================================================================
      ===  frans van hoesel               hoesel@igc.ethz.ch       ===
      ================================================================
