Problem reading alternate fits formats for RA and DEC

pnord wrote on Feb 23, 2009

It appears that a number of programs use this format:

OBJCTRA = "12 34 56.7"
OBJCTDEC = "+12 34 56.7"

Whereas IRAF expects:
OBJCTRA = "12:34:56.7"
OBJCTDEC = "+12:34:56.7"

IRAF will fail to correctly read the former without flagging an error.

Is there any reason to not modify the following line in ctod.x to allow both formats?
if (str[ip] == ':' || str[ip] == ' ') { # sexagesimal number?

Thanks,
Paul

---

Mike Fitzpatrick wrote on Feb 23, 2009

Paul,

I'm pretty sure this can be made to work but I'd like a calm moment to see if I can think of a case where something might break. The code change you mention (thanks for that!!) will need to be expanded to allow for more than a single space (e.g. the string "12 3 45.6" where there is no leading zero on the minutes field), but leading/trailing spaces don't seem to be a problem.

Note there is a slight difference in the way sexagesimal is handled by the CL itself and permitting spaces may be a little trickier for the parser, but I'll look into it. Thanks for the suggestion, if you need this right away let me know and I can send you the final code changes and instructions for relinking the system.

Cheers,
-Mike

---

pnord wrote on Feb 23, 2009

Mike,

Ah yes, it would also fail on:
"12 34 56 "
The trailing space would confuse it.

Oddly, I think the original will also read this without complaint:
"12:34:56:78:90:12"

I tried to sketch the state machine and realized that it might take a bit to untangle the spaghetti code in there. This could be done much better with flex/yacc. Sounds like a good project for a summer student.

Thanks,
Paul

fitz


I'm pretty sure this can be made to work but I'd like a calm moment to see if I can think of a case where something might break.

---

Mike Fitzpatrick wrote on Feb 23, 2009

Paul,

For the record, I've put this change in for the next release. The code change to sys$fmtio/ctod.x is as follows (starting at line 89):

    89              if (str[ip] == ':' || str[ip] == ' ') {     # sexagesimal number?
    90                  ip = ip + 1
    91                  dig[j] = EOS
    92                  value = 0.0                             # convert digits
    93                  for (j=1;  dig[j] != EOS;  j=j+1)
    94                      value = value * 10.0D0 + TO_INTEG (dig[j])
    95                  dval = dval + value * scalar * (10.0 ** e)
    96
    97                  while (str[ip] == ' ')                  # allow multiple spaces
    98                      ip = ip + 1

Only lines 89 and 97-98 are new. If you want to update you system following this change, do the following as the 'iraf' user:

% cd /iraf/iraf                     # go to iraf root
% mkpkg <arch>                      # reset architecture
% mkpkg                             # relink system
% cd noao                           # go to NOAO package
% mkpkg -p noao <arch>              # reset arch
% mkpkg -p noao -p tables update

If you have any problems or find a test string that doesn't appear to work please let me know.

Cheers,
-Mike

---

pnord wrote on Feb 23, 2009

Mike,

Thanks! I will give that a try.

Can I ask one more question?
What will the program do if it gets something it does not recognize in that field? I'm thinking of the possibility that someone put in some extraneous text. "12º34'56" or "12h34m56s". I don't think that either of these formats is used. And if someone typed in such a thing by hand they deserve to see it fail. Garbage in -- garbage out. Though, perhaps that is the point. Will they actually see it fail? Or will it, as with the space-delimited format, simply read the first number it sees and return?

Paul

fitz

Paul,

For the record, I've put this change in for the next release. The code change to sys$fmtio/ctod.x is as follows (starting at line 89):

....

Cheers,
-Mike

---

Mike Fitzpatrick wrote on Feb 23, 2009

Good point. I've never seen a file using the degree symbol and single/double quotes are also pretty rare but can be supported. Try the following code change instead:

    89              if (stridx (str[ip], " '\":dDhHmMsS") > 0) {  # sexagesimal number?
    90                  ip = ip + 1
    91                  dig[j] = EOS
    92                  value = 0.0                             # convert digits
    93                  for (j=1;  dig[j] != EOS;  j=j+1)
    94                      value = value * 10.0D0 + TO_INTEG (dig[j])
    95                  dval = dval + value * scalar * (10.0 ** e)
    96
    97                  while (stridx(str[ip]," '\":dDhHmMsS")>0) # multiple spaces
    98                      ip = ip + 1
    99              } else
   100                  break

This would allow hms/dms and quotes instead of just colons and spaces.

-Mike

---

pnord wrote on Feb 23, 2009

Ok, that fixes a few rational cases.
But what happens if I do this:
'12b34m56s'

I think it will read in 12:00:00 and return that without any complaint.

When it hits the "b" is should cry foul and either abort loading the file right then and there, or at least print out an error message in large friendly letters: "What was that? :shock:"

Paul

---

Mike Fitzpatrick wrote on Feb 23, 2009

When it hits the "b" is should cry foul and either abort loading the file right then and there, or at least print out an error message in large friendly letters: "What was that?

I think that's a matter for the higher-level application. The behavior of the task is the same as it was before, i.e. ctod() will attempt to convert a string to a number and return at the first untranslatable character. In your example "12b34m56s" the value will be 12.00 as before, and with the 'ip' pointer left at the untranslated 'b' character.

Note the procedure isn't meant to convert all strings that might logically be convertable, e.g. the string "0x123efc" clearly (to the human eye) represents a number, but ctod() doesn't do a lexical analysis to determine it's a hex value and return the corresponding double. Relaxing the definition of sexagesimal is reasonable given common usage, I'm much more reluctant to modify the task to start suddenly throwing errors it never used to complain about.

-Mike

---

pnord wrote on Feb 23, 2009

Ok, fair enough.

Thanks so much for your careful attention on this one.

Time to find the guy who wrote the routine that calls ctod(). :lol:

Paul

fitz

[quote:b19f5ba706]
I'm much more reluctant to modify the task to start suddenly throwing errors it never used to complain about.

-Mike

---

pnord wrote on Feb 23, 2009

Finally was able to run some real tests on this.

It works just great.

Thanks for your help with the fix, Mike.

Paul

---

Last post on Feb 23, 2009