Announcement

**Michael Mattias** · 23 Jul 2005, 09:29 AM

>Thoughts?

Not directly on topic, but you asked....

Code:

SUB AP37894 (DTMEORG$, Y2$, GFF%, HT%, L%, LL%) PUBLIC '        CVRTTIME:
37899   Y2$ = DTMEORG$ '                        Set to convert selected time
           IF VAL(Y2$) < 0 OR VAL(Y2$) > 2359 THEN
              GOTO APDCV1 '                     Units per hour
           END IF
           IF LEN(Y2$) < 3 OR LEN(Y2$) > 6 OR INSTR(Y2$, ":") > 0 THEN
              GOTO APDCV1 '                     Is bad
           END IF
           IF LEN(Y2$) > 4 THEN
              GOTO APDCV1 '                     Is bad
           END IF
           IF VAL(Y2$) < 1159 THEN '            Fix it up
              Y2$ = Y2$ + "AM"
           ELSE
              Y2$ = Y2$ + "PM"
           END IF
           ' next test is totally useless becuase above always
           ' makes the last character an upper case M
           IF RIGHT$(Y2$, 1) = "M" OR RIGHT$(Y2$, 1) = "m" THEN
              GOTO APDCV2
           END IF
APDCV1:
         GFF% = 1 '                             Set bad time flag
         EXIT SUB

APDCV2:
     etc..

You know, Mike, in your other post you query about the difference in performance between SELECT CASE and IF..ELSEIF blocks.

If this is typical code you are looking at, you are whistling past the graveyard. The code here is exceptionally redundant and uses the string engine far more than it needs to.

If I haven't missed something here, you are editing a time. The rule is the length of string must be exactly three or four characters, because you test for LEN<3, LEN>6 and LEN>4) and all failed tests "GOTO APDCV1" (which sets GFF% = 1 and EXITs); must not contrain a colon (although I would think it must be numeric, period); the HHMM must be in range ; and if the time passes the edits, a formatted "AM/PM" time is output.

You are testing LEN and VAL of the string multiple times... even when the string will fail a later edit.

I suggest we might try something like:

Code:

  Y2$ = DTMEORG$ '                Set to convert selected time
  LY2% = LEN(Y2$)               ' take length only once so we can do integer compares
      SELECT CASE LY2% 
        CASE 3%, 4%             ' the only valid lengths
           VY2% = VAL (Y2$)     ' only need to test VAL if length is in range, right?
                                ' so take it only once instead of twice
           IF VY2% < 0 OR VY2% > 2359 THEN
              GOTO APDCV1                   ' out of valid range
           END IF
          ' string is now known to be correct length and its VAL is in range
          ' so what could have screwed this up? Perhaps a colon chararter?
           IF INSTR (Y2$, ":") THEN
              GOTO  APDCV1
           END IF
          ' so fix up the string (doing the integer compare instead of taking VAL again)
           IF VY2% < 1159 THEN 
              Y2$ = Y2$ + "AM"
           ELSE
              Y2$ = Y2$ + "PM"
           END IF
           ' --------------------------------------------------------------------
           ' This test from original code is totally useless because above always makes
           ' the last character of Y2$ an upper case "M", so the test is ALWAYS true;
           ' so get rid of it and just GOTO the "passed edits and formatted" label
           ' (this must have been some kind of 'emergency edit' which got left in)      
           ' IF RIGHT$(Y2$, 1) = "M" OR RIGHT$(Y2$, 1) = "m" THEN
           ' --------------------------------------------------------------------
           GOTO APDCV2

       CASE ELSE            ' just exit to error point, invalid length
          GOTO APDCV1

   END SELECT               ' of length

I 'may' have posted here on at least two occasions that worrying about which particular compiler functions you use to test/compare/jump is unlikely to produce as much performance improvement as a careful look at your own code design.

I'm not trying to show you up or anything; I'm just using this as an example of what happens when you modify code many times over the years (no code lives as long as yours has without lots of modifications) and then wonder where your blazing speed went.

MCM

**Mike Luther** · 23 Jul 2005, 12:41 PM

You are totally correct Michael ..

I 'may' have posted here on at least two occasions that worrying
about which particular compiler functions you use to test/compare/jump
is unlikely to produce as much performance improvement as a careful
look at your own code design.

I'm not trying to show you up or anything; I'm just using this as an
example of what happens when you modify code many times over the
years (no code lives as long as yours has without lots of modifications)
and then wonder where your blazing speed went.

And your critique absolutely has to be valid for a lot more of my
code than what I posted above. Sadly. And, no, you are not trying to
show me up or anything. Plus what you posted here, I hope, will help
a lot more folks than me to think carefully about what you have said
not only about this, but in a heck of a lot of other comments you've
made in the forums Michael. You are a major contributor here and have
been, in my eyescape, and the time to do that doesn't come free either.

Thank you.

Not only are you correct, I've got what it takes to document what you
say from the work here to actually show people how right you are and
why what you say is so important.

The above code chunk actually supports what you are saying in your
critique of my work far more than you expected, sigh. The calendar
module was 'taken' from parts of the broadcast station log programming
codework, originally 'extracted' for concept 'can we do this?' as my
current records show, in 1991.

One of my utilities I wrote originally in Basic for my Heathkit Z120
looks for string data in any collection of files for a file name slice
overlay description match in a given file path. I looked for the
following text in this case, "RIGHT$(Y2$,". Admittedly I'm lax in that
from the files here I can't go back prior to 1985 in that we have
operating system issues for the work that was originally done in eight
inch floppies, the Heathkit Z120 and H89 boxes that *ARE* still there
for proof. But this'll show exactly how right you are Michael, grin.

From a WordStar file with the following internal trace date in the
128 bytes from the control header at the top of every WS format
file, grin:

02-15-85

From that 1985 file we find the following code where it was pulled
from the 1976-era broadcast station operations code that started in
BASIC at radio station WTAW in College Station, Texas. Incidentally,
there are very few "W" broadcast stations west of the Mississippi
river in the USA instead of KORA etc. The original Aggieland student
EE Department crew got the call letters from the FCC for "Watch The
Aggies Win". And the their first broadcasts were indeed of football
games here in CS.

I can go back to 286CPU code in CPM if we need to but this'll do
as to show how right you are! From that February 1985 file:

Code:

7920 ' - Select Hour wanted
7930 GOSUB 9440:IF TZ THEN GOSUB 10220
7940 PRINT KK$;:IF TZ THEN GOSUB 10310
7950 LINE INPUT Y2$:IF Y2$="E" OR Y2$="e" THEN 8080
7960 IF INSTR(Y2$,":")>0 OR LEN(Y2$)<5 OR LEN(Y2$)>6 THEN 7930
7970 IF RIGHT$(Y2$,1)="M" OR RIGHT$(Y2$,1)="m" THEN 7980 ELSE 7930
7980 ' - Wk hr
7990 IF LEN(Y2$)=5 AND VAL(LEFT$(Y2$,1))>=0 THEN Y2$="0"+Y2$
8000 Y2$=LEFT$(Y2$,2)+":"+MID$(Y2$,3,4)
8010 HT=VAL(LEFT$(Y2$,2)):IF HT>24 THEN 7920
8020 IF HT<12 AND RIGHT$(Y2$,2)="PM" OR HT<12 AND RIGHT$(Y2$,2)="pm" THEN 8040
8030 GOTO 8050
8040 HT=HT+12:Y2$=RIGHT$(STR$(HT),2)+":00PM"
8050 IF HT=24 THEN MID$(Y2$,6,2)="AM":HT=0:GOTO 8080
8060 IF HT=12 AND RIGHT$(Y2$,2)="AM" OR HT=12 AND RIGHT$(Y2$,2)="am" THEN HT=0
8070 L=INT(VAL(MID$(Y2$,4,2))):LL=L:IF L<1 OR L>60 THEN L=0
8080 GOSUB 9970:RETURN

At another time you made a very important point in working with me
here that one really needs to keep accurate revisions files and old
source information so you can document all the changes. I try. BTW,
one day when I get the time, Will Honea showed me how to re-configure
the OS/2 floppy diskette driver loader parameters so I can actually
tie one of those eight inch floppy or an older 5-1/4" floppy diskette
with the Heathkit DOS format to the current OS/2 operating system!
We could go all the way back to just after CP/M for this quest here if
we want. But thistle dew .. I think, to show the color of the blossom.

Marvelous this OS/2 operating system. Not only do we have USB and all
but we go back all the way to just after CP/M on the same box!

GDRFC!

What this whole thread now shows though is an even more important look
at project techniques, 'wrongs' and 'rights' that most would never
see. We program as people; each of us are different. We each see
our world bounded by our own limitations, which all of us have. As
an MBA in corporate planning from Texas A&M, strongly looking with
eyes that see text data and realizing that all professional management
is really the same, I've sought to containerize that concept.

For over 40 years now.. And I'm getting closer and closer each year.

Yes, the art is in the deal and numbers control it. But it is still
the TEXT and the variable length string data that are the mechanisms of
payment for whatever. As I can see over all this.

And yes, string data. an array of characters if you 'see' it that way,
grin, is best compared and directed through integer math pointers!
A truely competent 'reader' only should read a line once. The step
to representing that text and what it means in the fastest possible
recall of it, can't be efficently applied to the text words to describe
what you view, if you have to read the line over and over again before
you act on that data each time. You may get paid by the text, but
you'd better be able to index it by integer pointers if you ever
want to make a profit.

My problem is the template that encapsulates all this is so huge as
for what I really see. So many vectors; so little time. You have
to simultaneously, in real-time, keep key data from leaking out of
the control template before you have been really hurt by what's been
'wrongly' taken from your pie. And yes you are right again.

You have to periodically review the whole project and try to even
re-design it and completely look at things differently as the
focus on the canvas changes. Yet, Michael, on that special night
when you catch a glimpse of the whole picture, the moon only is
there for maybe ten minutes over the whole horizon .. which has
all the other details in it you must remember?

And it is a hundred years until that precise picture comes back
again for you to see? You won't live that long, so you begin
to work at capturing the beauty. You must.

My problem is precisely as you say. If I were a better reader, I'd
realize in my programming that I'd be better able to point to the
solutions with mathematics, than I now do as I see things. Yes,
the code above shows I have made real progress since 1985 at making
things more maintainable and clear. But there is a long way to go
down this management trail of stary night events, Michael.

Your point is very well taken. You are correct. At the same time
the overview is still massively before me. There is still art in
the deal which I see which has to be on the canvas as a working
calendar module before I can go back and touch up the canvas.

It's like looking at a painting and seeing the real overview, knowing
what might be done, but still not finished with the painting to be
able to handle the details.

I was in the room at a Holiday Inn in Baxter, Iowa, when a young guy
named Charlie McLain, on New Year's Eve in the 60's said, "Folks,
here's a song we're thinking of recording I like to try on you.
See what you think about it," And then, for the first time, in
public, he sang, "Stary stary night ... Amber fields .."

Two years ago, Vincent Van Gough's painting "Stary Night" was on
exhibit at the Houston Museum of Fine Art. You bet I went to see
it. And I GUARANTEE you that you ain't seen what Vincent wanted
you to see until you've looked at the original. For the admission
money they were right in step with technology. You got a personal
hand held. You punched in the integer number of the painting in
this massive exhibit of fine art and a custom audio track talked
to you about the painting at which you were looking.

Yap, yap .. all the technical details about Vincent's trip to the
monastery and so on. As you would expect, there was a large crowd
in front of that painting, including a tour clump of extra-paid-for
folk led by one of the exhibition planners. I wasn't in that group,
just happened to be there then. The guide asked, "Any questions?"

Ny overview broadcasting engineering management personality got the
best of me. I asked him, "If you've gone to all the beautiful work
to put this wonderful modern audio track together for the show,
and this painting, why didn't you background this track with
the music for Stary Stary Night from McClain's Vincent?"

Answer, "Gee, I never thought of that!"

Gee, Michael, you've just done exactly the same thing to me, and
you are so correct. All I can tell you is that it's awfully hard
to see the details on the canvas for the real nuances in the scene,
when you have to go over and over the work 'cuz the hairs fall out
of the brush every time you go to add an impression swipe at the
canvas.

But the brush issue is only another of the same sort of things that
*ALL* of us face when we try to really put out work which is on the
edge of what can be done with the technology resources. That at
the same time economics focus all of us on what we can and cannot
afford to add to our pallet and application tools.

I really do understand why sometimes we have to work with things the
way they are. But realizing that even not knowing if some otherwise
unseen limit in the tools we have, might cure things, if I just knew
it, makes me ask. Even IBM, as big as it is, has a phrase, "Customer
has a workaround." Even they are important.

It takes a lot more than any of us have as individuals. or even big
corporations sometimes. to define what really can be done in any
creative work. And believe me, what you offered is important to me.
I'll try, when I can get the thing working, again, this time, on the
canvas, to see what highlights can be placed on it to make it better.

Thanks again for your time. I guarantee you that the time you have
spent here, along with that of many others, has made my screen
look brighter, handle more data, and move faster than I ever could
have done by myself.

Meanwhile.

Does anyone here have any idea what the statement limit might
be between two consecutive numeric line lables in PB 3.5?

Inquiring mind wants to know.

------------------
Mike Luther
[email protected]iplog.com

**Michael Mattias** · 24 Jul 2005, 01:41 PM

Just a thought... is it possible you are referencing a line number in a different code segment (not a different module, just one line referencing another line with one or more intervening $SEGMENT directives?

I never really thought about it before, and since I never had a problem with it I assume the compliler either picks this up or doesn't care, but as long as the question is from Mars you may as well consider a suggestion from Jupiter.

**Donald Darden** · 26 Jul 2005, 05:17 PM

I noted something in your initial code that I wanted to comment on.
With PowerBasic, there are two ways to identify line lables:

(1) Use a standalong line number, such as 12345, which optionally
can be followed by a colon (

(2) Use a suitable name, similar to a variable name, but follow
it with a colon ( and allow no statement on that line.

In general, there are three techniques for renumbering or renaming
lines in a BASIC source file for use in PowerBasic:

(1) Renumber every line, possibly with an incremental step, such
as 10, or 20, in case you want to add new statements in between,
This assumes that line numbers will be used or assigned in
sequece, from low to high, over the course of the program.

(2) Renumber only referenced lines, such as those that are
targeted with GOTO or GOSUB, and eliminating line numbers that
are not really needed to compile the program. This reduces the
size of the source code, show you where join points occur in
the code from other areas in the program, but reduces the value
of ERL if an error occurs and you are trying to trap for it.

(3) Rename line numbers making them names, such as taking 12345
and renaming it "L12345:", so as to get rid of line numbers in
the old BASIC style (BASICA, GWBASIC, and others). Again, if a
line number is not actually used, it is removed.

Typically, programs that do this for you might be called a
Renumber, Labler, ReLable, or one of the services provided by
a Format, ReFormat, or Convert program.

Another thing that a Format, Reformat, or Convert program might
do would to break up very dense lines where multiple statements
appear separated by colons. This may appear to make the program
much larger, but it also means you now have room to either add
new line numbers for every statement (for more specific trapping)
or you now have space per line for adding more comments to your
source. Neither change will make the resulting compiled program
any arger. And another advantage of a Format, ReFormat, or
Convert program is that it can standardize the source, apply
rules of capitalization, indentation, and other benefits.

I want to make sure that you know that the name "Format" is also
shared by a utility for reformatting disk drives, and we do not
want you formatting disk drives by accident. But it is one of
the names sometimes employed for modifying source code files.

I seem to recall a converter utility called QB2PB, which did a
pretty good job converting QBASIC and QuickBASIC ASCII source
files to PB/DOS. It could also handle GWBASIC and BASICA
source files and convert them over. There were some problems
with graphic statements because QBASIC and QuickBASIC use a
different graphical coordinate system than adopted by PowerBasic.

The thing about PowerBasic is that it can be configured to use
Conventional Memory, Expanded Memory, and Extended Memory, so
that you had far less reason to be concerned with the 640 kb
limits of DOS.

Of course you also have the option to convert over to PB/CC in
place of PB/DOS. PB/CC has evolved quite a bit from the earlier
versions of BASIC, which means a lot more built-in functionality,
but it is not so far from them that it also makes it too hard to
adapt the source code.

Towards this end, lets take a look at another piece of your code:

Code:

7920 ' - Select Hour wanted
7930 GOSUB 9440:IF TZ THEN GOSUB 10220
7940 PRINT KK$;:IF TZ THEN GOSUB 10310
7950 LINE INPUT Y2$:IF Y2$="E" OR Y2$="e" THEN 8080
7960 IF INSTR(Y2$,":")>0 OR LEN(Y2$)<5 OR LEN(Y2$)>6 THEN 7930
7970 IF RIGHT$(Y2$,1)="M" OR RIGHT$(Y2$,1)="m" THEN 7980 ELSE 7930
7980 ' - Wk hr
7990 IF LEN(Y2$)=5 AND VAL(LEFT$(Y2$,1))>=0 THEN Y2$="0"+Y2$
8000 Y2$=LEFT$(Y2$,2)+":"+MID$(Y2$,3,4)
8010 HT=VAL(LEFT$(Y2$,2)):IF HT>24 THEN 7920
8020 IF HT<12 AND RIGHT$(Y2$,2)="PM" OR HT<12 AND RIGHT$(Y2$,2)="pm" THEN 8040
8030 GOTO 8050
8040 HT=HT+12:Y2$=RIGHT$(STR$(HT),2)+":00PM"

How about instead:

Code:

 ' - Select Hour wanted
 7920 GOSUB 9440
 7930 IF TZ THEN GOSUB 10220
      PRINT KK$;
      IF TZ THEN GOSUB 10310
      LINE INPUT Y2$
      IF Y2$="E" OR Y2$="e" THEN 8080
      IF INSTR(Y2$,":")>0 OR LEN(Y2$)<5 OR LEN(Y2$)>6 THEN 7930
      IF RIGHT$(Y2$,1)="M" OR RIGHT$(Y2$,1)="m" THEN
        GOTO 7980
      ELSE
        GOTO 7930
      END IF
7980 ' - Wk hr
      IF LEN(Y2$)=5 AND VAL(LEFT$(Y2$,1))>=0 THEN Y2$="0"+Y2$
      Y2$=LEFT$(Y2$,2)+":"+MID$(Y2$,3,4)
      HT=VAL(LEFT$(Y2$,2)):IF HT>24 THEN 7920
      IF HT<12 AND RIGHT$(Y2$,2)="PM" OR HT<12 AND RIGHT$(Y2$,2)="pm" THEN 8040
      GOTO 8050
8040 HT=HT+12
     Y2$=RIGHT$(STR$(HT),2)+":00PM"
8050

When you do this, you begin to see that the line numbers can be
made into lables, and the lables can have meaning. The GOSUB
and [some implied] GOTO commands can jump to labels that are
named to have some meaning in context, such as AM: and PM:.
Fact is, some GOSUB commands can be replaced with SUBs or
FUNCTIONs that are named for the tasks that they perform.

What you had to do with BASICA, GWBASIC, QBASIC, and QuickBASIC
were what you had to do at the time, but techniques and methods
can be refined over time. With earlier BASICS, you sometimes
could only perform one statement or multiple statements with
colon separators on a single line - there were no multi-line
IF structures with ELSEIF, ELSE, and END IF to help you. And
for structure, you did not have SELECT CASE, CASE, CASE ELSE, and
END SELECT, what you had was ON GOTO or ON GOSUB to contend with.

Things are so much better now that it is worth adapting. As to
adapting your code to use the new functionality, that is your
call. You can usually still use it as originally written, or you
may find value in at least a partial rewrite.

------------------
Old Navy Chief, Systems Engineer, Systems Analyst, now semi-retired

Announcement

Max number of statements 'tween line numbers?

Max number of statements 'tween line numbers?

Comment

Comment

Comment

Comment