Qbasicnews.com

Wel, one more time, some will not learn anything and some will, but this can be helpful :

The SIN and COs standard functions of QB are "exact" only in a given range. For example, if you type

Pi = ATN(1)*4 (or Pi = 3.141593, that's equal)

then

Print COS(Pi/2)

You will get -4.371139 E-8 instead of zero. This is sufficient most of the time, but unsufficient if you, for example, build a Hi-Res raytracer capable of plotting quadric shapes such as a torus or any twisted 4th degree shape on a 1024x768 screen. Those who guessed I'm buiding such a raytracer are right :rotfl: )

That simply comes from the fact that SIN and COS are correct only for a given range of angles (0 to Pi/4 for sinus).

If you need "exact" values, you may follow this code, and adapt it to your habits:

CONST Pi = 3.141592653589793# ' In the main module

FUNCTION CosD (A)
A = A - INT(A / 360 + .5) * 360
IF A >= 0 AND A <= 90 THEN
x# = A / 180 * Pi
IF COS(x#) < .5 THEN
CosD = SIN(Pi / 2 - x#)
ELSE
CosD = COS(x#)
END IF
EXIT FUNCTION
END IF

IF A < 0 AND A >= -90 THEN
x# = -A / 180 * Pi
IF COS(x#) < .5 THEN
CosD = SIN(Pi / 2 - x#)
ELSE
CosD = COS(x#)
END IF
EXIT FUNCTION
END IF

IF A > 90 AND A <= 180 THEN
x# = (180 - A) / 180 * Pi
IF COS(x#) < .5 THEN
CosD = -SIN(Pi / 2 - x#)
ELSE
CosD = -COS(x#)
END IF
EXIT FUNCTION
END IF

IF A < -90 AND A >= -180 THEN
x# = (A - 180) / 180 * Pi
IF COS(x#) < .5 THEN
CosD = -SIN(Pi / 2 - x#)
ELSE
CosD = -COS(x#)
END IF
EXIT FUNCTION
END IF

END FUNCTION


Now for an "exact" Sinus :

FUNCTION SinD (A)
SinD = CosD(90 - A)
END FUNCTION

Much easier after the first one...

that. Every other dialect of Basic will do similar things, as will every other programming language. It isn't actually the dialect or the language doing it. It's your digital computer doing it. (And there's also the fact that there is no computational method of obtaining generally exact values of trig functions (as well as many others), regardless of what programming tool is used.)

I was trained, when I was a student (I had hair by this time ), to solve numeric problems where we were quoted not by the answer, but by the method we used... and that was a real pain in the a... !

The machine is not a issue any longer, since Intel and Co's gave us 32 bits native processors, and hence, calculations.

The issue becomes : how far can we go with source codes anyone can read, while having "profesionnal" rendering ? We all know a 32 bits compiler can probably handle these issues...

The Mandelbrot Set images that are shown on The Mandelbrot Dazibao are a proof that anyone can generate top-rank fractal pics without being a programmation nerd. Quoting Robert Munafo himself : "I forgot to tell you that your M-Set pics are quite good". Check http://mandelbrot.dazibao.free.fr/Gallery/Gallery.htm to see what he was talking about (the pics there are Jpegs only, but the Qb sources are available for BMP's, along with the tutorials to get your hands on it!).

I'm currently building raytracing modules that can compare with POV-Ray "only" with QB: the aim of the game is not to prove programming is a way of living, only my wife and my daughters will ever complain about that :rotfl:

I just want to give genuine open sources to people who, like me, cannot just stand in front of a wall, saying " that's a wall" : I'm one of the ones who want to take a look at what's behind, just in case a wonderful, beautiful May Queen stands there... No Tea Lady!

As for today, I need a Cosine routine that gives acceptable values within a honnest QB code, this routine being a "#" function accepting a "#" argument.

Just for the sake of undressing POV-Ray, after having undressed Fractint: I tried undressing Terragen, but I have to admit http://mandelbrot.dazibao.free.fr/Ground/Ground.htm cannot compare: I will keep my clothes on for fractal landscapes 8)

More to come, but I have to focus on that cosine stuff before plotting real new pics... if you have checked what the TC-Lib 1.2 can do, you will see the current version has grown up from quadratic to quadric shapes :wink:

wow, cool

some magical property of 32-bit CPUs that makes the digital storage inaccuracy problem go away, because the number of bits used by the CPU is totally irrelevant. It relates to how many bits are used to store the number. The fundamentals of floating point number storage haven't changed from when 8-bit CPUs were common.


"The machine is not a issue any longer, since Intel and Co's gave us 32 bits native processors, and hence, calculations."

The prog I'm tuning uses hundreds of divisions and multiplications, and the double length calculations are perfect for what I do. After tracking the results variable per variable on the pixel for which the equation solver gives a wrong result, my conclusion is that the error comes from the first calculation : the 3D rotation matrix, based on sines and cosines... The first correction I applied solved a first bug, but the fact that the matrix is not strictly normalised propagates an error through the code, until a wrong pixel colour codes...

I made comparisons with Excel, which seems to have a better cosine function : does anybody know how these functions can be reprogrammed from scratch, even if it is assember code ?

Nope, there probably are a few numerical methods for it. Probably based on taylor series and stuff. ehum

Jark:
If you are using ffix, remember it masks the division by zero errors.
Instead of an error it generates s strange value with the INV characters on it (!!!) that propagates thru the calculations..
It may be a good thing to disable ffix while you are debugging.
I found this while making my 3d mesh rotator...