Home |
Search |
Today's Posts |
#7
![]() |
|||
|
|||
![]()
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 |
Thread Tools | Search this Thread |
Display Modes | |
|
|
![]() |
||||
Thread | Forum | |||
JvComm32 and other digisoft on WinXP | General | |||
Mismatch Uncertainty and an EZNEC transmission line sudy | Antenna | |||
EZNEC v. 4.0 at Dayton | Antenna | |||
3 antennas modeled with EZNEC | Antenna | |||
Eznec modeling loading coils? | Antenna |