sqrt(40000)
Kim
I'm writing a program that needs to find the distance 'tween two
points. I'm not interested in speed, so I'm using this:
dist:=sqrt(sqr(x)+sqr(y));
However, if x=200, it crashes with an invalid floating point
operation. Trying to debug it, I simplify to this:
dist:=sqrt(x*x);
It still crashes. On the other hand, sqrt(40000) has no problems.
Anybody know why?
By the way, I'm going around the problem by dividing by 100, then
multiplying the sqrt by 10. :)
--
Kim (OK...@max.tiac.net)
Ashish Mishra
> Anybody know why?
I can't see why it wouldn't work unless X is defined as an integer and
is only valid between 32627 and -32627.
Otherwise it should work (it does in UNIX).
Ashish.
Bell Northern Research
p.s. I never ever speak for BNR!
Duncan Murdoch
> However, if x=200, it crashes with an invalid floating point
>operation. Trying to debug it, I simplify to this:
>dist:=sqrt(x*x);
> It still crashes. On the other hand, sqrt(40000) has no problems.
> Anybody know why?
You're overflowing the multiplication, and returning a negative. If you're
using BP 7, turn on overflow checking ($Q+) and you'll see this.
To do the multiplication without getting an overflow, use the LongMul routine
(from the Objects unit), or just typecast to a type that can handle it, e.g.
Longint or Real.
Duncan Murdoch
Bob Dell 1
Try this in your calculations.
x=sqrt(40,000)
break up 40,000 into pairs starting at the decimal point like this
4 00 00
take the first number and get the nearest square root of it.
write it on top (like they teach you to do in math class under division, but
put the numbers above the pairs. in this example the first pair would be "04").
first number gets squared and subtracted from the first pair.
Second and continuing steps are as follows:
bring down the second pair next to the remainder as if you were dividing.
take the first number and multiply it by 10 (ex:2 would become 20) and start
from 0 to 9 and put the sample numbers in the top and units place and multiply
them together.
ex:(20*0, 21*1, 22*2 ... 29*9) and get the number that comes closest to the
remainder without going over it. This is the number to go over the next pair.
subtract and get another remainder.
If you don't have enough digits or you have more digits to go until you reach
the decimal point then go back to step #2.
This is the TEXTBOOK approach of obtaining square roots from a number by hand
with a pencil and paper. You may HAVE to re-invent the wheel for your
application.
I hope this works for you or better yet, I hope you understand it.
bobd...@aol.com
Dave Ingram
>You're overflowing the multiplication, and returning a negative. If you're
>using BP 7, turn on overflow checking ($Q+) and you'll see this.
This is a problem that has happened to me too in the past. Would
experienced users of Turbo Pascal care to post the compiler directives
that they recommend for the different stages of a programming project.
The manual does say what each switch does (as does THelp), but knowing
what is silly and what is critical is sometimes difficult.
Knowing the switches to use for development for bug-catching, and then
the ones for a streamlined final exe would really help me. I'm sure
others would benefit too, so if you have recommendations please post
them here (if you can't post, mail me them and I will forward on your
behalf).
Thanks alot,
Dave.
--
/////// ==> ing...@monster.equinox.gen.nz <== [At home - Pref.]
( O O ) ==> d.in...@csc.canterbury.ac.nz <== [At University]
[=( o )=] ==> ingr...@kosmos.wcc.govt.nz <== [At CityNet}
(___) Christchurch, New Zealand (172.40E, 43.33S)
Duncan Murdoch
>From: ing...@monster.equinox.gen.nz (Dave Ingram)
>Subject: TP Compiler Directives
>Date: Thu, 07 Apr 94 06:38:29 GMT
>In article <dmurdoch.87...@mast.mast.queensu.ca>
>dmur...@mast.mast.queensu.ca writes:
>>You're overflowing the multiplication, and returning a negative. If you're
>>using BP 7, turn on overflow checking ($Q+) and you'll see this.
>This is a problem that has happened to me too in the past. Would
>experienced users of Turbo Pascal care to post the compiler directives
>that they recommend for the different stages of a programming project.
>The manual does say what each switch does (as does THelp), but knowing
>what is silly and what is critical is sometimes difficult.
>Knowing the switches to use for development for bug-catching, and then
>the ones for a streamlined final exe would really help me. I'm sure
>others would benefit too, so if you have recommendations please post
>them here (if you can't post, mail me them and I will forward on your
>behalf).
Here's what I use in BP 7 during development:
{$A+, Word alignment on. It costs so little for a small speedup, so why
not?
B-, Shortcut boolean evaluation. I rarely code tests to have side
effects, so it's worthwhile stopping the evaluation when the answer
is known.
D+, Debug information on. I'll probably want to debug during
development. I might turn this off for some units once I'm confident
about them; then I won't trace into them when I don't want to.
E+ or E-, Depends on the project whether I want coprocessor emulation.
F-, Default near calls. I prefer to explicitly declare calls to be far
when I want that.
G-, 8086 code. Most of my programs will run on an 8086, so I leave this
setting for 8086 code. There isn't much advantage to G+ anyways.
I+, I/O checking on. The problems caused by forgetting to check IOResult
are so time wasting that I only select I- locally.
L+, Local symbols on. If I'm debugging, I'll want to look at symbols.
N- or N+, If I'm doing floating point, I'll need N+, but otherwise, I
leave it off.
O-, Don't generate overlay compatible code. I rarely use overlays. If
I did, I'd use O+ instead.
P-, Strings are strings, not open strings. If I want open strings I'll
declare them.
Q+, Overflow checking on. Lots of errors are caused by overflows.
R+, Range & object checking on. Lots of errors are caused by out of
range variables, or objects that have been damaged or not
initialized. This can often catch those.
S+, Stack checking on. If my program overflows the stack, I want to
know about it.
T+ *and* T-, For strictest type checking of assignments, your program
has to compile with both T+ and T- options. I wish Borland would
make T+ stricter than T-, but they didn't.
V+, I never pass a string shorter than the declared type as a var
parameter. There are ways to do that safely, but they're not worth
the risk.
X-, I usually want the strictest language definition, and
that comes with X-. With X+ I can forget to save the result of a
function, and that will cause trouble.
Y+ Do generate symbol information. The Browser in the BP 7 IDE is a
fantastic tool, and this lets it work.
When the project is ready to ship, the only changes I make are Q- and R-.
This still leaves run-time I/O and stack checks in place, but I think those
are worth the cost. It also leaves debug information in place; I use
TDSTRIP to remove that. This caused me trouble in the past because of a bug
in TDSTRIP, but I think the current version works fine. However, it lets me
do last minute debugging on the final version, just to make sure that
changing Q and R didn't change anything, so I think it's worth it.
Finally, just before I package things up I run Lastlook (garbo.uwasa.fi:
/pc/turbopas/lastlook.zip) to give me some peace of mind that the options
were really set the way I thought they were.
Duncan Murdoch
dmur...@mast.queensu.ca
Pete Doronzio
-> It still crashes. On the other hand, sqrt(40000) has no problems.
Check the TYPE of x.
When the expression x*x is evaluated the result is placed in a temporary
variable of the same TYPE as x. This may cause an overflow.
Try typecasting x to a bigger TYPE, or declaring x as a bigger type.
(double?)
I've been out of town for a bit, hope this isn't too old a message...
-Pete
----------------------------------
| '' Pete d'Oronzio |
| pppp d ' Pd' Programming |
| p p d 1235 Apollo Dr |
| p p d Lafayette, CO |
| ppp ddd USA |
| p d d |
| p d d Pe...@PdProg.Com |
| p dddd 303-666-7896 |
| |
| Programming Magic Happens! |
----------------------------------