Hi Charlie, I have not yet implemented user defined dims. But all the "hooks" are there
prs_arg.dmn_in ( contains ALL the dimensions in the input file)
prs_arg.dmn_out ( contains ALL the dimensions in the output file)
we need a way of distinguishing between using the "value" of a dimension and the dimension itself .
e.g If dims are prefixed by a dollar
$lat =10;
$lon=2;
foo_new[$lat,$lon]=1.2f;
It would be nice to define a co-ordinate in a single line e.g
foo_coord[$lat]={1.2,2.3,3.4,4.5}; /* i.e $lat=4 */
We want to be able to use dims on the RHS i.e
average@lat = total@lat / $lat;
Regards Henry
Sorry I have not contributed much this month - My installation of RH 7.2 is causing no end of problems on my Athlon machine.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for the update.
Yes I am very frustrated with RH7.2 as well.
I will switch probably to Debian when I find the time.
The "$" seems like a good symbol for indicating
a dimension (size) rather than value.
Shouldn't your last example be
average@lat = total(lat) / $lat;
Note that I have put in a new file nco_rth_flt.[ch]
which contains float versions of most arithmetic
functions. The idea iis for autotools to test for
the function and if not found use the definition in
nco_rth_flt.[ch]. Currently only Mac OS X uses this,
but it should allow all platforms to have same
ncap functionality, i.e., no architecture-dependent
symbol table manipulation.
Charlie
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Charlie, Its fairly simple for me to implement dynamic dims but we need a way of distinguishing its use on the RHS e.g.
as a dimension
new_avg = min(three_dmn_var_dbl, $lev);
and as a value
$new_lev = 2*$lev;
or
new_avg@test = $lev / $lon *4;
A nice feature I shall be able to implement is returning 1 dimesional attributes from the scanner to the parser as variables .
We also need to sort out a convert function for variables and attributes. I favour defining six keywords for the six types i.e ( byte, char, int. float ,double , short )
I finally sorted out Linux on my PC. I am now using KDE instead of Gnome
Regards Henry
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I do not understand the syntactic problem.
Let me begin with a few definitions that I think you'll
agree with then you point out what's missing/ambiguous and
we'll take it from there.
Let's say the dimension name is lev and there is a variable named
lev with that dimension, so that lev is a coordinate.
Then the two ways we have thought of referring to lev
are
lev
and
$lev
The former should be used when 'lev' is to behave like a normal
variable, i.e., the array of values of the lev variable are inserted
into the expression. The latter is to be used when lev is treated
as a dimension. In other words $lev should translate into the
(scalar) number of elements in the lev dimension. In this system
If $lev=2 and lev=[0,1] then
foo=2*$lev
defines foo=4 and
foo=2*lev
defines foo=[0,2]. Let me know what is incomplete about this system
so I can understand what additional syntax might be needed.
> We also need to sort out a convert function for variables and attributes. I
> favour defining six keywords for the six types i.e ( byte, char, int. float
> ,double , short )
Yes! a user-available convert function would be great! It can be
a wrapper for var_conform_type(). The keywords you have suggested are
fine.
Thanks,
Charlie
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Charlie,
The problem comes when we want to use dimensions on the RHS for ncwa like functions --i.e avg,min,max and ttl ---
I need to be clear in the scanner -- If it is a number then I return a SCV, If it is a dimension then I return a DMN. It may be possible to write an "exclusive start state for a list of dimensions" , but the user is gonna get confused if the syntax is the same.
The following is taken for granted
a) The user cannot redefine dims from the input files.
b) The record dimension remains a record dimension in the output
c) Once a dimension is defined in output , it cannot be redefined
Regards Henry
PS A patch from a CRAY user - I am flattered - It gives me a buzz to think the code written on my humble PC can be used on a cray -- Do you think he could give me a login ??? :-)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
>It may be possible to write an "exclusive start state for a list of
>dimensions" but the user is gonna get confused if the syntax is the
>same.
Since the argument to these functions is expected to be a list
of dimension names, it would be most natural to enter the names
unqualified. I do not think the user will be confused by, e.g.,
I recognize that this will be difficult to parse, but it seems
to me that creating some kind of mechanism for parsing lists of
dimensions is required to do the above anyway. The ability to
pass masks and weights to such a function as average() (so it
can mimic ncwa) opens the question of whether lists of dimensions
should be enclosed in special syntax, e.g.,
>The following is taken for granted
>a) The user cannot redefine dims from the input files.
>b) The record dimension remains a record dimension in the output
>c) Once a dimension is defined in output , it cannot be redefined
Yes, yes, yes!!!
>PS A patch from a CRAY user - I am flattered - It gives me a buzz to think the
>code written on my humble PC can be used on a cray -- Do you think he could
>give me a login ??? :-)
I sent this group a message saying you might be interested in finding
and fixing the problem Crays have with double precision missing values
if they give you an account on their machine. The problem shows up
with nco_tst.sh. They will contact you if they are interested...
Good luck,
Charlie
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Henry,
Did you ever get user-defined dimensions working in ncap?
If so, can you send me an example of how to show it works?
Thanks,
Charlie
Hi Charlie, I have not yet implemented user defined dims. But all the "hooks" are there
prs_arg.dmn_in ( contains ALL the dimensions in the input file)
prs_arg.dmn_out ( contains ALL the dimensions in the output file)
we need a way of distinguishing between using the "value" of a dimension and the dimension itself .
e.g If dims are prefixed by a dollar
$lat =10;
$lon=2;
foo_new[$lat,$lon]=1.2f;
It would be nice to define a co-ordinate in a single line e.g
foo_coord[$lat]={1.2,2.3,3.4,4.5}; /* i.e $lat=4 */
We want to be able to use dims on the RHS i.e
average@lat = total@lat / $lat;
Regards Henry
Sorry I have not contributed much this month - My installation of RH 7.2 is causing no end of problems on my Athlon machine.
Hi Henry,
Thanks for the update.
Yes I am very frustrated with RH7.2 as well.
I will switch probably to Debian when I find the time.
The "$" seems like a good symbol for indicating
a dimension (size) rather than value.
Shouldn't your last example be
average@lat = total(lat) / $lat;
Note that I have put in a new file nco_rth_flt.[ch]
which contains float versions of most arithmetic
functions. The idea iis for autotools to test for
the function and if not found use the definition in
nco_rth_flt.[ch]. Currently only Mac OS X uses this,
but it should allow all platforms to have same
ncap functionality, i.e., no architecture-dependent
symbol table manipulation.
Charlie
Hi Charlie, Its fairly simple for me to implement dynamic dims but we need a way of distinguishing its use on the RHS e.g.
as a dimension
new_avg = min(three_dmn_var_dbl, $lev);
and as a value
$new_lev = 2*$lev;
or
new_avg@test = $lev / $lon *4;
A nice feature I shall be able to implement is returning 1 dimesional attributes from the scanner to the parser as variables .
We also need to sort out a convert function for variables and attributes. I favour defining six keywords for the six types i.e ( byte, char, int. float ,double , short )
I finally sorted out Linux on my PC. I am now using KDE instead of Gnome
Regards Henry
I do not understand the syntactic problem.
Let me begin with a few definitions that I think you'll
agree with then you point out what's missing/ambiguous and
we'll take it from there.
Let's say the dimension name is lev and there is a variable named
lev with that dimension, so that lev is a coordinate.
Then the two ways we have thought of referring to lev
are
lev
and
$lev
The former should be used when 'lev' is to behave like a normal
variable, i.e., the array of values of the lev variable are inserted
into the expression. The latter is to be used when lev is treated
as a dimension. In other words $lev should translate into the
(scalar) number of elements in the lev dimension. In this system
If $lev=2 and lev=[0,1] then
foo=2*$lev
defines foo=4 and
foo=2*lev
defines foo=[0,2]. Let me know what is incomplete about this system
so I can understand what additional syntax might be needed.
> We also need to sort out a convert function for variables and attributes. I
> favour defining six keywords for the six types i.e ( byte, char, int. float
> ,double , short )
Yes! a user-available convert function would be great! It can be
a wrapper for var_conform_type(). The keywords you have suggested are
fine.
Thanks,
Charlie
Hi Charlie,
The problem comes when we want to use dimensions on the RHS for ncwa like functions --i.e avg,min,max and ttl ---
I need to be clear in the scanner -- If it is a number then I return a SCV, If it is a dimension then I return a DMN. It may be possible to write an "exclusive start state for a list of dimensions" , but the user is gonna get confused if the syntax is the same.
The following is taken for granted
a) The user cannot redefine dims from the input files.
b) The record dimension remains a record dimension in the output
c) Once a dimension is defined in output , it cannot be redefined
Regards Henry
PS A patch from a CRAY user - I am flattered - It gives me a buzz to think the code written on my humble PC can be used on a cray -- Do you think he could give me a login ??? :-)
>It may be possible to write an "exclusive start state for a list of
>dimensions" but the user is gonna get confused if the syntax is the
>same.
Since the argument to these functions is expected to be a list
of dimension names, it would be most natural to enter the names
unqualified. I do not think the user will be confused by, e.g.,
two_dmn_var=average(three_dmn_var,lon);
one_dmn_var=average(three_dmn_var,lon,lat);
scl_var=average(three_dmn_var,lon,lat,lev);
I recognize that this will be difficult to parse, but it seems
to me that creating some kind of mechanism for parsing lists of
dimensions is required to do the above anyway. The ability to
pass masks and weights to such a function as average() (so it
can mimic ncwa) opens the question of whether lists of dimensions
should be enclosed in special syntax, e.g.,
dmn_lst=(/lon,lat,lev/);
scl_var=average(three_dmn_var,dmn_lst);
Do you have a specific proposal in mind?
>The following is taken for granted
>a) The user cannot redefine dims from the input files.
>b) The record dimension remains a record dimension in the output
>c) Once a dimension is defined in output , it cannot be redefined
Yes, yes, yes!!!
>PS A patch from a CRAY user - I am flattered - It gives me a buzz to think the
>code written on my humble PC can be used on a cray -- Do you think he could
>give me a login ??? :-)
I sent this group a message saying you might be interested in finding
and fixing the problem Crays have with double precision missing values
if they give you an account on their machine. The problem shows up
with nco_tst.sh. They will contact you if they are interested...
Good luck,
Charlie