Did I write a good (efficient) program?

"tlmfru" <lacey@mts.net> wrote in message
news:96uIj.44130$QC.26319@newsfe20.lga...
>
> Richard <riplin@azonic.co.nz> wrote in message
> news:ee588146-8f0f-44cf-9674-51a4037ecdf9@s37g2000prg.googlegroups.com...
> On Apr 1, 3:40 pm, Robert <n...@e.mail> wrote: 
> told us to stop. We 
> needs to be 
> 
>
> That's uncalled-for.  Any programmer worth his thinking cap does this sort
> of thing automatically - for instance, making sure that calculations that
> don't beed to be inside a loop are moved outside it; or using a single
> variable to hold the results of a complex calculation rather than
> reiterating the calculation itself ... and so forth.
>

I agree that most of us who have any experience of programming do try and
make things more efficient as we write, often in the ways you note above,
and it is irrespective of whatever language we are using.

But we also need to recognise that modern optimisers can do this job for us
and often do it better than we can.

Today, this isn't as important as it once was.

It is also likely that in any exchange between Robert and Richard there are
going to be statements on both sides that are "uncalled for"... :-)

As long as it isn't mean or vicious, and nobody is blinded to the actual
value of their posts, I see no harm in it...:-)

Part of the normal rough and tumble on Usenet...

Pete.
--
"I used to write COBOL...now I can do anything."

--
"I used to write COBOL...now I can do anything."
"Michael Mattias" <mmattias@talsystems.com> wrote in message
news:57qIj.23163$0o7.2366@newssvr13.news.prodigy.net...
> You know, I've always used three tests to decide if code is well-written:
>
> 1. Does it work?
> 2. Is it *relatively* efficient?
> 3. Is it maintainable?
>

Yep, same priorities I have always observed also...

However, in the light of my experience over the last decade or so, I would
qualify these criteria with: "applies only to Procedural Code."

OO Code has a different set...

1.  Does it work?
2.  Is it small and complete (encapsulated)?
3.  Can I reuse and extend it easily?

Efficiency is taken care of by keeping components small, and using
optimizing compilers.

Maintainability is not a consideration as long as the interface is simple or
non existent. I like to use internal properties (via GETTERs and SETTERs) to
modify behaviour of components, as this avoids needing parameter interfaces,
but it isn't a hard and fast or black and white rule, and it is certainly
arguable... I have found it works and can completely eliminate maintenance.
These days I write stuff, thoroughly debug it, then forget about it. I don't
plan to "maintain" encapsulated functionality, and, so far, I have never had
to. I also don't need to regression test new functionality because it cannot
affect existing functionality, which continues to function as it always has.
OO encapsulation is a form of "ringfencing" for systems.

To modify existing functionality does NOT mean modifying a base class. It
means extending (through inheritance) or over-riding existing behaviours.
Again, only the parts of the system that invoke the modified functionality
need to be tested as the rest of the system is isolated from the changes.

This is, obviously, a different world from COBOL, which was conceived as
being "easily maintainable" in the days when that was important.

> You need a "yes" answer to all three questions to have well-written code.

Yes, but the question set is different between Procedural and Object
Oriented code.
>
> While 'works' is non-negotiable, I'll often often trade 'ultimate
> efficiency'  for maintainability; e.g., "ultimate" efficiency can often be
> best achieved by using lots of GO TOs; but this comes at a maintainability
> cost I am generally not willing to pay.
>
> All done, but need more efficiency?  My rule for optimizing may help:
> First you make it work; only then can you make it work better.

Emphaticaly agreed :-) For both Procedural and OO...

Pete.
--
"I used to write COBOL...now I can do anything."

"Michael Mattias" <mmattias@talsystems.com> wrote in message
news:ZrzIj.36801$J41.3240@newssvr14.news.prodigy.net...
> "Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
> news:65folmF1f605pU1@mid.individual.net... 
>
> Applications programmers (eg, moi) don't think in terms of "components";
> strangely enough, we think in terms of "applications."
>
> I guess that explains as well as anything why it is 'systems' programmers
> are the ones who just couldn't cut it in applications.
>

:-)

I build Applications from components; probably comes from using Meccano with
my Dad when I was a kid (before they invented Lego).

I have tried doing it the way you do, but I like the component based
approach better.

"Chacun a son gout" as the Irish say...

Pete.
--
"I used to write COBOL...now I can do anything."

On Tue, 01 Apr 2008 23:21:29 GMT, "Michael Mattias"
<mmattias@talsystems.com> wrote:

>"Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
>news:65folmF1f605pU1@mid.individual.net... 
>
>Applications programmers (eg, moi) don't think in terms of "components";
>strangely enough, we think in terms of "applications."
>
>I guess that explains as well as anything why it is 'systems' programmers
>are the ones who just couldn't cut it in applications.

I did have one applications programmer tell me that I always was a
systems programmer after he inherited some of my COBOL programs.  On
the other hand, my last three contracts were in applications where I
influenced at least one system and also provided applications
technical support to a Year 2000 project.

Clark Morris
>
>MCM
>
>
>

Frank,
As currently included in WD 1.10, I am very much opposed to it.  The problem
is that the current definition allows the data to be stored within the struc
ture
("DIRECT") and to have such items within ODO's and with data after this.  Wh
at
this means is that the "data" after the variable length field MUST be "moved
" in
storage each time the variable data size changes.

If the proposed definition
- only allowed for "direct" variable length fields at the 01-level,
- allowed for "indirect" variable length items within structures
- figured out how to handle such fields within FILES (or disallowed it there
),
- didn't allow the same variable length field to be BOTH prefixed and suffix
ed

then I would be for it.

--
Bill Klein
wmklein <at> ix.netcom.com
"Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> wrote in message
news:47F232DA.6F0F.0085.0@efirstbank.com... 
> <c463v3p7pdl8dc6dl5seo7j6u0mfrev3qr@4ax.com>, Robert<no@e.mail> wrote: 
>
> Is anyone here a member of this Old Guard that is opposed to variable leng
th
> strings?  I certainly am not.  I would love them.
>
> Frank
>

On Wed, 02 Apr 2008 02:54:19 GMT, "William M. Klein" <wmklein@nospam.netcom.
com> wrote:

>Frank,
>  As currently included in WD 1.10, I am very much opposed to it.  The prob
lem
>is that the current definition allows the data to be stored within the stru
cture
>("DIRECT") and to have such items within ODO's and with data after this.  W
hat
>this means is that the "data" after the variable length field MUST be "move
d" in
>storage each time the variable data size changes.
>
>If the proposed definition
> - only allowed for "direct" variable length fields at the 01-level,
> - allowed for "indirect" variable length items within structures
> - figured out how to handle such fields within FILES (or disallowed it the
re),
> - didn't allow the same variable length field to be BOTH prefixed and suff
ixed
>
>then I would be for it.

18.16.2.3
3) The INDIRECT phrase specifies that the subject of the entry is an indirec
t elementary
data item as defined in 8.5.1.7.2, Location of any-length elementary items. 
If the
INDIRECT phrase is not specified, an any-length elementary item declared at 
the 01 or 77
level or containing the LIMIT phrase is a direct elementary data item;
otherwise, that data item is an indirect elementary data item.

I read that to say a direct data item in the middle of a record (other than 
01/77) must
have a LIMIT. The compiler is expected to allocate LIMIT bytes, similar to O
DO, thus
eliminating the need to move everything following when the length changes.

It does have a "limit" - but it still needs to "move" the following data.  (
Of
course in Standard COBOL there can't be data following an ODO). "for contigu
ity"
of items, see,

"8.5.1.8.1 Contiguity of data items
A variable-length data item may be part of any group structure, and its
neighbors may be non-variable-length data
items or variable-length data items. A variable-length data item is logicall
y
but not necessarily physically
contiguous with its neighbors. However a variable-length data item behaves i
n
all respects as though it were in fact
contiguous with its neighbors whenever a procedural operation is applied to 
a
group containing it."

In other words, no matter how direct items are stored, if you process the "g
roup
item" containing them, it must "appear" as if the following items are direct
ly
after the current length - not after the MAXIMUM length.

--
Bill Klein
wmklein <at> ix.netcom.com
"Robert" <no@e.mail> wrote in message
 news:gh66v3h1ml3rjf9ic3nbgli94sh1j5fr1i@
4ax.com...
> On Wed, 02 Apr 2008 02:54:19 GMT, "William M. Klein"
> <wmklein@nospam.netcom.com> wrote:
> 
>
> 18.16.2.3
> 3) The INDIRECT phrase specifies that the subject of the entry is an indir
ect
> elementary
> data item as defined in 8.5.1.7.2, Location of any-length elementary items
. If
> the
> INDIRECT phrase is not specified, an any-length elementary item declared a
t
> the 01 or 77
> level or containing the LIMIT phrase is a direct elementary data item;
> otherwise, that data item is an indirect elementary data item.
>
> I read that to say a direct data item in the middle of a record (other tha
n
> 01/77) must
> have a LIMIT. The compiler is expected to allocate LIMIT bytes, similar to
> ODO, thus
> eliminating the need to move everything following when the length changes.

On Mar 31, 6:20 pm, "Rick Smith" <ricksm...@mfi.net> wrote:
> "MikeB" <MPBr...@gmail.com> wrote in message
>
> news:408bb0cb-b47e-43b4-b4f0-b604d6c36a3e@p25g2000hsf.googlegroups.com...
> [snip]
> 
> [snip] 
> 
>
> I am not feeling pressured and have a lot of time, so ...
> I rewrote your program adding the compression part
> and wrote a test program to call it. The results are as
> expected.
>
> ----- Results
> 76DF:54AE:A30:1:1:4321:EAD5:AA43
> FD05::1:0:5
> ::1

Rick,
I took about 1 1/2 hours to work through and understand what you
did. I'm stunned. You clearly showed the difference between an amateur
(me) and a professional (you).

Thank you. That was a valuable learning experience for me. I have 1
simple question to see if I understood all of that code correctly.

* Compress adjacent "   0"s, once

move 1 to ip-compress-state
perform
varying ip-index1 from 1 by 4
until ip-index1 > 28
evaluate ip-compress-state
when 1
if ip-octets (ip-index1:4) = "   0"
and ip-octets (ip-index1 + 4:4) = "   0"
then
move spaces to ip-octets (ip-index1:4)
move ":   " to ip-octets (ip-index1 + 4:4)
move 2 to ip-compress-state
else
move 1 to ip-compress-state
end-if
when 2

The
else move 1 to ip-compress state seems redundant, since you
can only ever be in that particular piece of code when the state = 1?

I could not conceive of a logic path that would lead you to excecute
that statement when the state would be other than 1, but perhaps I
missed something?

Once again, thank you. This is really great. And I learned a lot.

Wish I could find a way to apply such stuff as my day-to-day job.

On Wed, 02 Apr 2008 05:41:02 GMT, "William M. Klein" <wmklein@nospam.netcom.
com> wrote:

>It does have a "limit" - but it still needs to "move" the following data.  
(Of
>course in Standard COBOL there can't be data following an ODO). "for contig
uity"
>of items, see,
>
>"8.5.1.8.1 Contiguity of data items
>A variable-length data item may be part of any group structure, and its
>neighbors may be non-variable-length data
>items or variable-length data items. A variable-length data item is logical
ly
>but not necessarily physically
>contiguous with its neighbors. However a variable-length data item behaves 
in
>all respects as though it were in fact
>contiguous with its neighbors whenever a procedural operation is applied to
 a
>group containing it."
>
>In other words, no matter how direct items are stored, if you process the "
group
>item" containing them, it must "appear" as if the following items are direc
tly
>after the current length - not after the MAXIMUM length.

The next paragraph seems to confirm that, when it qualifies any-length with 
indirect. The
implication is that a change to a direct any-length item DOES affect the add
resses of its
neighbors.

"The physical address of a variable-length data item may change during execu
tion of the
program. Dynamic-capacity tables and indirect any-length elementary items, h
owever they
may change during execution, do not in any way affect the addresses of their
 neighbors."

What procedural operations are they referring to? A MOVE and comparison woul
d work if the
maximum length were allocated and following items not shifted. I can think o
f two
situations where it matters. FUNCTION LENGTH says nothing about variable-len
gth groups,
which seems like an error.  Reference modification cannot be used on variabl
e-length
groups.

How can a program tell whether the item following an any-length elementary i
tem is
contiguous? What behavior would be different?

Suppose program A calls B with the address of an indirect any-length item or
variable-length group containing a direct any-length item. B changes the ite
m's size and
address. How does A know the new address? The parameter passed was the addre
ss of the item
or group, not the address of its base pointer. If a Cobol program did pass t
he addess of
the base pointer, which it would almost have to, that would cause problems f
or other
languages, including the OS API.

"MikeB" <MPBrede@gmail.com> wrote in message
news:5bc82b56-8468-4624-9602-4d7085ffe9ff@m73g2000hsh.googlegroups.com...

[snip]

> Thank you. That was a valuable learning experience for me. I have 1
> simple question to see if I understood all of that code correctly.
>
>       * Compress adjacent "   0"s, once
>
>            move 1 to ip-compress-state
>            perform
>            varying ip-index1 from 1 by 4
>            until ip-index1 > 28
>                evaluate ip-compress-state
>                when 1
>                    if ip-octets (ip-index1:4) = "   0"
>                        and ip-octets (ip-index1 + 4:4) = "   0"
>                    then
>                        move spaces to ip-octets (ip-index1:4)
>                        move ":   " to ip-octets (ip-index1 + 4:4)
>                        move 2 to ip-compress-state
>                    else
>                        move 1 to ip-compress-state
>                    end-if
>                when 2
>
> The
>   else move 1 to ip-compress state seems redundant, since you
> can only ever be in that particular piece of code when the state = 1?
>
> I could not conceive of a logic path that would lead you to excecute
> that statement when the state would be other than 1, but perhaps I
> missed something?

It is redundant, but it shows what state will be the next
state. I do the same in the code following 'when 2', which
has 'move 2 to ip-compress-state', after adjusting for an
adjacent compressable field. Perhaps, it is something that
was left over from my days servicing computer equipment
that used ROM-based microprogramming, where next
address fields are never left empty.

> Once again, thank you. This is really great. And I learned a lot.

You're welcome, though I am left with the feeling that
I could have made it more clear as to how it worked or
perhaps had chosen a different way, if I had spent a bit
more time on it. And I apologize for not removing the
comment about formatting in reverse, which no longer
applies.