|
|
|
|
|
|
|
|
|
gauss_gate
|
gauss_gate(times)
gate function used by gaussian_gate. Refer to the source code
to learn how to write your own gate function, making proper use
of drat_start and drat_stop options in addition to the input times.
unknown type function, documented at startup/drat.i line 810
| |
| SEE ALSO: |
gaussian_gate, |
|
|
gauss_int
|
gauss_int(t)
returns time integral of Gaussian specified in call to gaussian_gate.
unknown type function, documented at startup/drat.i line 832
| |
|
gaussian_gate
|
gaussian_gate(t0, tsigma, max_trans)
sets the drat_gate for the snap function to be a Gaussian
centered at time T0, with sigma TSIGMA, and maximum transmission
fraction MAX_TRANS.
unknown type function, documented at startup/drat.i line 855
| |
| SEE ALSO: |
snap, |
|
|
gcd
|
gcd(a,b)
returns the GCD (greatest common divisor) of A and B, which must
be one of the integer data types. A and B may be conformable
arrays; the semantics of the gcd call are the same as any other
binary operation. Uses Euclid's celebrated algorithm.
The absolute values of A and B are taken before the operation
commences; if either A or B is 0, the return value will be 0.
unknown type function, documented at include/gcd.i line 26
| |
| SEE ALSO: |
lcm, |
|
|
get3_centroid
|
get3_centroid(xyz, nxyz)
or get3_centroid(xyz)
return 3D centroids for polygons with vertices XYZ. If NXYZ is
specified, XYZ should be 3-by-sum(nxyz), with NXYZ being the
list of numbers of vertices for each polygon (as for the plfp
function). If NXYZ is not specified, XYZ should be a quadrilateral
mesh, 3-by-ni-by-nj (as for the plf function). In the first case,
the return value is 3-by-numberof(NXYZ); in the second case, the
return value is 3-by-(ni-1)-by-(nj-1).
The centroids are constructed as the mean value of all vertices
of each polygon.
unknown type function, documented at include/pl3d.i line 507
| |
| SEE ALSO: |
get3_normal, |
|
|
get3_light
|
get3_light(xyz, nxyz)
or get3_light(xyz)
return 3D lighting for polygons with vertices XYZ. If NXYZ is
specified, XYZ should be 3-by-sum(nxyz), with NXYZ being the
list of numbers of vertices for each polygon (as for the plfp
function). If NXYZ is not specified, XYZ should be a quadrilateral
mesh, 3-by-ni-by-nj (as for the plf function). In the first case,
the return value is numberof(NXYZ); in the second case, the
return value is (ni-1)-by-(nj-1).
The parameters of the lighting calculation are set by the
light3 function.
unknown type function, documented at include/pl3d.i line 393
| |
| SEE ALSO: |
light3, get3_centroid |
|
|
get3_normal
|
get3_normal(xyz, nxyz)
or get3_normal(xyz)
return 3D normals for polygons with vertices XYZ. If NXYZ is
specified, XYZ should be 3-by-sum(nxyz), with NXYZ being the
list of numbers of vertices for each polygon (as for the plfp
function). If NXYZ is not specified, XYZ should be a quadrilateral
mesh, 3-by-ni-by-nj (as for the plf function). In the first case,
the return value is 3-by-numberof(NXYZ); in the second case, the
return value is 3-by-(ni-1)-by-(nj-1).
The normals are constructed from the cross product of the lines
joining the midpoints of two edges which as nearly quarter the
polygon as possible (the medians for a quadrilateral). No check
is made that these not be parallel; the returned "normal" is
[0,0,0] in that case. Also, if the polygon vertices are not
coplanar, the "normal" has no precisely definable meaning.
unknown type function, documented at include/pl3d.i line 454
| |
| SEE ALSO: |
get3_centroid, |
|
|
get3_xy
|
get3_xy, xyz, x, y
or get3_xy, xyz, x, y, z, 1
Given 3-by-anything coordinates XYZ, return X and Y in viewer's
coordinate system (set by rot3, mov3, orient3, etc.). If the
fifth argument is present and non-zero, also return Z (for use
in sort3d or get3_light, for example). If the camera position
has been set to a finite distance with setz3, the returned
coordinates will be tangents of angles for a perspective
drawing (and Z will be scaled by 1/zc).
unknown type function, documented at include/pl3d.i line 545
| |
| SEE ALSO: |
sort3d, |
|
|
get_addrs
|
addr_lists= get_addrs(file)
returns the byte addresses of the non-record and record variables
in the binary file FILE, and lists of the record addresses, file
indices, and filenames for file families with history records.
*addr_lists(1) absolute addresses of non-record variables
*addr_lists(2) relative addresses of record variables
(add record address to get absolute address)
The order of these two address lists matches the
corresponding lists of names returned by get_vars.
*addr_lists(3) absolute addresses of records
*addr_lists(4) list of file indices corresponding to
addr_lists(3); indices are into addr_lists(5)
*addr_lists(5) list of filenames in the family
unknown type function, documented at startup/std.i line 2250
| |
| SEE ALSO: |
openb, get_vars |
|
|
get_argv
|
get_argv()
returns string array containing the argv from the command line.
The -batch and batch_include.i arguments are removed (not returned).
unknown type function, documented at startup/std.i line 1575
| |
| SEE ALSO: |
process_argv, batch |
|
|
get_cwd
|
get_cwd()
or get_home()
returns the pathname of the current working directory or of your
home directory.
unknown type function, documented at startup/std.i line 1561
| |
| SEE ALSO: |
cd, |
|
|
get_env
|
get_env(environment_variable_name)
returns the environment variable (a string) associated with
ENVIRONMENT_VARIABLE_NAME (calls ANSI getenv routine).
unknown type function, documented at startup/std.i line 1568
| |
| SEE ALSO: |
cd, |
|
|
get_home
|
unknown type function, documented at startup/std.i line 1561 | |
| SEE |
get_cwd |
|
|
get_member
|
get_member(f_or_s, member_name)
returns F_OR_S member MEMBER_NAME, like F_OR_S.MEMBER_NAME syntax,
but MEMBER_NAME can be a computed string. The F_OR_S may be a
binary file or a structure instance.
unknown type function, documented at startup/std.i line 1719
| |
| SEE ALSO: |
openb |
|
|
get_ncycs
|
unknown type function, documented at startup/std.i line 2270 | |
| SEE |
get_times |
|
|
get_ray_path
|
ray_info= get_ray_path(path, rt, zt)
where PATH is one element of an array returned by track_rays,
returns the points where the ray cut the edges of the mesh (ZT, RT).
The returned RAY_INFO has two components: RAY_INFO(,1) is the z
coordinates and RAY_INFO(,2) is the r coordinates.
unknown type function, documented at startup/drat.i line 1272
| |
| 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.
unknown type function, documented at include/rays.i line 239
| |
| SEE ALSO: |
best_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
unknown type function, documented at startup/drat.i line 920
| |
|
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.
unknown type function, documented at include/style.i line 67
| |
| SEE ALSO: |
set_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.
unknown type function, documented at startup/std.i line 2270
| |
| SEE ALSO: |
collect, 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.
unknown type function, documented at startup/std.i line 2233
| |
| SEE ALSO: |
openb, get_addrs |
|
|
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.
unknown type function, documented at include/slice3.i line 755
| |
| SEE ALSO: |
slice3, |
|
|
getdate
|
getdate -- get date of the day in the form "DD/MM/YY"
*
* SYNOPSIS: date= getdate();
* getdate, date;
*
* HISTORY: October 30, 1995 by Eric THIEBAUT.
*
unknown type function, documented at include/string.i line 50
| |
| SEE ALSO: |
gettime, |
|
|
gettime
|
gettime -- get current time in the form "HH:MM:SS"
*
* SYNOPSIS: time= gettime();
* gettime, time;
*
* HISTORY: October 30, 1995 by Eric THIEBAUT.
*
unknown type function, documented at include/string.i line 33
| |
| SEE ALSO: |
getdate, |
|
|
getv3
|
getv3(i, m3, chunk)
return vertex 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 getv3 returns a 2x2x2x(dimsof(CHUNK))
list of vertex coordinates. CHUNK may also be a mesh-specific data
structure used in the slice3 routine, in which case getv3 may
return a (ni)x(nj)x(nk) array of vertex values. For meshes which
are logically rectangular or consist of several rectangular
patches, this is up to 8 times less data, with a concomitant
performance advantage. Use getv3 when writing slicing functions
for slice3.
unknown type function, documented at include/slice3.i line 707
| |
| SEE ALSO: |
slice3, |
|
|
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.
unknown type function, documented at include/pl3d.i line 764
| |
|
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
unknown type function, documented at startup/graph.i line 763
| |
| SEE ALSO: |
window, 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.
unknown type function, documented at startup/std.i line 887
| |
| SEE ALSO: |
_cat, building, |
|
|
grtest
|
grtest
or grtest, nstart
Perform a comprehensive test of Yorick's graphics package.
Pauses after each frame to let you check the result. Each
picture attempts to describe itself (of course, if text
plotting is broken, this doesn't do any good).
With NSTART, start with test number NSTART.
unknown type function, documented at include/testg.i line 258
| |
| SEE ALSO: |
testg, |
|
|
guess_symmetry
|
guess_symmetry, f
or guess_symmetry(f)
guesses the symmetry of the problem in the dump file F based on
the variables f.isymz, f.rt, and f.zt.
If called as a subroutine, prints one of:
"no symmetry", "z=0 reflection symmetry", or "spherical symmetry"
If called as a function, returns 0, 1, or 2, respectively.
unknown type function, documented at startup/drat.i line 949
| |
|
|
|
|
|
|
|
|