> I've been thinking of moving the read in of variables from the parser to the
> scanner. This will make doing hyperslabs easier and also enable us to return
> single valued variables as attributes to the parser- Something we cannot do
> at the moment.
>
> The Rank Problem
> ---------------------
>
> a5 = hyam(lev)*PO;
> a6 = hybm(lev)*PS(time,lat,lon);
> prs_mdp = P0*hyam + hybm*PS;
>
> a5 currently causes var_conform_dim() to crash out. I,m not sure why.
Yes, a 1-D var times a scalar should be the first thing we tackle.
I'm just coming up to speed on how you're parsing statements.
I should be able to be more helpful soon. In particular, it looks
likes like I maybe should write a more generic var_conform_dim
to support some new ncap features.
> I think its asking too much to expect a6 to work , there are no overlapping
> dimensions.
Perhaps we should make a more general var_conform_dim() that automatically expands rank when operands have mutually exclusive
sets of dimensions.
> Variables of the form var(dim1,dim2, dim3... dim n) and var(dim1,dim2,dim3
> .. dim n-1) Should be able to be made to conform.
Agreed, I thought var_conform_dim handled this, perhaps not, I'll have to check.
>
> Final Release
> ---------------
>
> I think when we do the final release of ncap we should include the source
> for the scanner and the parser to avoid compatibility problems with old
> versions flex and bison.
Has this really been a problem?
> Also we need to write a matrix multiplication
> routine -- Its bound to be asked for. I'm prepared to write it but will need
> some help with organizing dimensions as I have only ever handled
> mutliplication of 2D matracies.
Then you know all you need to know! There is no such thing as
matrix multiplication for N-D arrays, N > 2. I agree we should support
element-by-element multiplication ("dot products") of dissimilar
variables (e.g., case a6 above) but we can continue to use "*" for
that type of multiplication without causing ambiguity, right?
I havn't actually thought that last statement through, so check me on this.
> The mathematical functions need some re-thinking. Possibly an array holding
> pointers to the float and double functions
What is the purpose of this? to avoid unnecessary cycles spent doing float computations with double precision functions? or is there something else? just curious.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Charlie, Thanks for doing the code clean up. I'm gonna work on the matrix multiplication. But I think we need to put together a plan of the work that needs doing -- Why don't you give us a ring my numbers (England)(0)1727-759544
Regards Henry
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Henry Butowsky wrote:
> I've been thinking of moving the read in of variables from the parser to the
> scanner. This will make doing hyperslabs easier and also enable us to return
> single valued variables as attributes to the parser- Something we cannot do
> at the moment.
>
> The Rank Problem
> ---------------------
>
> a5 = hyam(lev)*PO;
> a6 = hybm(lev)*PS(time,lat,lon);
> prs_mdp = P0*hyam + hybm*PS;
>
> a5 currently causes var_conform_dim() to crash out. I,m not sure why.
Yes, a 1-D var times a scalar should be the first thing we tackle.
I'm just coming up to speed on how you're parsing statements.
I should be able to be more helpful soon. In particular, it looks
likes like I maybe should write a more generic var_conform_dim
to support some new ncap features.
> I think its asking too much to expect a6 to work , there are no overlapping
> dimensions.
Perhaps we should make a more general var_conform_dim() that automatically expands rank when operands have mutually exclusive
sets of dimensions.
> Variables of the form var(dim1,dim2, dim3... dim n) and var(dim1,dim2,dim3
> .. dim n-1) Should be able to be made to conform.
Agreed, I thought var_conform_dim handled this, perhaps not, I'll have to check.
>
> Final Release
> ---------------
>
> I think when we do the final release of ncap we should include the source
> for the scanner and the parser to avoid compatibility problems with old
> versions flex and bison.
Has this really been a problem?
> Also we need to write a matrix multiplication
> routine -- Its bound to be asked for. I'm prepared to write it but will need
> some help with organizing dimensions as I have only ever handled
> mutliplication of 2D matracies.
Then you know all you need to know! There is no such thing as
matrix multiplication for N-D arrays, N > 2. I agree we should support
element-by-element multiplication ("dot products") of dissimilar
variables (e.g., case a6 above) but we can continue to use "*" for
that type of multiplication without causing ambiguity, right?
I havn't actually thought that last statement through, so check me on this.
> The mathematical functions need some re-thinking. Possibly an array holding
> pointers to the float and double functions
What is the purpose of this? to avoid unnecessary cycles spent doing float computations with double precision functions? or is there something else? just curious.
Hi Charlie, Thanks for doing the code clean up. I'm gonna work on the matrix multiplication. But I think we need to put together a plan of the work that needs doing -- Why don't you give us a ring my numbers (England)(0)1727-759544
Regards Henry