comp.lang.idl-pvwave archive
Messages from Usenet group comp.lang.idl-pvwave, compiled by Paulo Penteado

Home » Public Forums » archive » scopes
Show: Today's Messages :: Show Polls :: Message Navigator
E-mail to friend 
Switch to threaded view of this topic Create a new topic Submit Reply
scopes [message #85951] Fri, 20 September 2013 14:28 Go to next message
spluque is currently offline  spluque
Messages: 33
Registered: September 2013
Member
Hi,

Using the following script to convert calendar date to day of year (test.pro):

FUNCTION calendar2doy, year, month, day
jd=julday(month, day, year)
caldat, jd, Null, Null, year
doy=string(jd - julday(12, 31, year - 1), format='(i03)')
RETURN, doy
END

PRO TEST
year=2011
mon=10
day=15
DOY=calendar2doy(year, mon, day)
RETURN
END


I expected the variable year in the TEST procedure to remain as defined (the long integer 2011), but this is what I see after calling the call to calendar2doy with a breakpoint at the RETURN line:

IDL> .run "test.pro"
% Compiled module: CALENDAR2DOY.
% Compiled module: TEST.
IDL> breakpoint,'test.pro',14
IDL> test
% Compiled module: JULDAY.
% Compiled module: CALDAT.
% Breakpoint at: TEST 14 test.pro
IDL> print, year
2012

What am I missing?

Cheers,
Seb
Re: scopes [message #85952 is a reply to message #85951] Fri, 20 September 2013 14:44 Go to previous messageGo to next message
David Fanning is currently offline  David Fanning
Messages: 11724
Registered: August 2001
Senior Member
spluque@gmail.com writes:

>
> Hi,
>
> Using the following script to convert calendar date to day of year (test.pro):
>
> FUNCTION calendar2doy, year, month, day
> jd=julday(month, day, year)
> caldat, jd, Null, Null, year
> doy=string(jd - julday(12, 31, year - 1), format='(i03)')
> RETURN, doy
> END
>
> PRO TEST
> year=2011
> mon=10
> day=15
> DOY=calendar2doy(year, mon, day)
> RETURN
> END
>
>
> I expected the variable year in the TEST procedure to remain as defined (the long integer 2011), but this is what I see after calling the call to calendar2doy with a breakpoint at the RETURN line:
>
> IDL> .run "test.pro"
> % Compiled module: CALENDAR2DOY.
> % Compiled module: TEST.
> IDL> breakpoint,'test.pro',14
> IDL> test
> % Compiled module: JULDAY.
> % Compiled module: CALDAT.
> % Breakpoint at: TEST 14 test.pro
> IDL> print, year
> 2012
>
> What am I missing?

Ah, yes, I've seen this before. It's weird. :-)

The problem comes about in the way you are calling CalDat:

caldat, jd, Null, Null, year

You are using the same variable for the day and month. This causes
CalDat great confusion! If you use different variables, you will get
what you expect.

caldat, jd, Null1, Null2, year

It must be something about variables getting updated in a particular
sequence or something. I don't understand exactly what is happening, but
I remember struggling for hours with exactly this thing one time. ;-)

Cheers,

David


--
David Fanning, Ph.D.
Fanning Software Consulting, Inc.
Coyote's Guide to IDL Programming: http://www.idlcoyote.com/
Sepore ma de ni thue. ("Perhaps thou speakest truth.")
Re: scopes [message #85953 is a reply to message #85951] Fri, 20 September 2013 14:52 Go to previous messageGo to next message
spluque is currently offline  spluque
Messages: 33
Registered: September 2013
Member
It looks like those NULL arguments for caldat are causing problems. If I supply some variable (which I don't need at all), then year keeps its value. This is very weird, nonetheless, and it would be good to know what is going on.

Seb
Re: scopes [message #85954 is a reply to message #85952] Fri, 20 September 2013 15:00 Go to previous messageGo to next message
spluque is currently offline  spluque
Messages: 33
Registered: September 2013
Member
Thanks, David, I followed up at about the same time, just after I played supplying some variable names for month and day. It's mildly annoying to have to do this since one may have no use for them, cluttering the environment.

Seb
Re: scopes [message #86158 is a reply to message #85954] Sun, 13 October 2013 20:20 Go to previous messageGo to next message
SonicKenking is currently offline  SonicKenking
Messages: 51
Registered: October 2010
Member
On Saturday, September 21, 2013 8:00:27 AM UTC+10, spl...@gmail.com wrote:
> Thanks, David, I followed up at about the same time, just after I played supplying some variable names for month and day. It's mildly annoying to have to do this since one may have no use for them, cluttering the environment.
>
>
>
> Seb

You can do it with the new !NULL variable if you have IDL 8.0+, like this
caldat, jd, !null, !null, year

Correct result. No dummy variables.
Re: scopes [message #86165 is a reply to message #85951] Tue, 15 October 2013 08:23 Go to previous messageGo to next message
Matthew Argall is currently offline  Matthew Argall
Messages: 286
Registered: October 2011
Senior Member
Variables are passed by reference in IDL. If two output positional parameters reference the same variable name, you are going to have a bad time.

Try this

-----------------------------------
pro test_input_params, a, b
a = 5
b = 4
help, a, b
end

test_input_params, null, null
----------------------------------

It shows that a = a = 4 and that b = a = 4 inside the test program. If I were to later do something with a and b independently, the results would not be independent. I assume that CalDat uses the "month" and "day" parameters when calculating "year", which is why your output is funky.
Re: scopes [message #86166 is a reply to message #86165] Tue, 15 October 2013 08:41 Go to previous message
Matthew Argall is currently offline  Matthew Argall
Messages: 286
Registered: October 2011
Senior Member
I guess a better example would be this:

----------------------------------------
function test_input_params, a, b
a = 5
b = 4
return, a + b
end

IDL> print, test_input_params(null, null)
8
  Switch to threaded view of this topic Create a new topic Submit Reply
Previous Topic: How to speed up KRIG2D by 30x
Next Topic: cgContour and NaN values

-=] Back to Top [=-
[ Syndicate this forum (XML) ] [ RSS ] [ PDF ]

Current Time: Wed Oct 08 11:40:57 PDT 2025

Total time taken to generate the page: 0.00500 seconds