Plotting a circle the Hard way (in GWBASIC)

[CP/M User]

Re: Another GWBASIC sin&cos functions coding

Re: Another GWBASIC sin&cos functions coding

"nodoubt73" wrote:

> Here another way.... :

> Sin function

10 INPUT X#
20 GOSUB 1000
30 PRINT Y#
40 END
1000 REM SIN(X#). X# IN RADIANTS. OUTPUT IN Y#
1010 RESULT# = 0 : SIGN%=-1
1020 DOUBLEPI#=6.283185307#
1030 PRECISION = 50
1040 TEMP% = X#/DOUBLEPI#
1050 X#=X#-TEMP%*DOUBLEPI#
1060 FOR K=1 TO PRECISION
1070 ADDENDUM#=X#
1080 FOR SCANIT=2 TO 2*K+1
1090 PARTQUOT#=X#/SCANIT
1100 ADDENDUM#=ADDENDUM#*PARTQUOT#
1110 NEXT SCANIT
1120 RESULT#=RESULT#+(ADDENDUM#*SIGN%)
1130 SIGN%=SIGN%*-1
1140 NEXT K
1150 Y#=X#+RESULT#
1160 RETURN

> and Cos function

10 INPUT X#
20 GOSUB 1000
30 PRINT Y#
40 END
1000 REM COS(X#). X# IN RADIANTS. OUTPUT IN Y#
1010 RESULT# = 0 : SIGN%=-1
1020 DOUBLEPI#=6.283185307#
1030 PRECISION = 50
1040 TEMP% = X#/DOUBLEPI#
1050 X#=X#-TEMP%*DOUBLEPI#
1060 FOR K=1 TO PRECISION
1070 ADDENDUM#=X#
1080 FOR SCANIT=2 TO 2*K
1090 PARTQUOT#=X#/SCANIT
1100 ADDENDUM#=ADDENDUM#*PARTQUOT#
1110 NEXT SCANIT
1120 RESULT#=RESULT#+(ADDENDUM#*SIGN%)
1130 SIGN%=SIGN%*-1
1140 NEXT K
1150 Y#=1+RESULT#
1160 RETURN

Does that work in DEGrees or RADians?

For example, SIN 1 in DEGrees is
0.017452406 & COS 1 in DEGrees
is 0.999847695. In RADians SIN 1
is 0.841470984 & COS 1 is
0.540302305.

So if that works in DEGrees, then that
could be something I could port to TP.

Cheers,
CP/M User.

 

[carlsson]

Re: Another GWBASIC sin&cos functions coding

Re: Another GWBASIC sin&cos functions coding

1000 REM SIN(X#). X# IN RADIANTS. OUTPUT IN Y#

Does that work in DEGrees or RADians?

Radians it seems. Otherwise it is fairly easy to convert degrees into radians or the other way:

DEG = RAD * (180/pi) : REM 180/pi ~= 57.29578
RAD = DEG / (180/pi)

 

[nodoubt73]

Re: Another GWBASIC sin&cos functions coding

Re: Another GWBASIC sin&cos functions coding

Does that work in DEGrees or RADians?
For example, SIN 1 in DEGrees is
0.017452406 & COS 1 in DEGrees
is 0.999847695. In RADians SIN 1
is 0.841470984 & COS 1 is
0.540302305.
So if that works in DEGrees, then that
could be something I could port to TP.
Cheers,
CP/M User.

Hi there. IT's all in RADIANTS.
indeed lines 1040 and 1050, as you see, are there to "normalize"
the parameter, that means it will "reduce" it to 0-6.28 range that's
the angle (as you see before and afterward it all repeats to infinite).
I had to use 2 lines to do that in basic (or better 2 statements, could
stay all in one line). In C (language in which I originally wrote
this serie method to implement trigonom. functions) the normalization
was:

x = x-((unsigned long)(x/DoublePI))*DoublePI;

where x and DoublePI are defined as "double".
I could probably do that with a remainder function, but I needed
top performance (this is a real life application, gotta control a 4
stepper motor interpolation, real time stuff).

Just to give coupla info more:
PRECISION identifier is something up to you and your machine power.
The bigger that value is the better result you get. As you may guess
the serie method to calculate these function tends to be perfect as long
as the serie is infinite. Ofcourse this ain't possible, so you gotta tell
the machine how many serie item you wanna evaluate.

This serie method is simply the Mac Laurin one.
To put it in coupla lines, it says:

sin(x) = x - (x^3) + (x^5)+..+(-1)^(n-1)*( x^(2n-1))
                 -------    --------                --------------
                     3!         5!                               (2n-1)!

Using the same principle, I've the coding for the functions
Tan, ArcSin, ArcCos.

Ciao

 

[CP/M User]

Re: Another GWBASIC sin&cos functions coding

Re: Another GWBASIC sin&cos functions coding

"carlsson" wrote:

>> Does that work in DEGrees or RADians?

> Radians it seems. Otherwise it is fairly easy
> to convert degrees into radians or the other
> way:

> DEG = RAD * (180/pi) : REM 180/pi ~= 57.29578
> RAD = DEG / (180/pi)

Carlsson, if you say it's easy to covert, could you
(or someone here) at least show me what I'm doing
wrong, because I seem to be missing something:

Set Calculator to DEGrees:

SIN 1 = 0.017452406
Put in Memory

Now I'm calculating it like this:

Memory Recall (0.017452406)/ (180/3.141592654) =
57.29577951, I'm sorry, but this just isn't the RAD
value of SIN 1! Or 'am I doing something wrong?

Cheer,
CP/M User.

 

[CP/M User]

Re: Another GWBASIC sin&cos functions coding

Re: Another GWBASIC sin&cos functions coding

"nodoubt73" wrote:

> Hi there. IT's all in RADIANTS.
> indeed lines 1040 and 1050, as
> you see, are there to "normalize"
> the parameter, that means it will
> "reduce" it to 0-6.28 range that's
> the angle (as you see before and
> afterward it all repeats to infinite).

> I had to use 2 lines to do that in
> basic (or better 2 statements, could
> stay all in one line). In C (language
> in which I originally wrote this serie
> method to implement trigonom.
> functions) the normalization
> was:

x = x-((unsigned long)(x/DoublePI))*DoublePI;

> where x and DoublePI are defined as
> "double".
> I could probably do that with a
> remainder function, but I needed
> top performance (this is a real life
> application, gotta control a 4 stepper
> motor interpolation, real time stuff).

> Just to give coupla info more:
> PRECISION identifier is something
> up to you and your machine power.
> The bigger that value is the better
> result you get. As you may guess
> the serie method to calculate these
> function tends to be perfect as long
> as the serie is infinite. Ofcourse
> this ain't possible, so you gotta tell
> the machine how many serie item
> you wanna evaluate.

> This serie method is simply the Mac
> Laurin one.
> To put it in coupla lines, it says:

sin(x) = x - (x^3) + (x^5)+..+(-1)^(n-1)*( x^(2n-1))
            ------- --------            --------------
               3!      5!                    (2n-1)!

> Using the same principle, I've the
> coding for the functions Tan, ArcSin,
> ArcCos.

Hi there, it makes for interesting reading,
unfortunately my maths isn't so sofisicated
as I'd like it to be.

For the machine I'm using, I'm finding that
my values don't need to be highly accurate
because they are being used for graphical
purposes. Sure if the resolution of the screen
was more than 16k bigger numbers would be
required.

Cheers,
CP/M User.

 

[nodoubt73]

Re: Another GWBASIC sin&cos functions coding

Re: Another GWBASIC sin&cos functions coding

"nodoubt73" wrote:
Hi there, it makes for interesting reading,
unfortunately my maths isn't so sofisicated
as I'd like it to be.

For the machine I'm using, I'm finding that
my values don't need to be highly accurate
because they are being used for graphical
purposes. Sure if the resolution of the screen
was more than 16k bigger numbers would be
required.

Cheers,
CP/M User.

just decrease the PRECISION 8)

 

[carlsson]

Re: Another GWBASIC sin&cos functions coding

Re: Another GWBASIC sin&cos functions coding

> DEG = RAD * (180/pi) : REM 180/pi ~= 57.29578
> RAD = DEG / (180/pi)
Set Calculator to DEGrees: SIN 1 = 0.017452406
Memory Recall (0.017452406)/ (180/3.141592654) = 57.29577951

Try push ENTER once more, as 180/pi = 57.295. I think your calculator has a surprise in store for you.

Remember than sinus of one radian (57 degrees) will be 0.84, while sinus of one degree (0.017 radians) will also be 0.017. Somewhere around pi/6 (30 degrees), there will be a difference between the input argument and the sinus result.

 

[CP/M User]

Re: Another GWBASIC sin&cos functions coding

Re: Another GWBASIC sin&cos functions coding

"carlsson" wrote:

>>> DEG = RAD * (180/pi) : REM 180/pi ~= 57.29578
>>> RAD = DEG / (180/pi)

>> Set Calculator to DEGrees: SIN 1 = 0.017452406
>> Memory Recall (0.017452406)/ (180/3.141592654) =
>> 57.29577951

> Try push ENTER once more, as 180/pi = 57.295. I
> think your calculator has a surprise in store for you.

> Remember than sinus of one radian (57 degrees) will
> be 0.84, while sinus of one degree (0.017 radians)
> will also be 0.017. Somewhere around pi/6 (30
> degrees), there will be a difference between the input
> argument and the sinus result.

Strewth, I did something which got me a value of
0.999949231 & I then did the (180/pi) which got me
the .017452406.

Oh now I got it, SIN 1 * (180/pi) = 0.999949231. Oh but
wait, no I've got this horribly wrong because the value
I'm after here is 0.841470984.

Help!! :-(
CP/M User.

 

[carlsson]

Re: Another GWBASIC sin&cos functions coding

Re: Another GWBASIC sin&cos functions coding

SIN 1 * (180/pi) = 0.999949231.
Oh but wait, no I've got this horribly wrong because the value
I'm after here is 0.841470984.

Hmm.. not sure what you're trying to do. Does your calculator or computer really work with radians or degrees? Four scenarios:

1. SIN 1 * (180/pi) will calculate sinus of 1 (something) and then multiply with 57.295. OK?

2. Sinus of 1 degree is 0.017, while sinus of 1 radian is 0.841, so either you get 0.999949 or 48.21273601. OK?

3. SIN (1*(180/pi)) will give you the sinus of 57.295 (something). OK?

4. Sinus of 57.295 degrees is 0.84 as I wrote. Sinus of 57.295 radians wraps around many times and ends in 0.679522. OK?

 

[CP/M User]

Re: Another GWBASIC sin&cos functions coding

Re: Another GWBASIC sin&cos functions coding

Hi carlsson,

I've just come from a maths Usenet group
which showed me what I did wrong.

I was going into Radians for example &
doing a SIN 1 first, got the result from that
& then tried to convert that result into
Degrees.

I didn't realise it was the number after SIN
which needed to be converted.

Having said that I did this to get the right
result.

1 * PI/180 = 0.017453292
SIN 0.017453292 = 0.017452406 (which is
the answer to SIN 1 in Degrees!

Just for good measure I tried SIN 2 just to
make sure it wasn't a fluke:

2 * PI/180 = 0.034906585 &
SIN 0.034906585 = 0.034899496!

Oh well, the main thing is I got it eventually
with some help! ;-)

Thanks,
CP/M User.

 

[carlsson]

Re: Another GWBASIC sin&cos functions coding

Re: Another GWBASIC sin&cos functions coding

I didn't realise it was the number after SIN which needed to be converted.

You mean the argument to SIN, or the result after applying SIN?

Just for good measure I tried SIN 2 just to
make sure it wasn't a fluke:

Try 30, 60, 90 etc and see if you still get the right results. As I wrote above, around pi/6 radians (30 degrees), the difference between input angle and the SIN function is getting so large that you can deduct what "happened". 8)

 

[CP/M User]

Re: Another GWBASIC sin&cos functions coding

Re: Another GWBASIC sin&cos functions coding

"carlsson" wrote:

>> I didn't realise it was the number after
>> SIN which needed to be converted.

> You mean the argument to SIN, or the
> result after applying SIN?

Originally, I was trying to convert the result
from SIN 1 into Degrees! ;-)

>> Just for good measure I tried SIN 2
>> just to make sure it wasn't a fluke:

> Try 30, 60, 90 etc and see if you still
> get the right results. As I wrote above,
> around pi/6 radians (30 degrees), the
> difference between input angle and the
> SIN function is getting so large that you
> can deduct what "happened". 8)

Yes, SIN 30 while it's not 0.5 the result was
0.499999999 seems close enough! ;-)
The other two provided the correct answers
in both cases (SIN 60 = 0.866025403 &
SIN 90 = 1).
While I'm using a calculator which can do
upto 9 decimal places, in case of SIN 30
if you did need the persise answer (of 0.5)
you'd perhaps need a calculator to support
more decimal places (don't ask me how
many), but more so that PI is accurate
enough (some people say that they know
PI to the 100th decimal place - that's 3.
<followed by 100 numbers!> I've always
wondered why, so perhaps this is it - but
that would mean building a calculator
which would have to be of a large figure
in order to fit those 101 digits! ;-)

Cheers,
CP/M User.

 

[carlsson]

Yup, Pi is a story on its own. I once read an article about a mathematician where he quoted someone who had said that Pi lately had changed from a mysterious number into something you wash your mouth with, when calcuation of Pi had moved from people's hand work to powerful computers doing one million of decimals just for fun.

 

[CP/M User]

"carlsson" wrote:

> Yup, Pi is a story on its own. I
> once read an article about a
> mathematician where he
> quoted someone who had
> said that Pi lately had changed
> from a mysterious number into
> something you wash your mouth
> with, when calcuation of Pi had
> moved from people's hand work
> to powerful computers doing one
> million of decimals just for fun.

Maybe for the serious mathematician
it maybe critical that they get the
most accurate read out, but for the
purpose of programming, it may not
be as critical (well maybe not in to
area of graphics). My Demonstration
that I posted earlier, which calculates
the Degrees to draw up a circle, is
only using Pi to 6 decimal places.
While the answer wouldn't be as
accurate (verus a 9 decimal place),
the image seems to be correct (or
to the effect that it looks right. There
maybe a few little gaps in it, but
that just happens to be the way this
draws itself out (even on the Ol'
Amstrad it happens).

Cheers,
CP/M User.

 

[carlsson]

The gaps are probably due to other reasons than Pi accuracy, i.e. you would need some addition to the drawing algorithm that decides which pixels between addressed pixels should also be lit. Off-hand I don't know how to make those decisions, but maybe there can be straight lines between two dots which happen to have a distance of more than one pixel in between.

 

[Barry]

There is the Bresneham circle drawing algorithm, which I've just heard of but don't know how to code, that follows a pattern of pixels, pixel to pixel, forming a circle. It's not made from endpoints of radii.

If you use a formula involving PI I think you're probably stuck with drawing lines from pixel to pixel to be sure the circle is closed.

One method I read about years ago that speeds the drawing of a circle is to only calculate a segment and replicate it. I don't remember the details of this. I'm not sure but it might have been part of the Bresneham circle algorithm.

It shouldn't be hard to google some information on this.

Barry

 

[CP/M User]

"carlsson" wrote:

> The gaps are probably due to other reasons
> than Pi accuracy, i.e. you would need some
> addition to the drawing algorithm that decides
> which pixels between addressed pixels should
> also be lit. Off-hand I don't know how to make
> those decisions, but maybe there can be
> straight lines between two dots which happen
> to have a distance of more than one pixel in
> between.

To be honest, it's not something I've considered
doing, because it's such a variable effect, in
which is varys depending on the size of the circle
& the resolution for which it's been drawn in. In
320x200 for example, there are fewer gaps.

It's not really something I'd worry about, in a way
I'm glad it's happened, cause it's more like the
circles drawn on an Amstrad. Since I've written an
equivalent program for the IBMs, it would have
been unusual if this gap effect didn't happen!

Cheers,
CP/M User.

 

[CP/M User]

"Barry" wrote:

> There is the Bresneham circle drawing algorithm,
> which I've just heard of but don't know how to
> code, that follows a pattern of pixels, pixel to
> pixel, forming a circle. It's not made from
> endpoints of radii.

Think I've got a BASIC example somewhere for
the Amstrad. I'll try & find it & port it over. I know
I've got one which plots a pixel by pixel around the
edge of the circle, but I'm sure there was another
one which draws a solid line around the edge too.

Cheers,
CP/M User.

 

[CP/M User]

"CP/M User" wrote:

>> There is the Bresneham circle drawing algorithm,
>> which I've just heard of but don't know how to
>> code, that follows a pattern of pixels, pixel to
>> pixel, forming a circle. It's not made from
>> endpoints of radii.

> Think I've got a BASIC example somewhere for
> the Amstrad. I'll try & find it & port it over. I know
> I've got one which plots a pixel by pixel around the
> edge of the circle, but I'm sure there was another
> one which draws a solid line around the edge too.

Yeah, basically you modify my program in line 40,
so instead of saying you want to draw a line from
the centre of the circle, you tell it to draw around:

Basically, it would look like this:

 40 LINE (320+XPOS-1,100+YPOS-1)-(320+XPOS,100+YPOS)

I don't think they call this the Bresneham drawning
algorithm though, some of the code I've seen which
demonstrates this, goes into some of the more
advance math.

Cheers,
CP/M User.

 

[Barry]

Basically, it would look like this:
Code:

 40 LINE (320+XPOS-1,100+YPOS-1)-(320+XPOS,100+YPOS)

I don't think they call this the Bresneham drawning
algorithm though, some of the code I've seen which
demonstrates this, goes into some of the more
advance math.

That's not the bresneham algorithm. Bresneham wrote a method by for calculating each pixel. Line drawing isn't needed. Line drawing around the circle using radii is a simpler method. Bresneham is used when speed is needed. It's unique in that it doesn't need division or multiplcation. Only addition or subtraction, which are much faster in most processors.

There's also a bresneham line drawing algorithm.

Barry