On 1 Mar, 06:41, Jon Kåre Hellan wrote:
John Smith I writes:

Dan Andersson wrote:

...
So if someone sits on the VB code for EZNEC, just rebuild it .Mono on Linux
BUT LINK IT STATICALLY! This means the code will run on almost all varietys
of Linux!
//Dan, M0DFI

My gawd man. Let us hope no serious program is ever written in Visual
Basic!

Oh, I forgot, some idiots did do that, didn't they?

I don't think that was called for.

We may like Linux, but programming just for Windows doesn't make
somebody an idiot.

73 de LA4RT Jon, Trondheim, Norway

The bottom line should be is EZNEC accurate? Has the programming been
held within the confines provided by the original provider'
the U.S. government. Who overseas the content of this so called
program. If it has a patent then all would or should be revealed
in the patent disclosure. Has anybody taken this for his own use for
the advancement of science which is the reason for patents?
Has anybody upgraded the assigned patent for the sake of science
or has something not been disclosed to prevent true examination
and as such invalidates the patent? Does the government have the
option of review of all algorithms or are they in the same position
the country is with voting machines? Basically the purchaser is really
in the position of caveat emptor especially since all programs provide
different results!
Art

art wrote:
The bottom line should be is EZNEC accurate? Has the programming been
held within the confines provided by the original provider'
the U.S. government. Who overseas the content of this so called
program. If it has a patent then all would or should be revealed
in the patent disclosure.

No. A patent must disclose enough of the method so that someone
"versed in the art" of programing could reproduce it. That's pretty
vague. I might be able to look at the patent and reproduce or better
the process easily, while you look at it and scratch your head. Or vice
versa.

Obviously the more complete a patent application is and the simpler it
is to understand, the more likely it is to be granted and the easier it
will be to explain to a jury in an infringment case. It does not
need to be simple or easy to understand and most are not.

Then as you alluded to later in your comments, there is the whole problem
of implementation. Without a lot of effort, a home computer version of
most scientific programs will produce meaningless results due to
lack of precision.

Experienced scientific and engineering programers know this and compensate.
"Teach yourself Visual whatever in a week" programmers don't.

The biggest problem with visual whatever programmers is they tend to
be seduced by the flashy interface and ignore the substance under it.

Caveat Emptor.

Geoff.
--
Geoffrey S. Mendelson, Jerusalem, Israel N3OWJ/4X1GM
IL Voice: (07)-7424-1667 Fax ONLY: 972-2-648-1443 U.S. Voice: 1-215-821-1838
Visit my 'blog at http://geoffstechno.livejournal.com/

(Geoffrey S. Mendelson) wrote in
:

....
Experienced scientific and engineering programers know this and
compensate. "Teach yourself Visual whatever in a week" programmers
don't.

The biggest problem with visual whatever programmers is they tend to
be seduced by the flashy interface and ignore the substance under it.

As an experienced scientific / engineering software developer, I suggest
that much the same issues exist in a conventional 3GL language as in the
"Visual xxx" environment. Good software doesn't just happen, it takes
(aside of the relatively trivial task of writing the functional
elements), huge effort in dealing with exceptions, and testing, testing,
testing.

If you dig deep into the source of Fortran programs, you will often find
the heritage of small memory and slow processors in days gone by, where
implementers used COMMON for variables to reduce memory use, and used
COMMON for passing parameters to avoid the overhead of parameter passing
function calls. This practice was, IMHO, the greatest risk to accuracy in
such programs, and the area that demanded the greatest attention to
design and documentation. The public NEC2 code uses COMMON, and the last
bug that I demonstrated in a C port of the code was related to messed up
parameter passing in COMMON.

So, the old 3GL world wasn't that good anyway!

Owen

On 1 Mar, 23:47, Owen Duffy wrote:
(Geoffrey S. Mendelson) wrote :

...

Experienced scientific and engineering programers know this and
compensate. "Teach yourself Visual whatever in a week" programmers
don't.

The biggest problem with visual whatever programmers is they tend to
be seduced by the flashy interface and ignore the substance under it.

As an experienced scientific / engineering software developer, I suggest
that much the same issues exist in a conventional 3GL language as in the
"Visual xxx" environment. Good software doesn't just happen, it takes
(aside of the relatively trivial task of writing the functional
elements), huge effort in dealing with exceptions, and testing, testing,
testing.

If you dig deep into the source of Fortran programs, you will often find
the heritage of small memory and slow processors in days gone by, where
implementers used COMMON for variables to reduce memory use, and used
COMMON for passing parameters to avoid the overhead of parameter passing
function calls. This practice was, IMHO, the greatest risk to accuracy in
such programs, and the area that demanded the greatest attention to
design and documentation. The public NEC2 code uses COMMON, and the last
bug that I demonstrated in a C port of the code was related to messed up
parameter passing in COMMON.

So, the old 3GL world wasn't that good anyway!

Owen

All very interesting Geoffrey and Owen and really it all adds up that
we need more supervision of programmers when they pupport to be
experts. I have used AO for many many years all with the understanding
that the author had his work hacked that forced him
to give up merchandising the effort. So for many years I used the
program on the basis if I didn't like the answer then ignor the
result. Time has shown that with all these so called antenna programs
all users are doing the same thing.....if you don't like the response
then it is garbage in garbage out and I was as guilty as everybody
else.It was for that reason I put a program test on this newsgroup
such that the results given normally would raise eyebrows. Even asked
Arie to check his but only silence reigned which emphasises that
people are just lazy or choose to remain silent when un unsuitable
answer occurrs.( This also emphasises what a great job W4RLN is doing
for ham radio where he points out where all the programs differ and
who he perceives as correct To me it shows that the human mind really
only believes what he wants to believe
so a program with high gain results is the best seller even tho
inaccurate.
Art

art wrote:

Even asked
Arie to check his but only silence reigned which emphasises that
people are just lazy or choose to remain silent when un unsuitable
answer occurrs.

Aha, could be so. I can't remember or maybe I have banned it from my
memory :-)

But I agree I am also lazy and there are a lot of questions for which
I do not have an answer (yet), but (I hope) I have an open mind and I
am never too old to learn.

( This also emphasises what a great job W4RLN is doing
for ham radio where he points out where all the programs differ and
who he perceives as correct.

I agree completely. Maybe the future will learn that we were fooled by
Nec2/4 and/or other software, but as long as I do not have (or am
willing to spend the funds for) a more accurate method of predicting
behavour or performance I am afraid I will have to stick with it.

To me it shows that the human mind really only believes what he wants to believe
so a program with high gain results is the best seller even tho
inaccurate.

Hmm is it so ?. I don't know. If you ask me, every person does have
it's own motives to decide if he buys or uses one program or the
other, and how much he does trust the results obtained with the
method(s) or underlaying software used by the program.

Arie.

On 6 Mar, 01:54, "4nec2" wrote:
art wrote:
Even asked
Arie to check his but only silence reigned which emphasises that
people are just lazy or choose to remain silent when un unsuitable
answer occurrs.

Aha, could be so. I can't remember or maybe I have banned it from my
memory :-)

But I agree I am also lazy and there are a lot of questions for which
I do not have an answer (yet), but (I hope) I have an open mind and I
am never too old to learn.

( This also emphasises what a great job W4RLN is doing
for ham radio where he points out where all the programs differ and
who he perceives as correct.

I agree completely. Maybe the future will learn that we were fooled by
Nec2/4 and/or other software, but as long as I do not have (or am
willing to spend the funds for) a more accurate method of predicting
behavour or performance I am afraid I will have to stick with it.

To me it shows that the human mind really only believes what he wants to believe
so a program with high gain results is the best seller even tho
inaccurate.

Hmm is it so ?. I don't know. If you ask me, every person does have
it's own motives to decide if he buys or uses one program or the
other, and how much he does trust the results obtained with the
method(s) or underlaying software used by the program.

Arie.

So what does your program provide?
Art

Owen Duffy wrote:
(Geoffrey S. Mendelson) wrote in
:

...
Experienced scientific and engineering programers know this and
compensate. "Teach yourself Visual whatever in a week" programmers
don't.

The biggest problem with visual whatever programmers is they tend to
be seduced by the flashy interface and ignore the substance under it.

As an experienced scientific / engineering software developer, I suggest
that much the same issues exist in a conventional 3GL language as in the
"Visual xxx" environment. Good software doesn't just happen, it takes
(aside of the relatively trivial task of writing the functional
elements), huge effort in dealing with exceptions, and testing, testing,
testing.

If you dig deep into the source of Fortran programs, you will often find
the heritage of small memory and slow processors in days gone by, where
implementers used COMMON for variables to reduce memory use, and used
COMMON for passing parameters to avoid the overhead of parameter passing
function calls. This practice was, IMHO, the greatest risk to accuracy in
such programs, and the area that demanded the greatest attention to
design and documentation. The public NEC2 code uses COMMON, and the last
bug that I demonstrated in a C port of the code was related to messed up
parameter passing in COMMON.

So, the old 3GL world wasn't that good anyway!

Agreed Owen. Perhaps the detractors who don't believe that good
software can be written in VB could give us some concrete examples of
the languages fatal flaws? I've seen nasty stuff in the "good" languages
programs


Programmers may deny it, but they are as vulnerable to "Ford versus
Chevy" type arguments as the best beer swillin', baccy chewin', good ol
boys down at the corner gas station.

- 73 de Mike KB3EIA -

Michael Coslo wrote:

...

Visual Basic being a sucky language, give example?

Krist, VB makes call into all the windows api's, it support com, windows
scripting, and all the other silly stuff windows does.

In other words, IT IS SLOW! And HEAVY on dependence on windows and all
windows flaws ...

It cannot be cross compiled for linux or most other os's without MAJOR
programming efforts.

C/C++ is where it is at ... VB is for babies and web site designers ...
--
http://assemblywizard.tekcities.com

.... and many other things exist to frustrate accurate computing. Long,
long ago when translating antenna modeling (written in FORTRAN) that had
given reasonable results on a 60 bit/word CDC computer to an IBM 32 bit/word
computer, I found the code for one antenna type to be unsalvageable. No
matter what was done with concatenating words together, garbage resulted. A
close look found that the algorithms used were much too sensitive to
significant figures.
I experienced another case where supposedly identical IBM computers
produced different results using the same code.
I echo: work reasonable examples by hand and compare their results to
what the computer produces.

Believable engineering programs earn respect just as people do.

73, Mac N8TT
P.S. My ISP has been having conniptions with their news server, so I have
missed a lot.
--
J. Mc Laughlin; Michigan U.S.A.
Home:

"J. Mc Laughlin" wrote in
:

... and many other things exist to frustrate accurate computing.
Long, long ago when translating antenna modeling (written in FORTRAN)
that had given reasonable results on a 60 bit/word CDC computer to an
IBM 32 bit/word computer, I found the code for one antenna type to be
unsalvageable. No matter what was done with concatenating words
together, garbage resulted. A close look found that the algorithms
used were much too sensitive to significant figures.

Though the 60 bit CDC machines were regarded as the ants pants by
engineers and scientists, the IBM 370 machines (and later) using double
precision were better. The tricky bit was (IIRC) that the representation
of reals on CDC machines used a base of 2 for the exponent, whereas the
IBM format used 2^16, and obviously the two macines allocated a different
number of bits to the mantissa and exponent. It was hard to state the
extent of improvmenet in precision in the IBM format due to the use of
the larger number for the exponent base.

On occasions, this gave rise to different results from programs ported
from on to other. It might have seemed like splitting hairs, but it
showed how close to the wind some of the programs ran in terms of
numerical stability.

I recall in the early days of Excel (V2???) when Microsoft first allowed
user developed add-ins (DLL only, they hadn't thought of VBA), I wrote a
function library for Erlang functions (and some other traffic funcitons).
A chap I was doing some work for asked for a spreadsheet to resemble a
set of printed Erlang tables, and he went through checking them.

When challenged about small differences, I offered "well see, the
engineer who probably developed that set of tables as a major project,
probably used a CDC machine with a mere 60 bit real representation (which
was thought to be the ducks guts in its heyday), but I have used the
Intel 80 bit reals inside the routines, and although Excel only uses 64
bit reals, accumulated rounding errors inside the function library are
reduced (Erlang is an iteritive calculation, but can be optimised to
reduce effects of rounding and overflow)". He was convinced, but I think
somewhat dissapointed to see a low cost desktop computer providing a more
accurate solution than the iconic CDC.

Our mobile phones have probably got more powerful processors now than the
386/SX16 that I used to develop that library!

Owen