APL question

phil chastney <phil.hates.spam@amadeus.munged.eclipse.co.uk> wrote:
> Peter Keller wrote:
>> Gosi <gosinn@gmail.com> wrote:
>>> http://www.pyr.fi/apl/texts/Idiot.htm
>>
>> Unfortunately, even though I have several unicode APL fonts installed,
>> I see garbage for all of the idioms on that site.
>
> the page in question doesn't appear to specify any encoding, so the
> browser will use its default setting

Hrm. I have some other unicode apl pages written in HTML and that stuff
shows up, but the Finn stuff simply doesn't work.

> try switching your browser display to another encoding, one of which
> will almost certainly work, because FinnAPL wouldn't publish rubbish

I realize the error is on my end for why I can't see it, I was just surprised
about it because I can see so much other APL in HTML.

>>> http://en.wikipedia.org/wiki/Critici...mming_language
>>
>> Ah, but the pdf prints out nicely.
>
> PDF? the above URL points to an HTML page

It does, but at the bottom of the page is a PDF of the FinnAPL Idiom set.

The idiom set is very neat, to say the least.

Thank you.

-pete

Pete,

the usual confusion when it comes to APL characters on the
Internet...

The FinnAPL pages are old stuff. It is _not_ using Unicode.

As a result, any Unicode fonts on your machine wont't work. They
CANNOT work.

If you look into the source of the page you will see something like
this: (copied from that page)

<th colspan="2"><!--mstheme--><font face="Trebuchet MS, Arial,
Helvetica"><font size="2" face="Dyalog Std TT">GRADE UP “ </font>
</th>

Which means that the HTML page uses a technique depricated more than a
decade ago to define the font to be displayed. If you got this font
(Dyalog Std TT) installed on your machine, you will see hard-to-read
APL code in italic. If you haven't you don't.

Kai

On Oct 17, 1:57*am, Peter Keller <psil...@merlin.cs.wisc.edu> wrote:
> Paul Houle <asmg...@yahoo.com> wrote:
> > You need to enclose the left argument (scalarizing it) to distribute it
> > properly across all the right arguments.
>
> > * * ({enclose}1 2) berp {each} 0 .1 .2 .3 .4 .5 .6 .7 .8 .9 1
>
> Hrm.... So once inside the berp function, how does berp know that the left
> hand side is a vector of length 2 where index 1 is 1 and index 2 is 2, instead
> of thinking that the left hand side is a single vector which contains
> one element which is another vector containing 1 and 2?
>
> I'm definitely confused on the semantic reasoning for why {enclose} behaves
> correctly in this case.
>
> I'm unsure what the difference are between these and why the
> implementation of berp knows what the left hand side looks like in the
> 1st and 4th example:
>
> * * *1 2 berp .5
> * * *({enclose}1 2) berp .5
> * * *1 2 berp {each} 0 .1 .2 .3 .4 .5 .6 .7 .8 .9 1
> * * *({enclose}1 2) berp {each} 0 .1 .2 .3 .4 .5 .6 .7 .8 .9 1
>
> Thank you.
>
> -pete

Peter, If I may return to your confusion on the EACH operator, let me
try to give you an underlying principle related to it. The EACH
operator is a very powerful operator. Backing up a bit, one of the
features of APL is the way it handles scalar functions, e.g. + - x
etc. With scalar functions APL provides Scalar Extension or Scalar
Conformability. i.e symbolically,
S f A or A f S
where the scalar S is used as many times as necessary to apply the
function to EACH of the the items of the array A.
The operator EACH extends this Scalar Extension capability to ALL
functions beyond the scalar functions.
More formally stated
"The operator EACH builds a scalar derived function that applies
its operands to "each" of the items in the array ONE level down in the
structure."
Thus the enclosure of 1 2 with your berp function was necessary so
that EACH could treat berp properly as a scalar function and apply
Scalar Conformability. But again only ONE level down. I hope this
helps you. This is one of the points that I strongly emphasize in my
classes. Ray Polivka

Polivka@acm.org <Polivka@acm.org> wrote:
> Peter, If I may return to your confusion on the EACH operator, let me
> try to give you an underlying principle related to it. The EACH
> operator is a very powerful operator. Backing up a bit, one of the
> features of APL is the way it handles scalar functions, e.g. + - x
> etc. With scalar functions APL provides Scalar Extension or Scalar
> Conformability. i.e symbolically,
> S f A or A f S
> where the scalar S is used as many times as necessary to apply the
> function to EACH of the the items of the array A.

Could I get more of a formal definition of Scalar Conformability and
Scalar Extension?

> The operator EACH extends this Scalar Extension capability to ALL
> functions beyond the scalar functions.

So, your explanation implies that this can be true:

> 1 + 2 2 2 2 2
3 3 3 3 3

> ({enclose}1) + 2 2 2 2 2
3 3 3 3 3

And, after trying it, I found it (midly surprising) to be true.

Then, I tried this:

> 1 +{each} 2 2 2 2 2
3 3 3 3 3

> ({enclose}1) +{each} 2 2 2 2 2
3 3 3 3 3

And also found it to be true.

> More formally stated
> "The operator EACH builds a scalar derived function that applies
> its operands to "each" of the items in the array ONE level down in the
> structure."
> Thus the enclosure of 1 2 with your berp function was necessary so
> that EACH could treat berp properly as a scalar function and apply
> Scalar Conformability. But again only ONE level down. I hope this
> helps you. This is one of the points that I strongly emphasize in my
> classes. Ray Polivka

I think I see, basically, {each} forces arbitrary functions to act as
primitive functions wrt Scalar Conformability. It seems that the primitive
scalar functions auto enclose their arrays, which is why I was confused in the
first place, because I didn't realize there wasn't a syntactical hint for
the autoenclose with things like + -, etc.

Is this correct?

Thank you.

-pete

Peter Keller wrote:
> phil chastney <phil.hates.spam@amadeus.munged.eclipse.co.uk> wrote:
>> Peter Keller wrote:
>>> Gosi <gosinn@gmail.com> wrote:
>>>> http://www.pyr.fi/apl/texts/Idiot.htm
>>> Unfortunately, even though I have several unicode APL fonts installed,
>>> I see garbage for all of the idioms on that site.
>> the page in question doesn't appear to specify any encoding, so the
>> browser will use its default setting
>
> Hrm. I have some other unicode apl pages written in HTML and that stuff
> shows up, but the Finn stuff simply doesn't work.
>
>> try switching your browser display to another encoding, one of which
>> will almost certainly work, because FinnAPL wouldn't publish rubbish
>
> I realize the error is on my end for why I can't see it, I was just surprised
> about it because I can see so much other APL in HTML.

yup, and I can see much that is plain, simple English, but not always

the main issues are
(i) does the HTML page specify an encoding?
what does the browser do with that information?
what does the browser do by default?
(ii) what fonts does the page specify?
are they available on the client machine?
what fallback mechanism is there?

fairly simple stuff, really

>>>> http://en.wikipedia.org/wiki/Critici...mming_language
>>> Ah, but the pdf prints out nicely.
>> PDF? the above URL points to an HTML page
>
> It does, but at the bottom of the page is a PDF of the FinnAPL Idiom set.

sorry, I didn't see the PDF

PDFs use a slightly different mechanism from that employed by HTML

a PDF may, or may not, embed required fonts -- in this case, only one
font is used throughout, and one font is embedded as a subset, so
everything is tickety-boo, because it doesn't require anything from your
machine, except a viewer

(HTML can also embed fonts, but that's a separate issue)

/phil

On Oct 21, 11:06*pm, Peter Keller <psil...@merlin.cs.wisc.edu> wrote:
> Poli...@acm.org <Poli...@acm.org> wrote:
> > Peter, If I may return to your confusion on the EACH operator, let me
> > try to give you an underlying principle related to it. *The EACH
> > operator is a very powerful operator. *Backing up a bit, one of the
> > features of APL is the way it handles scalar functions, e.g. + - x
> > etc. *With scalar functions APL provides Scalar Extension or Scalar
> > Conformability. *i.e symbolically,
> > * * *S f A * or A f S
> > where the scalar S is used as many times as necessary to apply the
> > function to EACH of the the items of the array A.
>
> Could I get more of a formal definition of Scalar Conformability and
> Scalar Extension?
>
> > The operator EACH extends this Scalar Extension capability to ALL
> > functions beyond the scalar functions.
>
> So, your explanation implies that this can be true:
>
> > 1 + 2 2 2 2 2
>
> 3 3 3 3 3
>
> > ({enclose}1) + 2 2 2 2 2
>
> 3 3 3 3 3
>
> And, after trying it, I found it (midly surprising) to be true.
>
> Then, I tried this:
>
> > 1 +{each} 2 2 2 2 2
>
> 3 3 3 3 3
>
> > ({enclose}1) +{each} 2 2 2 2 2
>
> 3 3 3 3 3
>
> And also found it to be true.
>
> > More formally stated
> > * "The operator EACH builds a scalar derived function that applies
> > its operands to "each" of the items in the array ONE level down in the
> > structure."
> > Thus the enclosure of 1 2 with your berp function was necessary so
> > that EACH could treat berp properly as a scalar function and apply
> > Scalar Conformability. *But again only ONE level down. *I hope this
> > helps you. *This is one of the points that I strongly emphasize in my
> > classes. *Ray Polivka
>
> I think I see, basically, {each} forces arbitrary functions to act as
> primitive functions wrt Scalar Conformability. It seems that the primitive
> scalar functions auto enclose their arrays, which is why I was confused in the
> first place, because I didn't realize there wasn't a syntactical hint for
> the autoenclose with things like + -, etc.
>
> Is this correct?
>
> Thank you.
>
> -pete

Peter, There is nothing more formally to say with repect to Scalar
Conformability.
the patterns are S sf S, S sf A, A sf S, A sf B.
In the A sf B case the obvious requirement is that the arrays have the
same shape.
However, there are some other points to make abour scalar functions.
First of all in the four major vendors of APL; APL2, Dyalog, APLX, and
APL_WIN, the enclosure of a simple scalar has no effect. The
enclosure of a scalar matches the scalar. I.e. enclosure of a simple
scalar produces no structural change. Historically, this behavior
provided much (heated?) discussion with the advent of nested arrays.
I'm not sure if J, K, A+, or Visual APLaccept that definition.
Someone else can respond for them.
A second behavior of scalars is that they pervade/ penetrate
through the whole structure. For example if you multiplied 10 by the
item {enclosure}(({enclosure 2 2) 2) you will get each of the scalar
numbers multipled by 10 with in the Same structure.
Since this is the case, one never needs to apply EACH to any scalar
function. Now note the point I emphasized in the definitin of EACH,
yes the resulting derived function behaves like a scalar BUT only ONE
level down in the structure.
What APL system are you using? All of them have the function DISPlAY
in some variation. It is a very useful function to use on nested
arrys. I have found writing the foloowing simple function has been
quite useful (at least to me).

On Oct 21, 11:06*pm, Peter Keller <psil...@merlin.cs.wisc.edu> wrote:
> Poli...@acm.org <Poli...@acm.org> wrote:
> > Peter, If I may return to your confusion on the EACH operator, let me
> > try to give you an underlying principle related to it. *The EACH
> > operator is a very powerful operator. *Backing up a bit, one of the
> > features of APL is the way it handles scalar functions, e.g. + - x
> > etc. *With scalar functions APL provides Scalar Extension or Scalar
> > Conformability. *i.e symbolically,
> > * * *S f A * or A f S
> > where the scalar S is used as many times as necessary to apply the
> > function to EACH of the the items of the array A.
>
> Could I get more of a formal definition of Scalar Conformability and
> Scalar Extension?
>
> > The operator EACH extends this Scalar Extension capability to ALL
> > functions beyond the scalar functions.
>
> So, your explanation implies that this can be true:
>
> > 1 + 2 2 2 2 2
>
> 3 3 3 3 3
>
> > ({enclose}1) + 2 2 2 2 2
>
> 3 3 3 3 3
>
> And, after trying it, I found it (midly surprising) to be true.
>
> Then, I tried this:
>
> > 1 +{each} 2 2 2 2 2
>
> 3 3 3 3 3
>
> > ({enclose}1) +{each} 2 2 2 2 2
>
> 3 3 3 3 3
>
> And also found it to be true.
>
> > More formally stated
> > * "The operator EACH builds a scalar derived function that applies
> > its operands to "each" of the items in the array ONE level down in the
> > structure."
> > Thus the enclosure of 1 2 with your berp function was necessary so
> > that EACH could treat berp properly as a scalar function and apply
> > Scalar Conformability. *But again only ONE level down. *I hope this
> > helps you. *This is one of the points that I strongly emphasize in my
> > classes. *Ray Polivka
>
> I think I see, basically, {each} forces arbitrary functions to act as
> primitive functions wrt Scalar Conformability. It seems that the primitive
> scalar functions auto enclose their arrays, which is why I was confused in the
> first place, because I didn't realize there wasn't a syntactical hint for
> the autoenclose with things like + -, etc.
>
> Is this correct?
>
> Thank you.
>
> -pete

Oops I seem to have pushed the wrong key. Here is the function.
Z{is} VIEW X
[1] 'Shape:' ({shape} x) 'Depth:' {{depth} x)
[2] Z {is} DISPLAY X
note with this function you have the option of not viewing or delaying
the view of the DISPLAY by assigning the result of VIEW to a
variable. The VIEW function can provide much insight when working
with nested arrays. Ray

Polivka@acm.org <Polivka@acm.org> wrote:
> Oops I seem to have pushed the wrong key. Here is the function.
> Z{is} VIEW X
> [1] 'Shape:' ({shape} x) 'Depth:' {{depth} x)
> [2] Z {is} DISPLAY X
> note with this function you have the option of not viewing or delaying
> the view of the DISPLAY by assigning the result of VIEW to a
> variable. The VIEW function can provide much insight when working
> with nested arrays. Ray

Your explanation was useful, and that function is also useful.

Thank you!

-pete

P.S. I use APLX 1.1 for linux.