(48) DATE->NUM, NUM->DATE, ->EXCELDATE, EXCELDATE->, DTDIFF

[Dave Britten]

I find that the 48 series particularly shines when you write a lot of small utility programs to enhance working within the stack paradigm, and keep them in HOME for access anywhere.

With that in mind, here are a handful of programs that convert dates/times to and from numeric values that are compatible with Excel and Lotus 1-2-3; just format the cell values as dates after transferring the data. I use them a lot within other programs that log time-stamped data.

Converting the times to scalar values rather than formatted values (M.DDYYYY, H.MMSS) has the added benefit of making it easier to plot time-based data directly on the 48.

DATE->NUM
Input:
1: Formatted date

Output:
1: Days since December 30, 1899

Code:

\<< 1.0119 SWAP DDAYS 2 + \>>

NUM->DATE
Input:
1: Days since December 30, 1899

Output:
1: Formatted date

Code:

\<< IP 2 - 1.0119 SWAP DATE+ \>>

->EXCELDATE
Input:
2: Formatted date
1: Formatted time

Output:
1: Excel/Lotus-compatible date value (e.g. right now is 41773.5727104)

Code:

\<< HMS\-> 24 / SWAP DATE\->NUM + \>>

EXCELDATE->
Input:
1: Excel/Lotus date value

Output:
2: Formatted date
1: Formatted time

Code:

\<< DUP IP NUM\->DATE SWAP FP 24 * \->HMS \>>

DTDIFF
Not directly related to the above programs, but worth including here. Gives elapsed time between two date/time pairs.

Input (all formatted values):
4: Starting date
3: Starting time
2: Ending date
1: Ending time

Output:
1: Elapsed time in H.MMSS format

Code:

\<< \-> D1 T1 D2 T2
  \<< D1 D2 DDAYS 24
* T2 T1 HMS- HMS+
  \>>
\>>

Some notes:

The programs use date constants that are equivalent regardless of the current date format (flag -42). That's why there's a fudge factor of 2 days, rather than a flag check, two date constants, and IFTE.

Running ->EXCELDATE EXCELDATE-> in sequence will not return the original starting values. Combining the date and time into a single real number will give you a small amount of rounding error, though the time appears to retain about 8 significant digits after the round trip.

[HP67]

(05-14-2014 06:06 PM)Dave Britten Wrote:  I find that the 48 series particularly shines when you write a lot of small utility programs to enhance working within the stack paradigm, and keep them in HOME for access anywhere.

Yeah, that's what FORTH and RPL are all about; building up a vocabulary of words (commands) that you use to solve the problems you want to solve the way you want to solve them. It's one of the big reasons to love RPL even though it's not the easiest language for expressing mathematical solutions in. It's flexible and it promotes good practices like semi-functional programming and factoring commands into bite-sized chunks that do one job.

I really don't like cluttering HOME so I have been using Detlef Mueller's excellent D->LIB 1.0 to create libraries. As you know there are many choices in lib creation tools.

The other thing I found out is that I would have liked a way to create hidden variables from UserRPL. HOME gets awfully full of junk and becomes messy to deal with. How are you managing your HOME directory as you add many commands and variables?

[Dave Britten]

(05-15-2014 11:19 AM)HP67 Wrote:  I really don't like cluttering HOME so I have been using Detlef Mueller's excellent D->LIB 1.0 to create libraries. As you know there are many choices in lib creation tools.

Thanks for the suggestion; I hadn't considered creating libraries yet, but my HOME is starting to get a pretty good amount of stuff in it. I'll check out D->LIB if it gets too unruly.

(05-15-2014 11:19 AM)HP67 Wrote:  The other thing I found out is that I would have liked a way to create hidden variables from UserRPL. HOME gets awfully full of junk and becomes messy to deal with. How are you managing your HOME directory as you add many commands and variables?

Basically, I'm not.

I also have a program called SORTALL that dives into each directory recursively and executes SORTDIR (defined globally in HOME, but some directories provide their own to override sorting). This alphabetizes the vars list, placing all directories first, followed by all programs, then leaves everything else following that unsorted to save execution time. (I'll probably post those programs later today.) In addition, I use local variables wherever possible so they vanish automatically.

Hiding variables is doable, though a little clumsy, and requires a SYSEVAL or a tiny bit of SysRPL. If you have an object with a null-string name (i.e. '') in the current directory, everything sorted after it is not shown in the variables list, or by any command that lists variables (VARS, TVARS, maybe others). They can still be accessed normally by name. A little clever directory sorting lets you hide things this way. I have a directory with user-defined units that hides everything but the 'CST' variable to prompt that they should be used that way, and not directly from the vars menu, lest they be overwritten accidentally with left shift.

I haven't bothered streamlining the hiding process yet, mostly because ORDER doesn't give you a simple way to move things to the end of the list, only the beginning. Perhaps that will give me a project to pass the time today in the hospital.

[HP67]

Thanks for the tips on hidden variables. I'll play around with that later.

I don't use a lot of globals (and seldom use locals either) but I have some astronomical stuff I'm working on and I keep things like position and UTC offset in globals. I just don't like seeing that stuff in the HOME menu so for now it all goes in a SETTINGS directory but then you have to change to that directory if you use the libraries that access them from anywhere else.

[rprosperi]

(05-15-2014 11:19 AM)HP67 Wrote:  The other thing I found out is that I would have liked a way to create hidden variables from UserRPL. HOME gets awfully full of junk and becomes messy to deal with. How are you managing your HOME directory as you add many commands and variables?

Check out HTRIM here: HTRIM

Just what you are looking for to keep the 48 home menus loaded with useful stuff, but neat and tidy.

[HP67]

Thanks, Bob. I know there are a couple of utilities for this but I try to avoid using other people's tools as much as possible. I had to flog myself pretty hard before I used a 3rd party library tool but eventually I will need to bite the bullet and start learning SysRPL and be able to make all my own tools.

[rprosperi]

(05-15-2014 02:05 PM)HP67 Wrote:  Thanks, Bob. I know there are a couple of utilities for this but I try to avoid using other people's tools as much as possible. I had to flog myself pretty hard before I used a 3rd party library tool but eventually I will need to bite the bullet and start learning SysRPL and be able to make all my own tools.

Happy to help. I guess I'm not as independent, and happily use other folks tools if they do what I need. For this requirement, suggest you grab the zip file and read the notes in the docs as the author explains the technique pretty well (which comes from Bill Wickes of all places) used to hide objects in the Home directory. If you can follow the technique (its in SysRPL), you could probably write your own version, or somehow integrate the technique into your own tools/environment. HTH.

[HP67]

Thanks.

[Dave Britten]

(05-16-2014 02:45 AM)rprosperi Wrote:  

(05-15-2014 02:05 PM)HP67 Wrote:  Thanks, Bob. I know there are a couple of utilities for this but I try to avoid using other people's tools as much as possible. I had to flog myself pretty hard before I used a 3rd party library tool but eventually I will need to bite the bullet and start learning SysRPL and be able to make all my own tools.

Happy to help. I guess I'm not as independent, and happily use other folks tools if they do what I need. For this requirement, suggest you grab the zip file and read the notes in the docs as the author explains the technique pretty well (which comes from Bill Wickes of all places) used to hide objects in the Home directory. If you can follow the technique (its in SysRPL), you could probably write your own version, or somehow integrate the technique into your own tools/environment. HTH.

Yeah, the technique is pretty simple really, it's just a bit clumsy to move things around as desired because of the way the ORDER command works.

Basically, you just make sure you have an object with a null (empty) name, and anything that you ORDER after it in the variables list will be hidden, but fully accessible by name as normal.

I think I might play with the D->LIB approach later, though. That way, I can still find the utilities by name in the library menu. If I hide too much stuff, I'm liable to forget what I've got.

WARNING: There's already a hidden directory with a null name in HOME. Do not try to create a new object for this purpose within HOME, just ORDER around the directory that's already in there. Apparently you'll be on your way to a memory loss crash if you blow away the hidden directory by mistake. Also be careful what you do to the objects inside that directory if you get adventurous and start looking around in there. The 48 is supposedly a bit touchy about the user directly changing things in there (don't try to ORDER anything, for example).

As for using custom stuff, I too find it more satisfying to build a tool that does EXACTLY what I want, the way I want it, but be careful about falling into the not-invented-here-syndrome trap. If I need something much more complex, or want a highly optimized/tested SysRPL routine, I'll start rummaging around hpcalc.org (I'm not going to try to build my own version of D->LIB, for instance). For the little tools, yeah, I'd rather bang out something in UserRPL. Much more engaging and customizable that way.

[HP67]

(05-16-2014 10:14 AM)Dave Britten Wrote:  As for using custom stuff, I too find it more satisfying to build a tool that does EXACTLY what I want, the way I want it, but be careful about falling into the not-invented-here-syndrome trap. If I need something much more complex, or want a highly optimized/tested SysRPL routine, I'll start rummaging around hpcalc.org (I'm not going to try to build my own version of D->LIB, for instance). For the little tools, yeah, I'd rather bang out something in UserRPL. Much more engaging and customizable that way.

I admit to suffering from a bad case of NIH but I do have the excuse that I write software tools for a living and we have packaging and delivery concerns that create a very different model than many people are used to today. In almost 40 years I have never used anybody else's tools or middleware on the job and I have not pasted 1 line of anybody else's code in anything I've ever delivered. Just me and the OS.

That does spill over when I work on stuff for my hobbies. But I also like to learn about the device and OS interfaces and avoid 3rd party anything and if that makes me slower to get the user code I want written I usually bite the bullet and do without.

It is certainly not for a lack of appreciation of the talent, skills, etc. of the guys who write tools (since that's part of what I do) but just the way I look at things.

Thanks again, Bob, Dave. You guys are great!