section g of routines in global.i

all functions - g

gammp


    gammp(a, x)  
 or gammp(a, x, q, lg)  


  return P(a,x) = int[0 to x]{ du * u^(a-1)*exp(-u) } / gamma(a)  
  optionally return Q(a,x) = 1-P(a,x) and ln(gamma(a))  
  
  Note that erf(x)=gammp(0.5,x^2) and erfc(x)=gammq(0.5,x^2)  
  Also P(chi2|nu)=gammp(0.5*nu,0.5*chi2)  
   and Q(chi2|nu)=gammq(0.5*nu,0.5*chi2)  
  are the probabilities that an observed chi-square be less than  
  or greater than (P or Q) chi2 when there are nu degrees of freedom  
  (terms in the chi-square sum).  
  
   Interpreted function, defined at i/gammp.i   line 14

SEE ALSO: track_rays

get_s0


    get_s0(rays)  


returns the s-coordinate of the point of closest approach of  
the RAYS to the origin x=y=z=0.  The length of the first dimension  
of RAYS may be either 3, 5, or 6; this first dimension will not  
be present in the result.  
The s-coordinate represents distance along the ray, increasing in  
the direction the ray moves.  The 5 and 6 component ray coordinates  
include a reference point (x,y,z) on the ray; s=0 at that point.  
For the 3 component ray coordinate, get_s0 always returns 0.  
Interpreted function, defined at i/rays.i   line 223

SEE ALSO: best_rays, dirt_rays, internal_rays

get_std_limits


    get_std_limits(rays, slimits)  


returns slimits suitable for internal routines: 2-by-nrays,  
with s=0 at point of closest approach to origin  
Interpreted function, defined at i0/drat.i   line 913

get_style


    get_style, landscape, systems, legends, clegends  


get the detailed style of the current drawing.  The arguments  
are all outputs:  
landscape: 1 if drawing is landscape orientation, 0 if portrait  
system:    an array of GfakeSystem struct instances, one per  
           coordinate system in this drawing (ordinarily just one).  
legends:   a GeLegendBox structure instance describing the layout  
           of the plot legends  
clegends:  a GeLegendBox structure instance describing the layout  
           of the contour legends  
See the help for the GeLegendBox and GpTextAttribs structs for  
the details of the legends and clegends arguments.  Basically,  
you can adjust the location of the legends on the page, the  
font and height of the characters used to render legends, and  
whether the legends are split into two columns.  
The coordinate systems are the systems accessible via the  
plsys command.  The index of the system in the system array is  
the index you use to switch to it in the plsys command.  Simple  
styles have only one coordinate system, and you should carefully  
consider whether you should design a graphic style with multiple  
coordinate systems -- most likely, you can do a better job by  
combining several separate Yorick pictures with some sort of  
page layout program, rather than trying to do this work within  
Yorick itself.  
See the help for the GfakeSystem struct for complete details of  
what you can adjust.  The most interesting features you can  
control are the location and aspect ratio of the viewport, and  
the details of the axis ticks and labels.  The gridxy function  
provides a simpler interface for fiddling with ticks and labels  
if that is all you need.  The system.viewport member is the  
[xmin,xmax,ymin,ymax] of the rectangle on the page where your  
plots will appear, expressed in NDC coordinates (0.0013 NDC units  
equals one point, and there are 72.27 points per inch, and 2.54  
cm per inch; the NDC origin is always at the lower left hand  
corner of the paper, with x increasing leftward and y increasing  
upward).  If you change the size of the viewport, you will also  
need to change the parameters of the tick-generating model; like  
other problems in typography and page layout, this is harder  
than you might think.  
Interpreted function, defined at i/style.i   line 10

SEE ALSO: set_style, read_style, write_style

get_times


    times= get_times(file)  
    ncycs= get_ncycs(file)  


returns the list of time or ncyc values associated with the records  
if FILE, or nil if there are none.  The time values are not guaranteed  
to be precise (but they should be good to at least 6 digits or so);  
the precise time associated with each record may be stored as a record  
variable.  
Builtin function, documented at i0/std.i   line 3304

SEE ALSO: collect, openb, updateb, restore, jt, jc, edit_times

get_vars


    name_lists= get_vars(file)  


returns the lists of non-record and record variable names in the  
binary FILE.  The return value is an array of two pointers to  
arrays of type string; *name_lists(1) is the array of non-record  
variable names (or nil if there are none), *name_lists(2) is the  
array of record variable names.  
The get_addrs function returns corresponding lists of disk  
addresses; the get_member function can be used in conjunction  
with the dimsof, structof, and typeof functions to determine  
the other properties of a variable.  
Builtin function, documented at i0/std.i   line 3252

SEE ALSO: openb, updateb, restore, jt, jc, has_records, get_addrs, set_vars

get_ylm


    get_ylm(pts, lmax, list)  


returns values of Ylm at the 3-by-anything array of unit vectors  
PTS, for all l and m up to LMAX.  The return value is  
(lmax+1)*(lmax+2)/2-by-anything.  The LIST is also returned; its  
value is [1, 2,2, 3,3,3, 4,4,4,4, ..., LMAX+1,LMAX+1,...,LMAX+1]  
-- i copies of each integer i up to LMAX+1.  This can be useful  
in conjunction with the histogram function; its values are l+1  
for each element of the returned array's first index.  The m  
values are [0, 0,1, 0,1,2, 0,1,2,3, 0,1,2,3,4, ...].  Negative m  
values are omitted, since they would be the conjugates of m>0.  
  llist= list-1;  
  mlist= (!list(dif))(cum)-(list-2)*(list-1)/2;  
Interpreted function, defined at i/ylmdec.i   line 34

getc3


    getc3(i, m3, chunk)  
 or getc3(i, m3, clist, l, u, fsl, fsu, cells)  


return cell values of the Ith function attached to 3D mesh M3  
for cells in the specified CHUNK.  The CHUNK may be a list of  
cell indices, in which case getc3 returns a (dimsof(CHUNK))  
list of vertex coordinates.  CHUNK may also be a mesh-specific data  
structure used in the slice3 routine, in which case getc3 may  
return a (ni)x(nj)x(nk) array of vertex values.  There is no  
savings in the amount of data for such a CHUNK, but the gather  
operation is cheaper than a general list of cell indices.  
Use getc3 when writing colorng functions for slice3.  
If CHUNK is a CLIST, the additional arguments L, U, FSL, and FSU  
are vertex index lists which override the CLIST if the Ith attached  
function is defined on mesh vertices.  L and U are index lists into  
the 2x2x2x(dimsof(CLIST)) vertex value array, say vva, and FSL  
and FSU are corresponding interpolation coefficients; the zone  
centered value is computed as a weighted average of involving these  
coefficients.  The CELLS argument is required by histogram to do  
the averaging.  See the source code for details.  
By default, this conversion (if necessary) is done by averaging  
the eight vertex-centered values.  
Interpreted function, defined at i/slice3.i   line 725

SEE ALSO: slice3, mesh3, getc3, xyz3

getv3_rect


    getv3_rect  


  
     Interpreted function, defined at i/slice3.i   line 708

gnomon


    gnomon  
 or gnomon, onoff  


Toggle the gnomon display.  If ONOFF is non-nil and non-zero,  
turn on the gnomon.  If ONOFF is zero, turn off the gnomon.  
The gnomon shows the X, Y, and Z axis directions in the  
object coordinate system.  The directions are labeled.  
The gnomon is always infinitely far behind the object  
(away from the camera).  
There is a mirror-through-the-screen-plane ambiguity in the  
display which is resolved in two ways: (1) The (X,Y,Z)  
coordinate system is right-handed, and (2) If the tip of an  
axis projects into the screen, it's label is drawn in opposite  
polarity to the other text on the screen.  
Interpreted function, defined at i/pl3d.i   line 734

gridxy


    gridxy, flag  
 or gridxy, xflag, yflag  


  Turns on or off grid lines according to FLAG.  In the first form, both  
  the x and y axes are affected.  In the second form, XFLAG and YFLAG  
  may differ to have different grid options for the two axes.  In either  
  case, a FLAG value of 0 means no grid lines (the default), a value of  
  1 means grid lines at all major ticks (the level of ticks which get  
  grid lines can be set in the style sheet), and a FLAG value of 2 means  
  that the coordinate origin only will get a grid line.  In styles with  
  multiple coordinate systems, only the current coordinate system is  
  affected.  
  The keywords can be used to affect the style of the grid lines.  
  You can also turn the ticks off entirely.  (You might want to do this  
  to plot your own custom set of tick marks when the automatic tick  
  generating machinery will never give the ticks you want.  For example  
  a latitude axis in degrees might reasonably be labeled "0, 30, 60,  
  90", but the automatic machinery considers 3 an "ugly" number - only  
  1, 2, and 5 are "pretty" - and cannot make the required scale.  In  
  this case, you can turn off the automatic ticks and labels, and use  
  plsys, pldj, and plt to generate your own.)  
  To fiddle with the tick flags in this general manner, set the  
  0x200 bit of FLAG (or XFLAG or YFLAG), and "or-in" the 0x1ff bits  
  however you wish.  The meaning of the various flags is described  
  in the file Y_SITE/gist/work.gs.  Additionally, you can use the  
  0x400 bit to turn on or off the frame drawn around the viewport.  
  Here are some examples:  
     gridxy,0x233        work.gs default setting  
     gridxy,,0x200       like work.gs, but no y-axis ticks or labels  
     gridxy,,0x231       like work.gs, but no y-axis ticks on right  
     gridxy,0x62b        boxed.gs default setting  
  The three keywords base60=, degrees=, and hhmm= can be used to get  
  alternative tick intervals for base 60 systems instead of the  
  usual base 10 systems.  The keyword values are 0 to restore the  
  default behavior, 1 to set the feature for the x axis, 2 to set it  
  for the y axis, and 3 to set it for both axes.  The base60 feature  
  allows ticks and labels at multiples of 30 (up to +-3600).  The  
  degrees feature causes labels to be printed modulo 360 (so that a  
  scale which runs from, say, 90 to 270 will be printed as 90 to 180  
  then -180 to -90, mostly for longitude scales).  The hhmm feature  
  causes labels to be printed in the form hh:mm (so that, for example,  
  150 will be printed as 02:30, mostly for time of day scales).  
KEYWORDS: color, type, width, base60, degrees, hhmm  
  Builtin function, documented at i0/graph.i   line 857

SEE ALSO: window, plsys, limits, range, logxy, viewport

grow


    grow, x, xnext1, xnext2, ...  
 or grow(x, xnext1, xnext2, ...)  
 or    _(x, xnext1, xnext2, ...)  


lengthens the array X by appending XNEXT1, XNEXT2, etc. to its  
final dimension.  If X is nil, X is first redefined to the first  
non-nil XNEXT, and the remainder of the XNEXT list is processed  
normally.  Each XNEXT is considered to have the same number of  
dimensions as X, by appending unit-length dimensions if necessary.  
All but this final dimension of each XNEXT must be right-conformable  
(that is, conformable in the sense of the right hand side of an  
assignment statement) with all but the final dimension of X.  
The result has a final dimension which is the sum of the final  
dimension of X and all the final dimensions of the XNEXT.  Nil  
XNEXT are ignored.  The value of the result is obtained by  
concatenating all the XNEXT to X, after any required broadcasts.  
If invoked as a function, grow returns the new value of X; in  
this case, X may be an expression.  X must be a simple variable  
reference for the subroutine form of grow; otherwise there is  
nowhere to return the result.  The subroutine form is slightly  
more efficient than the function form for the common usage:  
     x= grow(x, xnext1, xnext2)           is the same as  
     grow, x, xnext1, xnext2              the preferred form  
The _ function is a synonym for grow, for people who want this  
operator to look like punctuation in their source code, on analogy  
with the array building operator [a, b, c, ...].  
The _cat function is sometimes more appropriate than grow.  
Usage note:  
Never do this:  
  while (more_data) grow, result, datum;  
The time to complete this loop scales as the SQUARE of the number  
of passes!  Instead, do this:  
  for (i=1,result=array(things,n_init) ; more_data ; i++) {  
    if (i>numberof(result)) grow, result, result;  
    result(i) = datum;  
  }  
  result = result(1:i-1);  
The time to complete this loop scales as n*log(n), because the  
grow operation doubles the length of the result each time.  
Builtin function, documented at i0/std.i   line 1036