In 4983992839630034.wa.paulgboulderaim@listserv.ua.edu, on
07/19/2013
at 09:15 AM, Paul Gilmartin paulgboul...@aim.com said:
Mathematical/scientific notation tends to use single-character
identifiers, to be case-sensitive, and to admit characters from
Greek, Hebrew, ...
Also. face and
Some all but random responses.
First,
begin extract
That's all well and good for two character values but obviously
doesn't scale beyond a half-word.
/end extract
The problem I was addressing was a two-character/halfword one, and I
raised it originally to illustrate one egregious way in which
On Fri, 19 Jul 2013 08:19:19 -0400, John Gilmore wrote:
The C language switch statement is defined very specifically and
carefully as an SBCS single-character facility. Not at all
incidentally, this definition ensures that branch tables can always be
used to implement a C switch statement.
FSVO
Let me make a distinction between values known a fortiori, like those
of the keywords or reserved words of a statement-level language and
classes of values defined by initial letter, length in characters, or
the like.
It is correct that IBM REXX treats single-letter identifiers
differently from
On Fri, 19 Jul 2013 09:34:41 -0400, John Gilmore wrote:
Organizing a symbol table/dictionary by identifier length is an old
idea. For example, the Lowry-Medlock FORTRAN H compiler, to which I
have referred here before, kept one-, two-, three-, four-, five- and
six-character identifiers is
I 'favor' the mathematical tradition, but it is still infeasible, in
full, for programming. It is likely that in that long run in which I
shall be dead it will be feasible.
For certain kinds of programming a close, very close, approximation to
mathematical notation is already feasible; and it is
In
CAE1XxDHQXLXdSU=uf=ica2nfkudeytf+rj4shxp3uy_m2rp...@mail.gmail.com,
on 07/18/2013
at 04:13 PM, John Gilmore jwgli...@gmail.com said:
Of course alphabetic is very inefficient. In the Unioted States more
thsan half of the business in many insurance lines is in CA', 'NY',
and 'TX'.
On 19 July 2013 08:19, John Gilmore jwgli...@gmail.com wrote:
Some all but random responses.
[...]
The C language switch statement is defined very specifically and
carefully as an SBCS single-character facility. Not at all
incidentally, this definition ensures that branch tables can always be
COBOL optimization has always been problematic for two reasons.
The less important of them is that, until now at least, some
syntactically interesting features of the language have been
implemented very poorly. Some COBOL EVALUATEs are, for example,
functionally very like a C switch or a PL/I
On Thu, 18 Jul 2013 08:13:02 -0400, John Gilmore wrote:
COBOL optimization has always been problematic for two reasons.
The less important of them is that, until now at least, some
syntactically interesting features of the language have been
implemented very poorly. Some COBOL EVALUATEs are,
On 7/18/2013 6:46 AM, Paul Gilmartin wrote:
On Thu, 18 Jul 2013 08:13:02 -0400, John Gilmore wrote:
COBOL optimization has always been problematic for two reasons.
The less important of them is that, until now at least, some
syntactically interesting features of the language have been
Paul Gilmartin wrote:
begin extract
Which might be the proper implementation if the cases are sparse.
Best to start with the median case value and bisect recursively.
Storage is cheap nowadays, particularly if it's not accessed. But a
large and sparse branch table is an invitation to page
Alphabetic would almost certainly be very inefficient. A minimal
optimization would be a binary search of a table or states, or order
the states in most to least order for the (1. number of transactions,
2. number of policies, 3. number of agents, 4, population).Setting a
subscript once and
Why not a different algorithm, based on the number of possible
alternatives? For instance, if only 2 or 3, then a cascading IF/THEN/ELSE.
If over a thousand, maybe a hash table. Just a thought, I'm sure there are
many possibilities.
On Thu, Jul 18, 2013 at 3:02 PM, Mike Schwab
Of course alphabetic is very inefficient. In the Unioted States more
thsan half of the business in many insurance lines is in CA', 'NY',
and 'TX'. Programmers keep such sets of if-then-elses in
lexicographic sequence to simplify their maintenance. Moreover, they
often continue to do so even
On Thu, 18 Jul 2013 15:09:22 -0400, John Gilmore wrote:
Paul Gilmartin wrote:
begin extract
Which might be the proper implementation if the cases are sparse.
Best to start with the median case value and bisect recursively.
Storage is cheap nowadays, particularly if it's not accessed. But a
I am beginning to have a suspicion that some readers at least do not
know how branch tables. C switch statements, and the like work. Here,
given a state-code of, say, 'NY', its two-byte code point, in EBCDIC
x' d5e8', is used as an offset to address a unique byte in that
table, one of bytes 0,1,
That's all well and good for two character values but obviously doesn't
scale beyond a half-word. If all the keys are already known then a
perfect hash optimized switch statement is one of the most efficient
methods I've seen.
Especially popular with compiler writers for the symbol table.
On
Here IBM have been pushing the 5.1 barrow - even naming numbers.
From the announcement:
With modern advanced optimization and improved exploitation of z hardware,
many well-structured, CPU-intensive batch applications have shown performance
increases greater than 10%
Hmmm - it's that
I wouldn't take well structured too literally here. Or, at least, I think
it's best to consider the compiler developer's definition of well
structured which is at least somewhat different than the application
developer's.
Again, this is fairly easy stuff to measure -- in the statistical sense
20 matches
Mail list logo
