iraf.net

Some of the defaults shown in the help files are out of sync with the current default parameters. I've been learning some spectroscopy lately and reading the help pages in the [b:0ca26052c2]onedspec[/b:0ca26052c2] and [b:0ca26052c2]twodspec[/b:0ca26052c2] packages and practicing with the tasks; so these ones have come to my attention.It seems that for these tasks, the default parameters are mostly exactly the same across the handful of other instances of the task in related packages (kpnoslit, ctioslit, etc). So that the help page first found applies to all of them and should be updated. I also pointed out a couple small formatting mistakes but what the heck they are worth fixing too.The following are the parameters that had mismatches along with the respective fix. [b:0ca26052c2]apall[/b:0ca26052c2]
recenter = yes
resize = yes
extras = yes
nsum = 10
nfind = ""
lsigma=4.
usigma=4.
skybox section is out of proper order[b:0ca26052c2]apsum[/b:0ca26052c2]
nsum = 10
lsigma = 4.
usigma = 4.
There is a discrepancy in the files names in the example given. The file "apsum multislit1" should produce "multislit1.ms" by default, not "multspec.ms". Maybe "multispec" is the best name though.[b:0ca26052c2]identify[/b:0ca26052c2]
nsum shouldn't have quotes (not a string)
low_reject = 3.
high_reject = 3.
There's a doubled "the the" (two spaces) in the "Chebyshev Polynomial" and "Legendre Polynomial" sections. And a "the a" (two spaces) in the third bullet of the 1st example.[b:0ca26052c2]reidentify[/b:0ca26052c2]
step, nsum, and shift have unwanted quotes (not strings)
help fails to mention "answer" parameter[b:0ca26052c2]refspectra[/b:0ca26052c2]
verbose = no
help fails to mention "answer" parameterOn a second help topic, I've also noticed that for a large number of the tasks in common to many of these packages, the package help file has different descriptions for exactly exactly the same task. It's probably worth 10 or 15 minutes checking to make sure that every task in onedspec and twodspec has a common description across the board. This is easy to do with "apropos". This would improve IRAF usability for new users. For example, with the reidentify task, an "apropos reidentify" produces:[code:1:0ca26052c2]
reidentify - Automatically identify features in spectra (noao.imred.argus)
reidentify - Reidentify arc lines and determine new dispersion functions (noao.imred.ctioslit)
ecreidentify - Automatically identify features in spectra (noao.imred.echelle)
reidentify - Automatically identify features in spectra (noao.imred.hydra)
reidentify - Automatically identify features in spectra (noao.imred.iids)
reidentify - Automatically identify features in spectra (noao.imred.irs)
reidentify - Reidentify arc lines and determine new dispersion functions (noao.imred.kpnocoude)
reidentify - Reidentify arc lines and determine new dispersion functions (noao.imred.kpnoslit)
reidentify - Automatically reidentify features in spectra (noao.imred.specred)
reidentify - Automatically identify features in spectra (noao.onedspec)
reidentify - Reidentify features (noao.twodspec.longslit)
[/code:1:0ca26052c2]Jason

Hi Jason,Thanks for identifying help problems. I changed some of those. A comment is that in the places where you say quotes should not be used this was done explicitly to support 3D data. Because there is no data type that provides multiple numbers those parameters must be declared as strings in order to be able to enter something like nsum="5 5". The help explicitly shows this to remind the reader that it is a string so that if they accidentally type nsum="foo" you won't get an errror from epar but only when the task tries to parse the string. It is a subtle distinction so you made the logical comment about this.Yours,
Frank

[quote:412eaaface="valdes"]Hi Jason,
Thanks for identifying help problems. I changed some of those. A comment is that in the places where you say quotes should not be used this was done explicitly to support 3D data. Because there is no data type that provides multiple numbers those parameters must be declared as strings in order to be able to enter something like nsum="5 5". The help explicitly shows this to remind the reader that it is a string so that if they accidentally type nsum="foo" you won't get an errror from epar but only when the task tries to parse the string. It is a subtle distinction so you made the logical comment about this.[/quote:412eaaface]That's why you're an IRAF Guru. I still have several tasks of the apextract variety to learn so I may catch more of these. Considering the importance of these tasks it'd worthwhile to have the help as polished as possible.Jason