Discussion:
Running APL\360 on OS/360-MVT 21.8F: Minimal OPFNS Workspace available
(too old to reply)
Juergen
2013-01-05 13:28:21 UTC
Permalink
Hi All,

since the publication of MVT for APL version 1.00 comments not unexpectedly show that handling the OPR user which is signed on to the recording terminal raises problems: Especially beginners tend to lose the correct unlock/lock rhythm when working at that terminal which then leads to unwanted effects.

During APL\360 operations the only reason to "use" the recording terminal is to enter privileged commands or I-Beams because it is the only privileged terminal in the system. Note that "privileged" is an attribute of a terminal, not of a user. It can be assigned to a signed on terminal and lasts until it gets either explicitely removed or the user signs off.

As opposed to early versions of APL\360 the 5734-XM6 version we are using today doesn't have the )PRIV system command to privilege other terminals: In the 5734-XM6 version this type of functions is contained in the OPFNS workspace instead, which still is missing in action.

With the intention to just implement the PRIVILEGE function I had a look at the definitions of the dyadic I-Beams and at "Table 1. Summary of APL\360 Special Operator Function" on page 36 of the APL\360 General Information Manual (GH20-0850-1) only to find that while I'm at it, it would make more sense to implement an at least minimal subset of the ecosystem that the table suggests: Obviously OPFNS isn't just a set of standalone functions, but most of the functions are operating on vectors of ports and can be connected directly with each other or by using and, or, not logicals.

This ecosystem gives interesting options in operating APL\360, like for example:

Entering

PRIVILEGE MEMO<-ON AND NOT PRIVILEGED

will privilege all terminals that are currently signed on but not privileged and remembers their port numbers in vector MEMO. Entering then later

DEPRIVILEGE MEMO

will deprivilege exactly those terminals. And so on...

Sadly the above mentioned table isn't very specific, but it is the only information I have that can be used to define the functions in OPFNS. An open point is in particular how output of the "sinks" in function chains should look like: Just a vector of attributes, or a table listing objects with their attributes? And which attributes shall be listed? So, for the time being I stopped here and defined just one of these "sink" functions: The PORT function, which should according to the table report brief information on a vector of ports. I implemented it such that it delivers a vector of APL user numbers, being signed on currently (signed on port) or previously (signed off port). If one then wants a table (similar to the one the )PORTS command delivers) one has to do the APLish way what it takes to format the output. Perhaps someone remembers what type the output of these "sink" functions created, just vectors or ready made tables?

Well, enough chatting:

Please find some sample usage and a complete printout of that minimal OPFNS workspace at

http://wotho.ethz.ch/opfns.pdf

Although this workspace (like the previously published SINPLT and BEER workspaces) could be input into your system using line by line copy and paste to a 1052 terminal, it's probably not feasible to do so as it's already quite a bit of code. So I've created an AWS tape from this workspace using the SELDUMP function of the APL utility program. This tape can be found at

http://wotho.ethz.ch/opfns.zip

To load it use the following utility control statements:

//SYSIN DD *
WSLIST
SELREST
/*

Use for example the APLCRTE job as a base, replace the control statements with the above ones and give it the opfns.aws tape instead of the apllib.aws tape. The utility will then replace the existing empty dummy OPFNS workspace from the MVT for APL distribution with the new one.

Have fun!

Cheers, Juergen
Mike Stramba
2013-01-06 01:52:40 UTC
Permalink
Hi Juergen,

Well I managed to install it, so that means *anybody* should be able to :)

I didn't change either of the TAPE DD statements in the JCL.

What does APLLIB refer to ?

I looked at the aws tape with hetmap :

Volume Serial : '*NOLBL'

And LISTDS 'APLLIB' gives : DATA SET 'APLLIB' NOT IN CATALOG
TAPE1 DD UNIT=280,LABEL=(,BLP),VOLUME=SER=APLLIB,DISP=(,KEEP)
DSNAME=APLLIB

Mike
Post by Juergen
Hi All,
since the publication of MVT for APL version 1.00 comments not unexpectedly
show that handling the OPR user which is signed on to the recording terminal
raises problems: Especially beginners tend to lose the correct unlock/lock
rhythm when working at that terminal which then leads to unwanted effects.
During APL\360 operations the only reason to "use" the recording terminal is
to enter privileged commands or I-Beams because it is the only privileged
terminal in the system. Note that "privileged" is an attribute of a
terminal, not of a user. It can be assigned to a signed on terminal and
lasts until it gets either explicitely removed or the user signs off.
As opposed to early versions of APL\360 the 5734-XM6 version we are using
today doesn't have the )PRIV system command to privilege other terminals: In
the 5734-XM6 version this type of functions is contained in the OPFNS
workspace instead, which still is missing in action.
With the intention to just implement the PRIVILEGE function I had a look at
the definitions of the dyadic I-Beams and at "Table 1. Summary of APL\360
Special Operator Function" on page 36 of the APL\360 General Information
Manual (GH20-0850-1) only to find that while I'm at it, it would make more
sense to implement an at least minimal subset of the ecosystem that the
table suggests: Obviously OPFNS isn't just a set of standalone functions,
but most of the functions are operating on vectors of ports and can be
connected directly with each other or by using and, or, not logicals.
Entering
PRIVILEGE MEMO<-ON AND NOT PRIVILEGED
will privilege all terminals that are currently signed on but not privileged
and remembers their port numbers in vector MEMO. Entering then later
DEPRIVILEGE MEMO
will deprivilege exactly those terminals. And so on...
Sadly the above mentioned table isn't very specific, but it is the only
information I have that can be used to define the functions in OPFNS. An
open point is in particular how output of the "sinks" in function chains
should look like: Just a vector of attributes, or a table listing objects
with their attributes? And which attributes shall be listed? So, for the
The PORT function, which should according to the table report brief
information on a vector of ports. I implemented it such that it delivers a
vector of APL user numbers, being signed on currently (signed on port) or
previously (signed off port). If one then wants a table (similar to the one
the )PORTS command delivers) one has to do the APLish way what it takes to
format the output. Perhaps someone remembers what type the output of these
"sink" functions created, just vectors or ready made tables?
Please find some sample usage and a complete printout of that minimal OPFNS workspace at
http://wotho.ethz.ch/opfns.pdf
Although this workspace (like the previously published SINPLT and BEER
workspaces) could be input into your system using line by line copy and
paste to a 1052 terminal, it's probably not feasible to do so as it's
already quite a bit of code. So I've created an AWS tape from this workspace
using the SELDUMP function of the APL utility program. This tape can be
found at
http://wotho.ethz.ch/opfns.zip
//SYSIN DD *
WSLIST
SELREST
/*
Use for example the APLCRTE job as a base, replace the control statements
with the above ones and give it the opfns.aws tape instead of the apllib.aws
tape. The utility will then replace the existing empty dummy OPFNS workspace
from the MVT for APL distribution with the new one.
Have fun!
Cheers, Juergen
Juergen
2013-01-06 09:13:15 UTC
Permalink
Post by Mike Stramba
Hi Juergen,
Well I managed to install it, so that means *anybody*
should be able to :)
I didn't change either of the TAPE DD statements in the JCL.
What does APLLIB refer to ?
Volume Serial : '*NOLBL'
And LISTDS 'APLLIB' gives : DATA SET 'APLLIB' NOT IN CATALOG
TAPE1 DD UNIT=280,LABEL=(,BLP),VOLUME=SER=APLLIB,DISP=(,KEEP)
DSNAME=APLLIB
Mike
Hi Mike,

handling of the APL utility program is very straightforward. It can conveniently be used to exchange workspaces across APL\360 installations but not to and from other APL implementations (like the MTS APL version Phil is currently looking at).

You're of course right in that the //TAPEx DD statements don't have to be changed ever: The tapes themselves are nolabel and the JCL specifies bypass label processing, which means that on input any tape is accepted as long as its contents matches the utility operation requested and on output any tape is accepted and overwritten, regardless of its previous contents. That's easy to handle JCL-wise but bears some danger when mixing up tapes unintentionally.

For that reason I'm normally using a VOLUME and DSN in the JCL that matches the filename of the AWS file, i.e. as above DSN=APLLIB and VOL=SER=APLLIB are intended for use with apllib.aws (the initial empty library initialization tape). But that's simply a convention that isn't enforced by any APL\360, MVT or Hercules mechanism... so, clearly, careful manual verification by the "operator" is in order when using tapes the way APL\360 does.

Cheers, Juergen
halfmeg
2013-01-09 15:52:08 UTC
Permalink
Post by Juergen
handling of the APL utility program is very straightforward. It can
conveniently be used to exchange workspaces across APL\360
installations but not to and from other APL implementations (like
the MTS APL version Phil is currently looking at).
To exchange workspaces with another APL implementation is not easy. There seems to be a IN and/or OUT function on some APL versions but not the 360 version.

Tony mentioned the APL blob from SharpAPL might be used as a TSO version. It is suppose to be a 370 Object program surrounded by support for running in a MS-DOS window. The MTS APL implementation also seems to have just retained the APL blob and substituted the MTS I/O and support for execution as there is no 'started' task and operation is similar to individual TSO sessions for use.

There are currently no 2741 terminals defined in the MTS Turnkey, so no native APL symbols are available during APL execution even with the Hercules mods to enable 2741 connections. Having a 'original' implementation on MVT and a modified implementation on MTS would be much simpler to compare if the displays were compatible. Even if they were however, the keyboard mapping would be different as MTS APL commands have to be in CAPS while CAPS on MVT generate the APL symbol set of characters.

I initially thought the OPFNS was the WSFNS workspace but have gotten over that misconception. There is a comment in the MTS documentation for APL that PORTS was not implemented on MTS. There is also a comment in the latest MTS distribution tapes that APL/360 isn't supported and just before that a blurb about EBCASC and ASCEBC now being reversible. Since I was looking at the data via AWSBrowse and not a printed document they may not have anything to do with each other as formating is sometimes a little indecipherable when viewing that way. Documents in MTS also have formating controls as well so running them through 'FORMAT' to the printer give a clearer picture.

Regardless, it makes me a little uneasy trying to compare the two APL implementations.

Phil
Juergen
2013-01-13 17:25:35 UTC
Permalink
Hi All,
Post by Juergen
Please find some sample usage and a complete printout of
that minimal OPFNS workspace at
. . .
Although this workspace (like the previously published SINPLT
and BEER workspaces) could be input into your system using line by
line copy and paste to a 1052 terminal, it's probably not feasible
to do so as it's already quite a bit of code.
In fact it's not only not feasible, it's impossible: Copy and paste is possible between an APL\360 session on a 1052 terminal and a single byte encoded text file (the "ANSI" type from notepad) only. I didn't realize that Acrobat Distiller didn't care about the original encoding when embedding the APL font and thus the workspaces can't be entered by copying and pasting from the PDF files I published.

So I'm no longer publishing PDF listings from workspaces but utility dump tapes only. Even if copy and paste worked it would be tedious and error prone, so the utility dump tapes are for sure the way to go as long as we're talking APL\360 only.

During analysis of the "missing midnight" date and time problem I've extended the OPFNS workspace by a few functions:

- AH adds to hexadecimal "scalars"
- MAP displays the APLSXREF CSECT map
- CSECT returns hex address of a CSECT in MAP
- HTD converts hex vector (i.e. array of hex "scalars") to integers
- SETDATE initializes time and date to the current time at an arbitrary date

Call the DESCRIBE function for a list of all functions available.

HTD translates 4-byte hex values to signed fullword integers, all other lenghts to unsigned. Conversely DTH has been modified to convert integer values between -2**31 and 0 to 4-byte hex values.

The SETDATE function is a kludge/glitch to circumvent the "missing midnight" problem that occurs when APL\360 runs over midnight: I does then continue to count the hours (i.e. 24, 25, 26, ad infinitum) but doesn't increment the date. Entering SETDATE 'mm/dd/yy' from a privileged terminal initializes time and date as if APL\360 had been started at the given date at the current time. Once the function has been executed, the recording terminal _must_ be signed off and back on (this will not harm any active user sessions). See http://wotho.ethz.ch/APL360_date_time.pdf for sample usage (look at the dates and times marked in blue).

I've put the new OPFNS workspace and others I published earlier (BEER, SINPLT, CHARSET, TIMESTABLES, UTILITIES) on a single tape for easy installation. It can be found at

http://wotho.ethz.ch/sample_workspaces.zip

See the included README.txt for installation methods and requirements.

Cheers, Juergen
Mike Stramba
2013-01-14 01:40:28 UTC
Permalink
Juergen,

Haven't loaded that yet, still trying to figure out your DTH function.

What would the function look like if it only accepted *one* decimal number ?

Maybe that will be remotely comprehensible :)

The terse defintions for the basic operators in the Dyalog help aren't
that helpful for a noob.

It appears there is some apl-automagical-recursion going on (isn't
there always ? .. that being the point I guess),

Mike
Post by Juergen
Hi All,
Post by Juergen
Please find some sample usage and a complete printout of
that minimal OPFNS workspace at
. . .
Although this workspace (like the previously published SINPLT
and BEER workspaces) could be input into your system using line by
line copy and paste to a 1052 terminal, it's probably not feasible
to do so as it's already quite a bit of code.
In fact it's not only not feasible, it's impossible: Copy and paste is
possible between an APL\360 session on a 1052 terminal and a single byte
encoded text file (the "ANSI" type from notepad) only. I didn't realize that
Acrobat Distiller didn't care about the original encoding when embedding the
APL font and thus the workspaces can't be entered by copying and pasting
from the PDF files I published.
So I'm no longer publishing PDF listings from workspaces but utility dump
tapes only. Even if copy and paste worked it would be tedious and error
prone, so the utility dump tapes are for sure the way to go as long as we're
talking APL\360 only.
During analysis of the "missing midnight" date and time problem I've
- AH adds to hexadecimal "scalars"
- MAP displays the APLSXREF CSECT map
- CSECT returns hex address of a CSECT in MAP
- HTD converts hex vector (i.e. array of hex "scalars") to integers
- SETDATE initializes time and date to the current time at an arbitrary date
Call the DESCRIBE function for a list of all functions available.
HTD translates 4-byte hex values to signed fullword integers, all other
lenghts to unsigned. Conversely DTH has been modified to convert integer
values between -2**31 and 0 to 4-byte hex values.
The SETDATE function is a kludge/glitch to circumvent the "missing midnight"
problem that occurs when APL\360 runs over midnight: I does then continue to
count the hours (i.e. 24, 25, 26, ad infinitum) but doesn't increment the
date. Entering SETDATE 'mm/dd/yy' from a privileged terminal initializes
time and date as if APL\360 had been started at the given date at the
current time. Once the function has been executed, the recording terminal
_must_ be signed off and back on (this will not harm any active user
sessions). See http://wotho.ethz.ch/APL360_date_time.pdf for sample usage
(look at the dates and times marked in blue).
I've put the new OPFNS workspace and others I published earlier (BEER,
SINPLT, CHARSET, TIMESTABLES, UTILITIES) on a single tape for easy
installation. It can be found at
http://wotho.ethz.ch/sample_workspaces.zip
See the included README.txt for installation methods and requirements.
Cheers, Juergen
Juergen
2013-01-14 12:56:47 UTC
Permalink
Post by Mike Stramba
Juergen,
Haven't loaded that yet, still trying to figure out your
DTH function.
What would the function look like if it only accepted *one*
decimal number ?
Maybe that will be remotely comprehensible :)
The terse defintions for the basic operators in the Dyalog
help aren't that helpful for a noob.
Hi Mike,

I strongly recommend sticking to the APL\360 User's Manual (GH20-0906-1). It has comprehensive descriptions of the language concepts as well as of the specific implementation. APL developed many dialects over time, so using a manual of a different implementation may lead to wrong conclusions.

The encode function (the operator looking like a smaller capital letter T) is the key to the DTH function. You'll find it explained in the User's Manual on page 3.44.

A typicsl method to understand an APL program is to test parts of the expression in question interactively. So, for example, try to evaluate what's written to the right and to the left of the encode operator separately.

Btw.: The function used on a single decimal value smaller than 16 reads '0123456789ABCDEF'[1-16Tn] where T means the encode operator and n means the decimal value. Now try to understand what happens when n is 16 or higher. Then you'll get it.

Cheers, Juergen
Mike Stramba
2013-01-14 14:02:55 UTC
Permalink
Juergen,
Post by Juergen
I strongly recommend sticking to the APL\360 User's Manual (GH20-0906-1). It has comprehensive descriptions of the language concepts as well as of the specific implementation. APL developed many dialects over time, so using a manual of a different implementation may lead to wrong conclusions.
Ok, thx will do.
Post by Juergen
Btw.: The function used on a single decimal value smaller than 16 reads '0123456789ABCDEF'[1-16Tn] where T means the encode operator and n means the decimal value. Now try to understand what happens when n is 16 or higher. Then you'll get it.
Thanks for that, that gives me a start.
Post by Juergen
A typical method to understand an APL program is to test parts of the expression in question interactively. So, for example, try to evaluate what's written to the right and to the left of the encode operator separately.
That's what I've been trying to do,

Mike
Post by Juergen
Post by Mike Stramba
Juergen,
Haven't loaded that yet, still trying to figure out your
DTH function.
What would the function look like if it only accepted *one*
decimal number ?
Maybe that will be remotely comprehensible :)
The terse defintions for the basic operators in the Dyalog
help aren't that helpful for a noob.
Hi Mike,
I strongly recommend sticking to the APL\360 User's Manual (GH20-0906-1). It
has comprehensive descriptions of the language concepts as well as of the
specific implementation. APL developed many dialects over time, so using a
manual of a different implementation may lead to wrong conclusions.
The encode function (the operator looking like a smaller capital letter T)
is the key to the DTH function. You'll find it explained in the User's
Manual on page 3.44.
A typicsl method to understand an APL program is to test parts of the
expression in question interactively. So, for example, try to evaluate
what's written to the right and to the left of the encode operator
separately.
Btw.: The function used on a single decimal value smaller than 16 reads
'0123456789ABCDEF'[1-16Tn] where T means the encode operator and n means the
decimal value. Now try to understand what happens when n is 16 or higher.
Then you'll get it.
Cheers, Juergen
Mike Stramba
2013-01-14 20:28:08 UTC
Permalink
Post by Mike Stramba
Juergen,
Post by Juergen
I strongly recommend sticking to the APL\360 User's Manual (GH20-0906-1).
PIA that it's not searchable. Oh well at least it exists online for free

"Cup" half full ? (heh sorry).

Anybody have an OCR'd one ?

I found a freeware OCR program ... problem is it only does ONE page at a time :\

Mike
"Fish" (David B. Trout)
2013-01-15 08:53:53 UTC
Permalink
Mike Stramba wrote:

[...]
Post by Mike Stramba
I found a freeware OCR program ...
problem is it only does ONE page at a time
:\
I haven't tried it yet, but this one is on my "ToDo" list of ones to
eventually try:


PDF-XChange Viewer
http://www.tracker-software.com/product/pdf-xchange-viewer

"Those wishing to View/Modify or perform simple
editing and even OCR Image based PDF files on their
Windows PC's now have a FREE pdf reader alternative
to the Adobe Reader!"

"The FREE OCR functionality supports a base language
set of English, French, German & Spanish. Additional
Language Extension Packages are available..."


Maybe you can try it for us and let us know how well/poorly it behaves?
--
"Fish" (David B. Trout)
fish-VLFb7ALKWJGGw+***@public.gmane.org




------------------------------------
Mike Stramba
2013-01-15 12:15:23 UTC
Permalink
Thanks Fish, will check it out

Mike
Post by "Fish" (David B. Trout)
[...]
Post by Mike Stramba
I found a freeware OCR program ...
problem is it only does ONE page at a time
:\
I haven't tried it yet, but this one is on my "ToDo" list of ones to
PDF-XChange Viewer
http://www.tracker-software.com/product/pdf-xchange-viewer
"Those wishing to View/Modify or perform simple
editing and even OCR Image based PDF files on their
Windows PC's now have a FREE pdf reader alternative
to the Adobe Reader!"
"The FREE OCR functionality supports a base language
set of English, French, German & Spanish. Additional
Language Extension Packages are available..."
Maybe you can try it for us and let us know how well/poorly it behaves?
--
"Fish" (David B. Trout)
------------------------------------
http://groups.yahoo.com/group/hercules-390
http://www.hercules-390.org
Yahoo! Groups Links
Mark Salter
2013-01-15 13:19:00 UTC
Permalink
Post by Mike Stramba
PIA that it's not searchable.
Google docs (not everyone's cup of tea and there may be others) provide
a conversion when uploading of pdf's :-

after upload (and conversion) they look the same as the pdf but are also
searchable (only for documents up to 2Mb - unfortunately for this manual).

Their search results for pdf's also provide a 'View as html' which might
do you too (it lacks some formatting) :-

http://tinyurl.com/aa2tmtd
--
Mark
Mark Salter
2013-01-15 13:19:46 UTC
Permalink
Post by Mark Salter
(it lacks some formatting
and has some OCR errors :-(
--
Mark
Juergen
2013-01-14 14:24:06 UTC
Permalink
Post by Juergen
'0123456789ABCDEF'[1-16Tn]
Thanks for that, that gives me a start.
oops, a typo... of course I meant:

'0123456789ABCDEF'[1+16Tn]

Sorry...

Cheers, Juergen
dhdurgee
2013-01-14 17:07:07 UTC
Permalink
Post by Juergen
Post by Juergen
'0123456789ABCDEF'[1-16Tn]
Thanks for that, that gives me a start.
'0123456789ABCDEF'[1+16Tn]
Sorry...
Cheers, Juergen
A minor correction, the "1" above should actually be the &#9014; equivalent of &#9109;IO, as you could be in origin 0 instead of 1 here. Looking at Tony H.'s earlier post, I would think it would be (6&#9014;0) to retrieve the index origin.

Dave
Juergen
2013-01-15 18:29:59 UTC
Permalink
Post by dhdurgee
Post by Juergen
Post by Juergen
'0123456789ABCDEF'[1-16Tn]
Thanks for that, that gives me a start.
'0123456789ABCDEF'[1+16Tn]
Sorry...
Cheers, Juergen
A minor correction, the "1" above should actually be the &#9014;
equivalent of &#9109;IO, as you could be in origin 0 instead of
1 here. Looking at Tony H.'s earlier post, I would think it
would be (6&#9014;0) to retrieve the index origin.
Hi Dave,

you're of course right: If this were a general solution, one would have to make it waterproof as with any other kind of software.

But here we have a quick and dirty implementation of selected parts of the OPFNS workspace to provide certain operational capabilities not given by the set of system commands available. As I've written that "mini OPFNS" personally I'm of course sure that I'm in "index origin 1" mode. I wrote the whole thing relative to index origin 1 because that's the default in APL\360 and I didn't want to irritate newcomers (like Mike ;-) who want to use helper functions like DTH outside the OPFNS environment in their own workspaces...

So just to clarify: "My" OPFNS really is a workaround to provide minimal functionality until the original OPFNS hopefully comes up or at least enough documentation on the original functionality can be found that a more sophisticated implementation can be envisioned. As such "my" OPFNS can be seen as a collection of kludges/glitches whith absolutely no focus on being waterproof. Each function does exactly what it's supposed to do, no user errors are detected (except by APL itself, of course) or prevented.

Given that, I interpreted Mike's question as a novice's, being interested in learning how that stuff is done in that specific implementation and refrained from explaining side considerations like the index origin.

But as you brought it up:

o Besides the OPFNS covering the implementation specific operational aspects, APL\360 came with a workspace named WSFNS covering the implementation specific user functionality.

o At that time the "quad" system variables didn't yet exist. Any behavior defaults defaults are hardcoded in the workspace and I-Beams can be used to change them. WSFNS basically provides a user interface to these I-Beams. As we don't have WSFNS too, one of course can call the I-Beams directly, which may be error prone.

o Phil Roberts is currently working at transferring workspaces from MTS APL to APL\360. Amongst these most probably an at least partly complete WSFNS can be expected to become available.

o I'd generally recommend waiting for this unless one urgently needs to change a default behavior immediately.

The example of the index origin shows how errors can be introduced easily: You correctly mention that 6 I-Beam 0 reports the index origin. But it does so only if you set it at the same time, in which case it reports the old setting. So, to do a simple query of the index origin, without changing it, you have to call 6 I-Beam 0 twice: Once to set it to 0 or 1 (doesn't matter which one) and a second time to restore its previous value.

I'm very sure Mike would have loved me for overloading the one liner just a bit more by executing two 6 I-Beam 0 calls inline instead of just hardcoding the "1+" ;-)

Cheers, Juergen
Tony Harminc
2013-01-15 20:23:45 UTC
Permalink
[...]
Post by Juergen
Post by dhdurgee
A minor correction, the "1" above should actually be the &#9014;
equivalent of &#9109;IO, as you could be in origin 0 instead of
1 here. Looking at Tony H.'s earlier post, I would think it
would be (6&#9014;0) to retrieve the index origin.
[...]
Post by Juergen
The example of the index origin shows how errors can be introduced easily: You correctly mention that 6 I-Beam 0 reports the index origin. But it does so only if you set it at the same time, in which case it reports the old setting. So, to do a simple query of the index origin, without changing it, you have to call 6 I-Beam 0 twice: Once to set it to 0 or 1 (doesn't matter which one) and a second time to restore its previous value.
I'm very sure Mike would have loved me for overloading the one liner just a bit more by executing two 6 I-Beam 0 calls inline instead of just hardcoding the "1+" ;-)
It's easy enough to come up with an APL expression that returns the
value of the index origin, without use of an I-beam - in other words a
test on behaviour rather than stepping outside the language to ask the
system. I think rho iota 1 would do it, but I can't test it right now,
and I'm far from thinking in APL mode these days.

Tony H.
Kevin Leonard
2013-01-15 20:44:17 UTC
Permalink
Post by Tony Harminc
I think rho iota 1 would do it
It does, unless you're a purist: rho iota 1 returns a 1-element
vector, while quad IO returns a scalar.

--
Juergen
2013-01-15 20:46:48 UTC
Permalink
Post by Juergen
[...]
Post by dhdurgee
A minor correction, the "1" above should actually be the &#9014;
equivalent of &#9109;IO, as you could be in origin 0 instead of
1 here. Looking at Tony H.'s earlier post, I would think it
would be (6&#9014;0) to retrieve the index origin.
[...]
The example of the index origin shows how errors can be
introduced easily: You correctly mention that 6 I-Beam 0 reports
the index origin. But it does so only if you set it at the same
time, in which case it reports the old setting. So, to do a simple
query of the index origin, without changing it, you have to call
6 I-Beam 0 twice: Once to set it to 0 or 1 (doesn't matter
which one) and a second time to restore its previous value.
I'm very sure Mike would have loved me for overloading the one
liner just a bit more by executing two 6 I-Beam 0 calls inline
instead of just hardcoding the "1+" ;-)
It's easy enough to come up with an APL expression that
returns the value of the index origin, without use of an
I-beam - in other words a test on behaviour rather than
stepping outside the language to ask the system. I think
rho iota 1 would do it, but I can't test it right now,
and I'm far from thinking in APL mode these days.
Well, Tony, you're right as always! I just wanted to provide an excuse for me programming lazily in quick and dirty mode ;-)

And for not thinking APLish these days your solution is real close: Depending on what is needed either a simple iota 1 would do, or if specifically a scalar is needed, one could use '' rho iota 1, or a bit cleaner (0 rho 0) rho iota 1.

Cheers, Juergen
Juergen
2013-01-15 20:50:19 UTC
Permalink
Post by Kevin Leonard
Post by Tony Harminc
I think rho iota 1 would do it
It does, unless you're a purist: rho iota 1 returns a 1-element
vector, while quad IO returns a scalar.
--
Hi Kevin

see my previous reply: yes, rho iota 1 returns a 1-element vector. And that one element is always one, regardless of quad IO, which is why I wrote that Tony was close ;-)

Cheers, Juergen
dhdurgee
2013-01-15 21:03:07 UTC
Permalink
Post by Kevin Leonard
Post by Tony Harminc
I think rho iota 1 would do it
It does, unless you're a purist: rho iota 1 returns a 1-element
vector, while quad IO returns a scalar.
If you want to be a purist the use (''&#9076;&#9075;1) to obtain the index origin as a scalar. I should have suggested that in the first place, but I was too stuck on &#9109;IO and an &#9014; to replace it. It is also possible that there is a monadic &#9014; to return &#9109;IO and you only need the dyadic version to set it. I don't have a reference to those available and I seem to recall that there were release specific ones as well.

Dave

Loading...