I'm trying to get Eznec ver 2 to run on a WinXP machine, but I keep getting
an Error 137, insufficent memory. Does anyone have a suggestion on what I
need to set, or fix?

Any help would be appreciated. Please post to the news group, as this
address doesn't have a mailbox associated with it to avoid spam.

Robert
N3LGC

SignalFerret wrote:
I'm trying to get Eznec ver 2 to run on a WinXP machine, but I keep getting
an Error 137, insufficent memory. Does anyone have a suggestion on what I
need to set, or fix?

I vaguely remember the firewall/virus-protection needs to
be disabled during installation. I'm sure Roy will respond.
--
73, Cecil, W5DXP

----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

I could be wrong, and Roy will correct me if I am, but EZNEC seems to be
written in Visual Basic, or similar... might you need the run-time libraries
for an older edition?
And, he (Roy) mentions "double percision"--a nasty reality of basic (and
some Fortran compilers also), which seems to confirm my suspicions...

Regards,
John

"SignalFerret" wrote in message
news:JoW9e.26259$jd6.8685@trnddc07...
I'm trying to get Eznec ver 2 to run on a WinXP machine, but I keep
getting an Error 137, insufficent memory. Does anyone have a suggestion
on what I need to set, or fix?

Any help would be appreciated. Please post to the news group, as this
address doesn't have a mailbox associated with it to avoid spam.

Robert
N3LGC

precision even!!! before all the spelling freaks fall on me!

John

"John Smith" wrote in message
...
I could be wrong, and Roy will correct me if I am, but EZNEC seems to be
written in Visual Basic, or similar... might you need the run-time
libraries for an older edition?
And, he (Roy) mentions "double percision"--a nasty reality of basic (and
some Fortran compilers also), which seems to confirm my suspicions...

Regards,
John

"SignalFerret" wrote in message
news:JoW9e.26259$jd6.8685@trnddc07...
I'm trying to get Eznec ver 2 to run on a WinXP machine, but I keep
getting an Error 137, insufficent memory. Does anyone have a suggestion
on what I need to set, or fix?

Any help would be appreciated. Please post to the news group, as this
address doesn't have a mailbox associated with it to avoid spam.

Robert
N3LGC

John Smith wrote:
I could be wrong, and Roy will correct me if I am, but EZNEC seems to be
written in Visual Basic, or similar... might you need the run-time libraries
for an older edition?

No, that's not the problem -- it's due to DOS not being able to properly
determine the size of a large amount of RAM. And the DOS versions were
written with the MS BASIC Professional Development System, not Visual
Basic. Windows versions of EZNEC (v. 3.0 and 4.0) are written in Visual
Basic, except the calculating engines and a few speed-critical main
program routines which are written in Fortran.

And, he (Roy) mentions "double percision"--a nasty reality of basic (and
some Fortran compilers also), which seems to confirm my suspicions...

Double precision isn't a "nasty reality" -- it's simply a way of storing
floating point variables. Normal precision floating point variables are
stored in four byte words, and consequently have a resolution of about
seven significant decimal digits. Double precision variables require 8
bytes and have about 15 significant digits of resolution. Fortran
additionally has a complex data type which requires twice as much
storage space, since each variable of that type has two parts. Some
compilers have additional, higher precisions available. The program
author can choose which data type to use for each individual variable.

Roy Lewallen, W7EL

Yes, you are correct. In "C"/C++ conversion is automatic (or generates a
compiler error prompting you to "cast" to another type) if there is the
slightest chance you will unintentionally lose precision...
If I go to VB or Fortran I tend to get a lot of math errors (which are not
caught by the compiler, but in real world use!) until I remember to
compensate and control my code better... double precision is used by
"C"/C++ (the "double"(integer) and "float"(floating point) variables) also
(you are right, it is related to the size, in bytes(bits), of the math
variable(s) in question), no problem--it is just more transparent in C.
And, you are correct again, "precision" is only a matter of where you wish
to "quit", and "double-double-precsion" and greater are able to be done,
either as a function of the compiler, hard code a routine directy in
assembly language yourself, or the programmer can institute them in the high
level code...
Visual Basic, Fortan, COBOL (yuck!), Pascal, "C", etc, etc are usually only
a matter of syntax, style, speed and preference... "C" is just my personal
preference...

Years ago it was common for Basic/VB to constantly have issues with math
variables (actually, changes to the functions in the OS) in each new release
of windows, I live in the past... frown

Warmest regards,
John

"Roy Lewallen" wrote in message
...
John Smith wrote:
I could be wrong, and Roy will correct me if I am, but EZNEC seems to be
written in Visual Basic, or similar... might you need the run-time
libraries for an older edition?

No, that's not the problem -- it's due to DOS not being able to properly
determine the size of a large amount of RAM. And the DOS versions were
written with the MS BASIC Professional Development System, not Visual
Basic. Windows versions of EZNEC (v. 3.0 and 4.0) are written in Visual
Basic, except the calculating engines and a few speed-critical main
program routines which are written in Fortran.

And, he (Roy) mentions "double percision"--a nasty reality of basic (and
some Fortran compilers also), which seems to confirm my suspicions...

Double precision isn't a "nasty reality" -- it's simply a way of storing
floating point variables. Normal precision floating point variables are
stored in four byte words, and consequently have a resolution of about
seven significant decimal digits. Double precision variables require 8
bytes and have about 15 significant digits of resolution. Fortran
additionally has a complex data type which requires twice as much storage
space, since each variable of that type has two parts. Some compilers have
additional, higher precisions available. The program author can choose
which data type to use for each individual variable.

Roy Lewallen, W7EL

The C "float" type is equivalent to the VB Single and Fortran Real
variable types, which are single precision (4 bytes) -- I forget what
they call the double precision real variable in C. Integers are another
matter -- all have the same precision, and the only difference between
different sizes is the size of number they can contain. It's hard to
believe a compiler can tell when you'll lose precision, since it depends
on many factors in the course of the calculation including the order of
calculation, as well as the actual variable values. I don't know what
kind of "math errors" you got when you tried to use some other language,
but it's not because the numerical precision is any less with one
language than another. Careless programming in any language can cause
errors and loss of accuracy.

I'm not aware of any problem with Basic or VB with regard to variable
precision or other issues with variables. I've programmed in HP, DEC,
GW, Quick, and other flavors of Basic since the mid '60s, and VB since
v. 4. Every language has its strong and weak points, but for many years
now mathematical calculation quality has been determined by the
hardware, not the language. I suppose the language could have made a
difference before the days of the coprocessor. However, my first
commercial program, ELNEC, was introduced in early 1990 in coprocessor
and non-coprocessor versions, and I never saw a significant difference
in results between the two -- and it did some extremely intensive
floating point calcualations. So if there was some problem, it must have
occured before that.

As a side note, I once fell for the alleged superiority of C with regard
to speed compared to Basic, and reprogrammed the calculation portion of
ELNEC with Quick C. The result was that the compiler generated about 30%
more code than with the Basic PDS I was using, and it ran about 30%
slower. Some genuine C gurus where I was working looked over the code
and couldn't find anything I'd done which would cause it to run slower
than optimum. So there are good and poor compilers in all languages.

This has strayed way off topic, and the OP has contacted me directly, so
I'll exit this thread now.

Roy Lewallen, W7EL

John Smith wrote:
Yes, you are correct. In "C"/C++ conversion is automatic (or generates a
compiler error prompting you to "cast" to another type) if there is the
slightest chance you will unintentionally lose precision...
If I go to VB or Fortran I tend to get a lot of math errors (which are not
caught by the compiler, but in real world use!) until I remember to
compensate and control my code better... double precision is used by
"C"/C++ (the "double"(integer) and "float"(floating point) variables) also
(you are right, it is related to the size, in bytes(bits), of the math
variable(s) in question), no problem--it is just more transparent in C.
And, you are correct again, "precision" is only a matter of where you wish
to "quit", and "double-double-precsion" and greater are able to be done,
either as a function of the compiler, hard code a routine directy in
assembly language yourself, or the programmer can institute them in the high
level code...
Visual Basic, Fortan, COBOL (yuck!), Pascal, "C", etc, etc are usually only
a matter of syntax, style, speed and preference... "C" is just my personal
preference...

Years ago it was common for Basic/VB to constantly have issues with math
variables (actually, changes to the functions in the OS) in each new release
of windows, I live in the past... frown

Roy Lewallen wrote:

-- I forget what
they call the double precision real variable in C.

double

-j

Back in the dark ages, when I was in school, we were "encouraged" to take a
numerical analysis course if we were interested in computers. (I was an EE
major.) It was not an easy topic, but it made us well aware of the
difference between correct results and computational precision. I was
recently astonished to find that most computer science students have no
concept of this area and even less interest in it.

These current thoughts extend to other areas:

- C is more accurate than Fortran (or Basic, or what whatever)
- Obtaining "stable" numeric results means you get the same answer if
you run the program twice
- C produces the fastest programs
- if C is good then C++ is better
- Using all the obscure C operators produces a better program

(Anyone remember the IBM 7030 system? The user could control the rounding
direction of the floating point LSB. In this case running a program twice
(with different rounding options) really was relevant.)

Bill
W2WO

"SignalFerret" wrote in message
news:JoW9e.26259$jd6.8685@trnddc07...
I'm trying to get Eznec ver 2 to run on a WinXP machine, but I keep
getting an Error 137, insufficent memory. Does anyone have a suggestion
on what I need to set, or fix?

Any help would be appreciated. Please post to the news group, as this
address doesn't have a mailbox associated with it to avoid spam.

Robert
N3LGC


Is that a DOS program? I recall upgrading to a Windows version, and think
it was 3.x.

Tam