From: sns@deimos.caltech.edu (Sam Southard Jr.)
Subject: Figaro Wildcarding (was Re: this newsgroup outside the US.)
Organization: Caltech Astronomy Department
Date: Thu, 16 Apr 1992 22:44:46 GMT

In article <1992Apr16.204654.1073@chpc.utexas.edu>, aswx266@chpc.utexas.edu (Michael Lemke) writes:
|> In article <1992Apr16.180813.6209@cco.caltech.edu> sns@deimos.caltech.edu (Sam Southard Jr.) writes:
|> Yes, should be able to specify what you want.  But right now you could
|> just not specify OUTPUT and let icmult ask.  For complicated stuff I'd
|> still suggest procedures.  As I said in my first post I really like
|> that it is integrated in the operating system.  Don't put some new 
|> meta-language on top of it.

I agree that it would be bad to invent a new meta-language.  However, doing
what you ask is currently impossible, unless I special-cased the OUTPUT
paramter, and I don't like the sound of that.

|> Not really but just look how the VMS COPY command handels that. 

I'm not sure what you mean by this.  Can you be more specific?

The general problem is that such a modification should be made entirely in the
PAR library, or perhaps in the PAR library plus the main routine.  It should
not be necessary to modify each and every Figaro command to be able to do this.

Given this, how do I know over what parameter I should loop?  IMAGE?  INPUT?
something else?  How do I know what parameter(s) should be prompted for for
each time through the loop (such as an output file)?  How do I know which
parameters should remain constant (such as a constant by which all the images
are going to be multiplied)?

Note that since the PAR library allows you to specify parameters positionally
(you can say 'image testim 1 200 2 200' instead of 'image image=testim
ystart=1 yend=200 xstart=2 xend=200') I can't just say any looping done will be
done over the first specified parameter.

|> This is a typical Unix problem.  I was annoyed by that in VMS as VMS has a 
|> concept of default filespecifications and there is no need to hardcode 
|> such extensions like it is done right now.  Use LIB$FIND_FILE or the 
|> DEFAULTFILE='.DST' in the open statement.  See DCL Concepts manual et 
|> al.

I believe that newer versions of VMS Figaro do in fact use this.

|> In Unix it doesn't work that way but one can still use the primitive
|> approach to first look for the file literally and if it can't be found
|> look again but with the .dst appended.  I think, TeX does it that way.

I will change the libraries to act this way some time.

|> >|> The commands should be more graphic oriented like the IRAF splot for
|> >|> example.  Unless you use the new `figdisp' on a workstation it's a real
|> >|> pain to look through individual rows or columns in an image for
|> >|> example.  The huge sharable images on VMS make image activation very
|> >|> slow.  So a sequence extracting a row and displaying it to `step
|> >|> through' an image takes ages.
|> >
|> >The answer to that is really a non-answer.  The vast majority of figaro sites
|> >are gradually moving to SunOS (with a few going to other types of graphics
|> >workstations, such as DECstations).  This means that Unix and X are going to be
|> >dominant.  Since figdisp is the only supported X interface, saying that it
|> >works everywhere except where you use figdisp is basically saying it works
|> >everywhere.
|> 
|> Go for X, not Unix.  But for many reduction steps you don't need a fancy 
|> display and a simple graphics display does pretty well.  You could even 
|> do it from home via phone.

When I said X & Unix, X was for the fancy display (figdisp has already been
ported to VMS - I just need to update the VMS TVCPKG).  I said Unix because I
don't think much will be done about VMS's slow image activation.

However, it is fairly easy to write your own routines.  If you do this kind of
image examination regularly, why not simply write a routine to do it?  It
sounds like an interactive exam or istat.

Sorry to pass this buck right back to you, but there isn't a lot of support (as
in financial) for Figaro right now.  There isn't anyone anywhere who is paid to
maintain and improve Figaro as a whole (there may be people paid to develop
Figaro applications, but I don't think so).  Any improvements (aside from the
inclusion of routines which other people have written) are done by either
Keith (on the VMS side) or me (on the Unix side) in spare moments we steal from
our real jobs.  Sort of like Usenet, I guess.

|> >|> Btw, for VMS I wrote something that uses the callable FIGARO interface
|> >|> so that everything runs in a background subprocess.  That process is
|> >|> activated only once.  From the user everything looks as before but the
|> >|> commands are executed *much* faster.  But this is interesting only for
|> >|> the VMS version of FIGARO.
|> >
|> >Yes, and the percentage of sites running VMS Figaro is destined to decrease.

However, when you go to callable Figaro you lose one of Figaro's big advantages,
the ease of expansion by J. Random User.

As far as callable Figaro only being interesting for the VMS version, is this
because callable Figaro doesn't currently exist for Unix or because there is
no real reason for callable Unix figaro to exist (since Unix has much smaller
image activation times)?  It'd be very easy for me to make a callable Figaro
for Unix.

|> Unfortunately.  Hope that changes with the ALPHA chip and Open VMS.

We won't go into that here (at least I won't - others may).

|> >|> Why not create a single command to do image arithmetic instead of IADD, 
|> >|> ISUB, IDIV, IMULT, ICADD, ICDIV.....  A general LET would do:
|> >|> 
|> >|> $ MLET result.z.data = (obs.z.data - bias.z.data)/(ff.z.data)
|> >
|> >This seems to be a very good idea.  Would you limit it to +-*/?  If not, what
|> >else should be included.  Anyone care to volunteer to write a simple parser?
|> 
|> As I just indicated to an e-mail to Sam I do have such a thing which I
|> found here in some newsgroup.  It supports all kind of functions like

This is an excellent example of one of the uses I had in mind for this
newsgroup.  I now have the code for MLET and it will be included in the next
Figaro patch release.

I'm sure other people out there have developed routines which may be useful to
others.  Let us know about them.

-- 

Sam Southard, Jr.
{sns@deimos.caltech.edu|{backbone}!cit-vax!deimos!sns}
Newsgroups: alt.sci.astro.figaro