|
-
Oct 15th, 2001, 10:03 AM
#1
Thread Starter
Lively Member
sin, cos & precision
Hello Everyone.
I'm aware that VB's highest precision variable, double, will only accept a number with less than 15 decimal places. I'm also aware that I can work with higher-precision numbers using text strings and converting to decimal data type using cdec(). But what about the built-in VB functions like sin and cos? These calculations are automatically returned with less than 15 decimals. Does anyone know of way to perform trig (and other math) operations to a higher precision? I did try assigning cdec(cos(AngleInRadians)) to a variant. Still returned the 15-decimal number...
Any thoughts would be greatly appreciated!
p.s. In case anyone is interested, I'm using this calculation in coordinate geometry to calculate the end-point of a line, given the start point and the line bearing.
-
Oct 15th, 2001, 01:01 PM
#2
Hyperactive Member
well it depends.
some (all?) trig functions, such as sin45, have equivalents such as 1/sqrt(2). but.... the sqr function in vb only works to 15 decimal places as well. you might have to use an iterative approach or store the sqrt(x), where x is common numbers, to a high number of decimal places beforehand.
hope that makes sense!
There are 10 types of people in the world - those that understand binary, and those that don't.
-
Oct 15th, 2001, 05:29 PM
#3
Plus, with 15 digits of precision you can measure the the distance from the sun to the Earth in millimeters. You don't really need it.
Any observation or measurement is limited by the least precise component - in physics things are measured accurately out to about 7 digits of precision or so. Since you don't commonly use trig on currency operations - what are you trying to do -- that requires more than 15? Calculate the diameter of the Universe to a micron?
-
Oct 16th, 2001, 01:11 PM
#4
transcendental analytic
sin(x) = lim k->infinity S[n=1 to k] x^(4n-3)/(4n-3)!-x^(4n-1)/(4n-1)!
cos(x) = lim k->infinity S[n=1 to k] x^(4n-4)/(4n-4)!-x^(4n-2)/(4n-2)!
If you want 64 bit precision you can approximate results iteratively with currency, if you want more you need a big integer class or
corresponding functions for byte arrays/strings, anyways vb isn't the right language to do this in, but if you don't care about speed, it is quite possible to get any accuracy in reasonable time
Use  
writing software in C++ is like driving rivets into steel beam with a toothpick.
writing haskell makes your life easier:
reverse (p (6*9)) where p x|x==0=""|True=chr (48+z): p y where (y,z)=divMod x 13
To throw away OOP for low level languages is myopia, to keep OOP is hyperopia. To throw away OOP for a high level language is insight.
-
Oct 17th, 2001, 01:06 AM
#5
Hyperactive Member
Hi kedaman, even if we can do this, we are still limited by our data type which is 15 significant places.
It is written in the MSDN that MS's long double is equivalent to double and it is allowed by ANSI C++.
"Some compilers (such as Borland's) long double type uses this extended precision.
However, other compilers use double precision for both double and long double. (This
is allowed by ANSI C.)" written by author of free ebook," PC Assembly Language", Paul A. Carter.
Nasm Pdf by Paul A Carter
long double which is 80bits, (double is 64bits and float is 32bits)
-
Oct 17th, 2001, 06:09 AM
#6
transcendental analytic
Currency in vb is a 64 bit integer with 4 decimal places
Decimal in vb is a 96 bit integer
Don't use floating points, you waste bits on the exponent
Use  
writing software in C++ is like driving rivets into steel beam with a toothpick.
writing haskell makes your life easier:
reverse (p (6*9)) where p x|x==0=""|True=chr (48+z): p y where (y,z)=divMod x 13
To throw away OOP for low level languages is myopia, to keep OOP is hyperopia. To throw away OOP for a high level language is insight.
-
Oct 18th, 2001, 12:53 PM
#7
Thread Starter
Lively Member
Thanks
Thanks, everyone, for your input.
Kedaman, thanks for your creative approach. Yet another new thing that I've learned from you ...
I'm working a program that maps flight routes. Each segment is defined by turn radius and turn angle (for curved segments) and length (for straight segments). So each rotation is dependent upon the outcome of previous rototations. I noticed that towards the end of the route the rotatations become progressively further "off". This seems to indicate that there is some kind of error leak, in which an extremely small error becomes noticible as it becomes compounded by further error. But given what jim mcnamara writes, I'm starting to think that I may have been wrong.
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|