From: aswx266@chpc.utexas.edu (Michael Lemke)
Subject: Re: this newsgroup outside the US.
Organization: The University of Texas System - CHPC
Date: Thu, 16 Apr 92 20:46:54 GMT

In article <1992Apr16.180813.6209@cco.caltech.edu> sns@deimos.caltech.edu (Sam Southard Jr.) writes:
>In article <1992Apr16.001434.27491@chpc.utexas.edu>, aswx266@chpc.utexas.edu (Michael Lemke) writes:

[suugestion to add some sort of file name globbing to FIGARO commands 
deleted]

>
>This would be a good idea.  In fact, I think Figaro 3.0 (available on VMS only
>right now) has such a mechanism for looping through a command multiple times.
>However, for the purposes of discussion, let's assume it doesn't (it may not,
>I've not used it), and figure out exactly how it should work.
>
>What you seem to be saying is that something like:
>
>% image @.dst
>
>should display all images in the current directory.  I use the @ sign so as not
>to interfere with any shell wildcards - if it interferes, users would always
>have to be escaping things, and that gets awkward.
>
>This would be a fairly simple loop, and could be easily implemented now.
>However, what about the case where you have an output file?  For example, an
>obvious extension of the above method would be:
>
>% icmult IMAGE=@.dst OUTPUT=o@.dst
>
>which would multiply all images in the current directory by some number and
>place the output in the file o123.dst (if the original file was 123.dst).
>
>However, do you really want such a restriction?  Shouldn't you be able to call
>the output file anything you like?  

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.

>Perhaps an interface like:
>
>% icmult IMAGE@="123 456 789" OUTPUT@="abc def ghi"
>
>would be better.  Or perhaps something like:
>
>% icmult IMAGE@ 123 456 789 @IMAGE OUTPUT@ abc def ghi @OUTPUT
>
>The second method gets around the problem of specifying multiple strings (for
>plot labels, perhaps), but is a bit wordy.  It would also allow the user to
>use the normal shell wildcards, which is a big plus.
>
>Does anyone have an alternative method?
>

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


>No matter what, if the parameter is supposed to be a file name, it should
>probably have the .dst extension stripped away.  I'm sure just about every
>Figaro user has been annoyed by doing something like 'istat foo.dst' and it
>coming back with "The file foo.dst.dst does not exist".
>

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.

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.

>|> 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.

>
>However, you could also mean that you'd like more interactive, graphically
>oriented, commands.
>

Actually, yes, that was my idea.  And figdisp is a good start.


>|> 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.

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

>
>|> 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
sin, sqrt and even Bessel functions.  It's called XVAL written by
Michael Madden <MECMADDEN@bodkin.ucg.ie>.  I just didn't find the time
to look at it.  And I suppose it needs some modification to be
efficient to operate on whole arrays without reparsing everything from
scratch for each element.


Michael
-- 
Michael Lemke
Astronomy, UT Austin, Texas
(michael@io.as.utexas.edu or UTSPAN::UTADNX::IO::MICHAEL [SPAN])
Newsgroups: alt.sci.astro.figaro