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 00:14:34 GMT

In article <1992Apr15.175923.12608@cco.caltech.edu> sns@deimos.caltech.edu (Sam Southard Jr.) writes:
>I've been talking to people from Australia (for the VMS side of Figaro, which
>is right now far more widespread) who say they've not yet seen this newsgroup.
>I would appreciate it if anyone who is outside the US who can see this
>newsgroup would contact me, either via email or by a post to this group.

I can see it in Texas only on one newsserver.  I suppose it will take a 
while to get around.  Well, I just checked:  It's known now by that 
other server but has no articles.  I also did not get asked there to
subscribe as usual with new groups.

>
>And now an attempt to start some discussion.  Several of the mails I've seen
>have asked for discriptions or comparisons of Figaro to other data processing
>packages.  Since I do not have experience with other packages, I must rely on
>input from astronomers.  Hopefully, this newsgroup will prove to be a
>valuable source for that.  Therefore, I have a few questions to ask.  Please
>post your responses, so we can get a discussion going.
>
>	(1) How does Figaro compare to other packages?  What are its bad
>		points?  How could they be eliminated?  What are its good
>		points?  Be as specific or as general as you like.

Good points:

	It doesn't have its own monitor/environment/OS.  Instead you get
	a bunch of new commands in addition to DELETE, DIRECTORY, PHONE or
	how that's called by your OS.  I like that very much because
	you don't have to learn a new unnessecary environment as with
	IRAF or MIDAS and you don't need escapes to the OS.  You can 
	immediately write procedures and combine FIGARO with your old
	programs.

	Very flexible.  You could easily write applications to 
	analyze stock markets or design spectrographs.  The latter 
	has been done here and I'm currently misusing it to administer
	complex results in a huge structured table (sort of 
	spreadsheet).

	Very open.  You have access to the source of each routine so
	you can really figure out what they are doing.  No black box 
	at all like the other systems.

Bad points:

	The absence of a monitor makes it a little hard to execute 
	commands in a loop for example.  You end up writing command 
	procedures (DCL or Unix) for more or less the same tasks:  Let's
	say you want to subtract the same flat field from ten files or 
	so.  In Unix it's rather simple with `foreach' but in DCL you have
	to write a procedure.  This could be solved if the commands would 
	take wildcards, i.e., in VMS the use of LIB$FIND_FILE would be
	a really good idea.  Or to put it more general:  The commands 
	should take a file specification and not some strange idea of an
	image.

	You also quite often end up writing lots of FORTRAN modifying 
	little things in existing commands.  I also find myself reading 
	the sources quite too frequently just to figure out what they 
	are doing at all.  I'd like to have the help (VMS) not that 
	verbose.  It's nice if you see the system for the first time but
	if you are looking for a command it's pretty bad.  And 
	eventually you just end up in the FORTRAN source comments.

>	(2) In the past a lot of effort has gone into the file structure and
>		the other underlying libraries, possibly at the expense of the
>		applications.  What application areas are the most under-
>		represented?  What types of new routines should be developed?

A routine to measure equivalent widths.  The existing stuff is not very 
useful.  

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.

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.


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)



Even if this looks like a rather long `gripe' I like FIGARO very much.  
Especially that you don't have some silly new environment other than the
computer's OS is nice.  You don't fire up some big thing.  Instead the 
OS's commands become more powerful.


>		One example of this is in data simulation.  A few routines are
>		being developed at Caltech to do this, but they're still very
>		immature.
>
>-- 
>
>Sam Southard, Jr.
>{sns@deimos.caltech.edu|{backbone}!cit-vax!deimos!sns}


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