This is a slightly different convention from that used in, for example, [nr], which defines to be the smallest number for which .
For example, appendix E of [sunncg] displays `Kahan's summation formula', which allows you to perform a large sum without losing precision in the manner described above.
There used to be an issue here in that all of K&R C's floating-point operations were defined to be done in double-precision -- this made things easy for compiler writers, at the expense of runtime. This is no longer true in ANSI C.
Not impossible. Since someone has already done the hard work of implementing a BASIC interpreter in TeX (honestly!), you'd simply have to port your code to BASIC and let it rip.
Note that, with pipelining, RISC chips can typically support some degree of on-chip parallelization, even for a single CPU.
A statement like that can't be made without some qualification. Depending how you added it up, you could probably make a case that old Fortran dialects probably have more code actually running on CPUs, since many heavily-used libraries were written a long time ago.
There
are two versions of ps
on Suns -- this
example assumes you are using the
/usr/ucb/ps
version.
However, there is no excuse for Bubble Sort!
If you don't get a core file, it might
be that you have your shell set to prevent it -- possibly
as a (reasonable) precaution to avoid filling up filespace
with `useless' core files. The command ulimit
-c
(sh
-type shells only) will show the
maximum size of core file: setting this to zero inhibits
creating core files, and setting it to a very large number
or to unlimited
allows core files to be
created. On csh
-type shells, the
corresponding command is limit coredumpsize
unlimited
A little known
factoid for C enthusiasts: did you know that C's array
reference syntax is commutative, since a[i]
is defined to be equivalent to *(a+i)
and
is thus equal to i[a]
? This means that
a[3]
is the fourth element of the array
a
, and so is 3[a]
! Bizarrely
enough, the latter is a legitimate array reference, but
one you're probably best not including in your own
code.
IDL experts will know that
the common IDL idiom for this is
d=shift(dist(64),32,32)
, but have you ever
actually compared dist
with its
documentation? The documentation for dist
suggests that this idiom wouldn't work, but the function's
actual behaviour seems to (substantially) depart from the
claimed behaviour in exactly the right way.
It's
unfortunate that neither book is much of an advert for TeX's
potentially beautiful typesetting -- both seem to be produced using a
practically unmodified LaTeX book
style.