Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!jarthur!bgribble
From: bgribble@jarthur.Claremont.EDU (Bill Gribble)
Newsgroups: comp.sys.handhelds
Subject: Re: Complex units
Message-ID: <11221@jarthur.Claremont.EDU>
Date: 14 Mar 91 19:16:48 GMT
References: <11187@jarthur.Claremont.EDU> <25590125@hpcvra.cv.hp.com.>
Organization: Harvey Mudd College, Claremont, CA 91711
Lines: 30

In article <25590125@hpcvra.cv.hp.com.> billw@hpcvra.cv.hp.com. (William C Wickes) writes:
>There's no conceptual problem with complex numbers with units.  The
>48 doesn't happen to include an object type for such things; call it a
>limitation rather than a quirk (remember ROM is full and life is short?).
>However, you can enter expressions like '(1_m,1_m)', which immediately
>compiles to '1_m+(1_m)*i'.  That opens up lots of possibilities.

When I read this article, I hit 'F' and thought, 'I'm going to get to tell
  Bill Wickes he's wrong, because I've tried this and it doesn't work.'
  Of course, when I went to get my 48 just to confirm your error :-) I
  discovered that it does, in fact, work, with a caveat.

What I had tried was something like '1_m + i*1_m', which doesn't work.  The
  unit objects must be enclosed in parentheses to prevent evaluation of 
  a unit object times i.  

It also seems that this only works if you quote the expression, and only 
  if you explicitly insert the comma rather than leaving a space to separate 
  the elements of the number.  Hmm.  I thought leaving a space was always 
  equivalent to the separator token.  I guess not.

Thanks for the information - it makes complex unit objects at least possible.

>Bill Wickes
>HP Corvallis

*****************************************************************************
**   Bill Gribble                     Harvey Mudd College, Claremont, CA   **
**   bgribble@jarthur.claremont.edu   Never heard of it?  You're stupid.   **
*****************************************************************************