[Casa-framework] quant (was Re: Added quanta tool to casapy (fwd)) (fwd)

[Raymond Rusk]

Hi Wes, 

I don't think that the following message and some others that I sent 
really made it into the casa-framework list.  They were not posted back to 
me and they are not in the archive.  In fact, I don't see any messages in 
the archive posted by me though I have generated quite a few.  Maybe the 
replies I have received are all from aips2-developers subscribers.

Raymond

PS: I have removed my usual ".signature" component to this message because 
the French part contains a non-US ASCII character.  Maybe that is a 
contributing factor.  It certainly makes my reports in 
aips2-weekly-reports-request hard to read.  I have also posted to 
casa-framework at donar.cv.nrao.edu rather than casa-framework at nrao.edu to 
see whether that makes a difference.

---------- Forwarded message ----------
Date: Fri, 15 Sep 2006 08:59:02 -0700 (PDT)
From: Raymond Rusk <Raymond.Rusk at nrc-cnrc.gc.ca>
To:  <Wim.Brouw at csiro.au>
Cc:  <casa-framework at nrao.edu>
Subject: Re: [Casa-framework] Added quanta tool to casapy

On Fri, 15 Sep 2006, Wim.Brouw at csiro.au wrote:

> The observation that all the string conversion takes place in glish for 
> say '12:09:12.13' or '12km/s2' is incorrect. If a string is input to the 
> 'quantity' method the c++ ('quant') is called to convert it to a 
> quantity. (would have been very expensive to do it all in glish)
> 
> Wim

Hi Wim,

I was meaning to ask someone about the quant method of DOquanta.cc. As it 
is presently implemented, it just accepts an input parameter of type 
Array<QuantumHolder> and returns it.  I can't see how this accomplishes 
anything unless there are side-effects that I don't appreciate.

Raymond

PS:  The code I am referring to is:

// quant
  case 18: {
    Parameter<Array<QuantumHolder> > val(parameters, valName,
                                         ParameterSet::In);
    Parameter<Array<QuantumHolder> > returnval(parameters, returnvalName,
                                               ParameterSet::Out);
    if (runMethod) returnval() = val();
  }
  break;

> > -----Original Message-----
> > From: casa-framework-bounces at donar.cv.nrao.edu 
> > [mailto:casa-framework-bounces at donar.cv.nrao.edu] On Behalf 
> > Of Raymond Rusk
> > Sent: Friday, 15 September 2006 07:04
> > To: Kumar Golap
> > Cc: casa-framework at nrao.edu
> > Subject: Re: [Casa-framework] Added quanta tool to casapy
> > 
> > On Thu, 14 Sep 2006, Kumar Golap wrote:
> > 
> > > An observation  I have
> > > 
> > > Design wise ....right now quanta.quantity is not more useful that 
> > > quantity alone to use...
> > > 
> > > because i need to use a float and a string....e.g so i need 
> > to convert 
> > > myself to a float something i know in hours mins and seconds
> > > 
> > > if you look at the quanta examples in glish
> > > 
> > > http://aips2.aoc.nrao.edu/docs/user/General/node474.html#quanta
> > > 
> > > 
> > > it can interprete  a string and convert it to the right 
> > quatitty and 
> > > units
> > > 
> > > qa.quantity('12h00m00')
> > > 
> > > gets converted to a time quamntity [0.5,''d']
> > > 
> > > qa.quantity('180d00m00')
> > > 
> > > gets converted to an angle quantity [3.142, 'rad')
> > > 
> > > 
> > > etc etc...
> > > 
> > > So will that be possible to implement.
> > 
> > As it is currently implemented, quantities can be expressed 
> > in canonical units using:
> > 	t=qa.canonical(qa.quantity(12.,'h'))
> > 	print qa.tos(t)
> >  and 
> > 	a=qa.canonical(qa.quantity(180.,'deg')).
> > 	print qa.tos(a).
> > 
> > You should also be able to use the convert method to specify 
> > exactly which units that you want.  (Note that I haven't done 
> > much testing yet as I have just gotten this component into casapy.)
> > 
> > I think your real question is whether can you enter the string '12h' 
> > rather than qa.quantity(12.,'h').  The answer is yes, this 
> > can be implemented, but all of our string handling capability 
> > is in the Glish code and will take time to translate to C++.
> > 
> > Also, there is a design choice.  Most of the Glish methods 
> > take a string or a quantity.  If the input parameter is a 
> > string then the Glish code parses it and, when it has the 
> > expected format, converts it to a quantity before passing it 
> > on to the C++ method.
> > 
> > If the C++ methods defined by the IDL need to accept either 
> > strings or quantities then I will need to use a record or 
> > variant to pass parameters.  
> > I am not sure whether that would be better or not.  Every 
> > method would also have the added overhead of dealing with the records.
> > 
> > It might be better to do something on the Python end to 
> > convert strings to quantities in analogy with the glish.  
> > Then the C++ methods don't have the added overhead of string 
> > conversion code if it isn't needed.
> > 
> > Anyway, I nearly certainly will not have time this month to 
> > write the code needed to generate valid quantities from 
> > arbitrary strings since there is considerable work to be done 
> > on the atmosphere component.  Also, rather than using the 
> > existing Glish code as the specification, it would be better 
> > to start from a formal specification of string formats that 
> > should be parsed.
> > 
> > > thanks
> > > 
> > > Kumar
> > > 
> > > 
> > > 
> > > 
> > > 
> > > On 9/14/06, Raymond Rusk <Raymond.Rusk at nrc-cnrc.gc.ca> wrote:
> > > > Hi,
> > > >
> > > > Quit a bit of the quanta tool is functional so I have added it to 
> > > > code/casac/scripts/casapy.py so that it can be exercised.  For my 
> > > > build, I had to run 'gmake componentslib' afterwards to 
> > make it available.
> > > >
> > > > Raymond