Sometimes you take an old file with numeric-only item ids
and add a few related ids with alphabetic suffixes like
14
551
551A
2800

but still want the legacy digit-only part of ids to line up,as above

A correlative to add that trailing blank for digits-only ids is

f;0;' ';'1';0;0;(L0);'1';[];(MCN);(L0);'0';<;[];:

It does nothing to empty string {""} item ids, and does not reformat
unexpected-format ids like 555-1212 or 123.45 or -42
like the simpler form f;0;p;(mcn);_;(mc/n);' ';:;'1';'1';[];: does.


Remarks 'line' A17 --
***Corr. to append a blank to id if final character is a digit.***
Put A0 on stack then prepare for SECOND substring; 0;' ';'1';
put final byte of A0 on stack <<is FIRST substring>> 0;0;(L0);'1';[];
Strip that one byte string to only digits; (MCN);
Find Length of result; (L0);
Assess result; put '1'{true} on stack if zero is less than it,
put '0'{false} on stack otherwise; '0';<;

Invoke the SECOND substring, relying on ' ';'1'; from very front
That took all,or none,of the one-blank padding text string...; []
Concatenate to the A0 we had put on stack at very beginning ;:
Generic form only loads 0 once at left end then push/swaps clones of 0;
f;0;p;' ';_;'1';_;p;(L0);'1';[];(MCN);(L0);'0';<;[];:
Change (MCN) to (MC/N) to reverse behavior--append blank if NOT a digit

Frank,

I like the idea of formatting the ids to line up pretty, but an F-
correlative? Really? All MV platforms have supported calling basic
from dict items for like, 20 years. Don't you think...

01 sub(ans)
02 * 08-28-11 asb: append trailing space to numeric ids so they line
up pretty
03 if ans eq "" then return
04 if num(ans) then ans := " "
05 return

is simpler and infinitely easier to understand than...

f;0;' ';'1';0;0;(L0);'1';[];(MCN);(L0);'0';<;[];:

?

My rule is "Code for ease of maintenance." Using basic makes it easy
to revisit this a year later and quickly grok what's happening. I like
an elegant F-correlative (actually, that could be an oxymoron) as much
as the next old-school CDPer, but I think their raison d'etre has long
since passed.

/Scott Ballinger
Pareto Corporation
Edmonds WA USA
206 713 6006

On Aug 27, 1:57*am, "Frank Winans" <fwin... (AT) sbcglobal (DOT) net> wrote:

I like having all the stuff in one item; a basic source code, compiled
item, and catalog entry bulks that up to four items. And yes these
are brutal to maintain, hence the overblown 'line' A17.

If the suffixes had been of variable length, I'd have gone with Basic.

This feature was almost generic enough to warrant being in the MD,
instead of just one file's dict -- sadly the id field width is
file-specific.

On Aug 28, 4:24*pm, "Frank Winans" <fwin... (AT) sbcglobal (DOT) net> wrote:
There is probably also a time elapsed issue. The F correlative logic
is built into the dictionary processing routines. The basic
subroutine calls were stapled on at a much later date. I expect the F
correlative's are up to ten times faster.

Of course you'd probably need to sample them against 100,000 records
for it to much any real world difference.

As a semi-related footnote to this, I've always believed that F
correlatives were faster than BASIC, until recently (and I admit the
situation may be "unusual") ...

Imagine a "wildcard" lookup over 300,000 customers that searched for a
strinmg of characters anywhere across 14 fields (street address,
postal address, phone, mobile, email address etc). Following what I
"knew" to be true, I constructed an F-correlative dictionary item, and
fired off a SELECT using this dictionary.

After this had been in production for a few months, the client asked
if we could index the fields (oe SOMETHING) to make the search faster.
Our "solution: ended up being to perform a BASIC select of the file,
doing the same concatenations, and then using an INDEX for the
wildcard matching.

The result was a search routine that was 3 times faster than using an
ACCESS SELECT statement ... who would have figured! The BASIC routine
in question is FLASHED, which I believe is part of the "magic" of this
result

I too have always believed that F-correlatives are fastest.
But in the immortal words of RR: "Trust, but verify."

Test 1:
F-correlative that adds up three numeric attributes vs "call" to
flashed basic program.
Get-list 1M records, sum f-correlative dict item, print elapsed time.
Get-list 1M records, sum basic dict item, print elapsed time.
repeat ad nauseum.

Result: F-correlative twice as fast. (13 sec vs 26 sec)

Test 2:
F-correlative adds up 6 numeric attributes vs flashed basic program.
Get-list 1M records, sum... repeat.

Result: F-correlative 50% faster. (20 sec vs 29 sec)

Test 3:
F-correlative adds up 12 numeric attributes vs flashed basic program.
Get-list 1M records, sum... repeat.

Result: F-correlative and flashed basic "call" are the same. (36 sec)

Test 4:
F-correlative adds up 24 numeric attributes vs flashed basic program.
Get-list 1M records, sum... repeat

Result: F-correlative 50% slower. (61 sec vs 42 sec)

So, I would say simple F-correlatives are faster, but the more tricky
the F-correlative, the less the advantage. And as I was originally
trying to point out, that tricky F-correlative quickly becomes
impossible for me to grok; so, whose time are we saving by using F-
correlatives? I would argue that the programmer is the most expensive
component of the system.

/Scott Ballinger
Pareto Corporation
Edmonds WA USA
206 713 6006

"Scott Ballinger" wrote

In this case speed is not a problem at all; project management
complexity is the problem, if only a small one.

This is a smallish file, well under two megabytes and 10,000 items,
but has survived three or four sets of support programmers over its
decades of existance. It has over 200 dict items, and ten CALLed
programs living in three different program files. It has many Translates
to five other files. It gets light to moderate usage, both in data entry/
retrieval screens and bulk report printouts, with readonly accesses
far outstripping updates.

But it is an example, of sorts; and staff are liable to snatch copies
of dicts or support progs to use in other projects without devoting
overmuch effort to tracking down pesky details like CALLed
program source code for that dict they bulk-copied.
And then I'll get a call at home on the weekend about it...

And just how did you find the documentation borne on attribute 17
lacking, again? It was a mini-essay about a reasonably short attrib 8.

On Aug 29, 9:42*pm, "Frank Winans" <fwin... (AT) sbcglobal (DOT) net> wrote:
The fact that a "reasonably short" F-correlative requires 10 lines of
detailed comments to explain what it's doing is exactly the point.
Kudos to you for providing those comments- we've all seen lots of
"concise" code with no comments whatever.

/Scott

Why not an A-correlative?
Easier to write, and (closer to) self-documenting.

--
frosty

"frosty" wrote
these things out.
{Why yes, I _am_ posting these mini-tools for selfish personal
reasons...}