Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

256 degree why not 360

2 views
Skip to first unread message

Sang Le

unread,
Apr 13, 1994, 5:38:44 PM4/13/94
to
Hi all,

At times I look at rotation routines of objects in 2D or 3D,
I always see that the no. of degrees used for rotation is
from 0 to 256. Why not 360? (Should I review my trig.?)
Thanks.

Please post.

Sang.

Ron Asbestos Dippold

unread,
Apr 13, 1994, 8:22:44 PM4/13/94
to
sa...@tss.com (Sang Le) writes:
>I always see that the no. of degrees used for rotation is
>from 0 to 256. Why not 360? (Should I review my trig.?)

360 is an almost totally arbitrary number of divisions of a circle
(ask the Babylonians...) . If you make the it a 256 item division,
you can hold the angle in a single byte.
--
Does the noise in my head bother you?.

RoboZapp

unread,
Apr 13, 1994, 9:09:14 PM4/13/94
to
sa...@tss.com (Sang Le) writes:

> At times I look at rotation routines of objects in 2D or 3D,
>I always see that the no. of degrees used for rotation is
>from 0 to 256. Why not 360? (Should I review my trig.?)
>Thanks.

Because many rotation routines are looking to be as fast as
possible. Generally one create faster code, expecially when dealing with
functions that are heavily based on mathematics such as graphics
routines, when using ranges that are a power of 2. 2^8 = 256, so you may
see rotations that are 0-255, with 256 being the same as 0 because it
will speed up the code. Also, when you overflow the rotation variable,
it will still be correct because the lower 8 bits will still be the same
regardless of overflow. If you used 360 degrees, overflow would cause a
"jump". In my code, I favor rotations of 0-4095 (2^12 = 4096), simply
becfause I have found that 4096 entries in a sine table gives me the
accuracy that I need, and at the same time doesn't take up huge amounts
of space.

--
RoboZapp
robo...@xmission.com

A cohort's CoHort

unread,
Apr 14, 1994, 6:42:21 AM4/14/94
to
In article <2ohop4$b...@newsflash.tss.com>, Sang Le <sa...@tss.com> wrote:
> At times I look at rotation routines of objects in 2D or 3D,
>I always see that the no. of degrees used for rotation is
>from 0 to 256. Why not 360? (Should I review my trig.?)
>
I have found that most [vectored] graphical programs (this includes
anything from video games to rotation routines) use obscure scales.
From radians to our degrees, the scales vary far and wide. I would
suspect that the reason 0-255 is used is because it fits in a short (8-bit)
int. It really doesn't matter what you use in YOUR routines, as long as
the UI uses something that the end-user understands.

--
coh...@hebron.connected.com
-----=====-----
If you're not part of the solution, you're part of the precipitate.
When all else fails, read the manual.

Mike Copley

unread,
Apr 14, 1994, 4:54:19 PM4/14/94
to
360 is almost totally arbitrary...
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

He's right, earlier civilizations thought the amount of days in a year
was 360 days and they went by the lunar calendar. However, this is a
radical tangent I suppose. In any event, most programmers use 0 to 256
degrees as a matter of convenience. Remember, most programmer's decide
to use fixed point arithmetic and trig look-up table functions for the
best possible speed on machines not equipped with floating point
processors...

Mike C.
--
==============================================================================
Michael Copley - Graduate Assistant, Arts and Sciences - U of H at Manoa
Strategic Solutions (A Development Solutions Company)
"Throw me the idol, I throw you the whip. No time to argue..." - ROTLA

Phil Carlisle

unread,
Apr 14, 1994, 2:54:27 PM4/14/94
to

Cos 0 to 255 is the value you can hold in a byte, so when you add 1 to
255 it goes to 0 again.... its mainly used for table lookups e.g.

cos = costable [angle] where angle is the angle stored as a byte...

Phil.
--

/----------------------------------------------------------------------\
| Phil Carlisle - p...@espr.demon.co.uk Hull,England...... |
| aka zoombapup // codex espr development, third eye productions... |
\----------------------------------------------------------------------/

che...@csc.canterbury.ac.nz

unread,
Apr 14, 1994, 7:15:35 PM4/14/94
to

We like using 0-255 as often as possible; the computer is optimized to handle
byte sized (2 to power 8) values. Although chips nowdays handle larger (16,32,
64 bit) numbers just as quickly, storage is still in byte-sized chunks and it
is generally easier to have say 8 bits of a 32-bit number devoted to your
integer angle, and the other 24 to the fractional value.

The exact angles are pretty arbitrary really- (take radians for eg.) -and
as long as our routine knows what the number represents its fine.

Peter

James Ojaste

unread,
Apr 15, 1994, 8:08:05 AM4/15/94
to
In article <2oj6md$g...@hebron.connected.com>, coh...@hebron.connected.com (A cohort's CoHort) writes:
|> In article <2ohop4$b...@newsflash.tss.com>, Sang Le <sa...@tss.com> wrote:
|> > At times I look at rotation routines of objects in 2D or 3D,
|> >I always see that the no. of degrees used for rotation is
|> >from 0 to 256. Why not 360? (Should I review my trig.?)
|>
|> From radians to our degrees, the scales vary far and wide. I would
|> suspect that the reason 0-255 is used is because it fits in a short (8-bit)
|> int. It really doesn't matter what you use in YOUR routines, as long as

Yikes! 8 bits is a byte - a short int is 16 bits. A long int is 32 bits.
And yes - it makes calculation easy. When you add degrees to an angle, you
probably expect to do a full circle - if you use a byte for degrees, then
you just ignore the overflow instead of doing a costly mod-type operation.

|> the UI uses something that the end-user understands.

--
main(){char n[]="James Ojaste\r";int x,y=12;while(y--,x=y)while(x--)putc(' ',0);printf("%s",n+y);}

Bernie Roehl

unread,
Apr 15, 1994, 10:23:01 AM4/15/94
to
In article <rdippold.766282964@happy>,
Ron "Asbestos" Dippold <rdip...@qualcomm.com> wrote:

>sa...@tss.com (Sang Le) writes:
>360 is an almost totally arbitrary number of divisions of a circle

Well, *almost* arbitrary. It's neatly divisible by 1,2,3,4,5,6,8,10,12,15
and so on. They chose 360 for the same basic reason we choose 256: it's
easy to work with.

--
Bernie Roehl
University of Waterloo Dept of Electrical and Computer Engineering
Mail: bro...@UWaterloo.ca
Voice: (519) 888-4567 x 2607 [work]

Lasse Reichstein Nielsen

unread,
Apr 15, 1994, 12:41:28 PM4/15/94
to
Thus spake bro...@sunee.uwaterloo.ca (Bernie Roehl):

>In article <rdippold.766282964@happy>,
>Ron "Asbestos" Dippold <rdip...@qualcomm.com> wrote:
>>sa...@tss.com (Sang Le) writes:
>>360 is an almost totally arbitrary number of divisions of a circle

>Well, *almost* arbitrary. It's neatly divisible by 1,2,3,4,5,6,8,10,12,15
>and so on. They chose 360 for the same basic reason we choose 256: it's
>easy to work with.

Not to mention te fact that their year was 360 days, so the sun did a complete
circle in 360 days... (ofcourse newyear took 5 days to celebrate...:)

Spot


--
Spot / l...@daimi.aau.dk
Triangle 3532 - The solution to your confuzion
GCS d p+ c++ l u+ e+ m- s !n h f g+ w+ t+(++) r(+) y+
Faith without Judgement merely degrades the Spirit Divine..

Pat Fleckenstein (HoseNode)

unread,
Apr 15, 1994, 2:18:39 PM4/15/94
to
In article <Co9oq...@news.Hawaii.Edu> cop...@uhunix.uhcc.Hawaii.Edu (Mike Copley) writes:
>360 is almost totally arbitrary...
>^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
>He's right, earlier civilizations thought the amount of days in a year
>was 360 days and they went by the lunar calendar. However, this is a

*Errr* try again, but thank-you for playing. 8^). 360 has some
wonderful properties. It's divisible by 1, 2, 3, 4, 5, 6, 8, 9,
10, and 12. And, as an added bonus, its divisible by 60 (the
base of the Babylonian number system). To get it to be divisible
by 7, they'd have had to go to 2520. And to toss 11 in the picture,
27720. Now, to a society that doesn't believe in fractions yet
(the Babylonians had a LAW that stated 'pi' was 4 [it was
obviously bigger than 3]), you'd want to pick a number of units
that was divisible by lots of numbers. But, they were also a
society without much in the way of calculators, so 2520 and
27720 degrees per circle was a bit unwieldy (papyrus just wasn't
that big of a jump in computing power). Ah, the sacrifices....

But, the fact that there were 360-ish days in a year was a
definite added bonus and a sign that arithmetic and geometry
came from the gods. Unfortunately it also helped Kepler waste
many years trying to formulate a view of planetary motion where
there were a bunch of circles rolling around on each other
like a giant SpiroGraph (circa. 1977). But, alas, he finally
wrestled Tycho Brahe's numbers from Newton's Royal Academy of
Science (Newton was a dork) and found the ellipse.

Ok, now that I've beat this digression into the ground....

> Remember, most programmer's decide
>to use fixed point arithmetic and trig look-up table functions for the
>best possible speed on machines not equipped with floating point
>processors...

Indeed, but I've not really been satisfied with any resolution
less than 1024 degrees per circle. Things at MAX_SHORT get too
jumpy at low-velocity otherwise. But, if I had a short-range
world, I'd definitely save myself the extra byte.

alter,
pat
--
"I've seen attack ships on fire off the shoulder of Orion."

Shannon Lawson

unread,
Apr 15, 1994, 5:56:51 PM4/15/94
to

Yeah, the way I heard it (on The Learning Channel, no less), it was decided that
a "degree" was the angle through which the earth rotated around the sun in one
day. Since the year was thought to be 360 days long, the circle was subdivided
into 360 degrees (consistent with Spot's explanation above).

This must be true, because Mark Lenard was the host, and, as well all know, it
would be illogical for Sarek to lie about this!

:-)

===============================================================================
Shannon Lawson, Systems Designer | "Knowledge is chimera - for beyond
Advanced Microcontroller Division | it ever lies other knowledge, and
Motorola Semiconductor Products Sector | the incompleteness of what is known
Austin, TX | renders the knowing false."
e-mail: law...@zappa.sps.mot.com | -- Stephen R. Donaldson
Disclaimer: Employed by, but not speaking on behalf of, Motorola SPS Austin.
===============================================================================

bmc...@vaxc.stevens-tech.edu

unread,
Apr 17, 1994, 12:35:22 AM4/17/94
to
In article <Co9oq...@news.Hawaii.Edu>, cop...@uhunix.uhcc.Hawaii.Edu (Mike Copley) writes:
> radical tangent I suppose. In any event, most programmers use 0 to 256
> degrees as a matter of convenience. Remember, most programmer's decide

i think by "most programmers" you mean "most vectorball demo programmers"..

because 256 angles is just not enough for most purposes.
if i used 256 angles in my 'doomlike' engine, the display would look very funny!

-------------------------------------------------------------------------------
Bryan McNett
bmc...@vaxc.stevens-tech.edu

John Krueger

unread,
Apr 18, 1994, 9:24:40 AM4/18/94
to
In article 72...@ultb.isc.rit.edu, p...@nick.csh.rit.edu (Pat Fleckenstein (HoseNode)) writes:
> Now, to a society that doesn't believe in fractions yet
> (the Babylonians had a LAW that stated 'pi' was 4 [it was
> obviously bigger than 3]),

Wasn't that also proposed as a bill in some state legislature?
Or was that an urban myth? I think I heard which one it was at one
time, but now I cannot remember.

---
-------------------------------------------------------------------
Disclaimer: This was written by someone who didn't know any better,
and anyway was just blowing off hot air to reduce light-headedness.
kru...@cs.hope.edu * John Krueger * and GOD said: Let there be roo
-------------------------------------------------------------------

John Krueger

unread,
Apr 18, 1994, 11:30:00 AM4/18/94
to
In article A...@cid.aes.doe.ca, oja...@devw751.ice.ncr.doe.ca (James Ojaste) writes:
>In article <2oj6md$g...@hebron.connected.com>, coh...@hebron.connected.com (A cohort's CoHort) writes:
>|> From radians to our degrees, the scales vary far and wide. I would
>|> suspect that the reason 0-255 is used is because it fits in a short (8-bit)
>|> int. It really doesn't matter what you use in YOUR routines, as long as
>
>Yikes! 8 bits is a byte - a short int is 16 bits. A long int is 32 bits.

The ANSI standard did not fix the length of any of the integer data
types. I don't think chars are even required to be 8 bits, because
when they did the standard some machines had "bytes" of 7,9,10,etc.
bits. Now you can pretty much assume that a byte is 8 bits, but as
far as I know, the length of a short/long int is still not fixed.

Pat Fleckenstein (HoseNode)

unread,
Apr 18, 1994, 3:17:27 PM4/18/94
to
In article <2ou91o$j...@hydra.cs.hope.edu> kru...@cs.hope.edu writes:
>
>The ANSI standard did not fix the length of any of the integer data
>types. I don't think chars are even required to be 8 bits, because
>when they did the standard some machines had "bytes" of 7,9,10,etc.
>bits. Now you can pretty much assume that a byte is 8 bits, but as
>far as I know, the length of a short/long int is still not fixed.

char >= 8-bits
short >= char
int >= short
long >= int

double >= float

--
(add to /usr/share/misc/units.lib) ark 960000 cubit3
ship 1 ark
helen 1000 ship
picture 1000 word

Bryan Larsen

unread,
Apr 18, 1994, 10:54:45 PM4/18/94
to
p...@nick.csh.rit.edu (Pat Fleckenstein (HoseNode)) writes:

>In article <2ou91o$j...@hydra.cs.hope.edu> kru...@cs.hope.edu writes:
>>
>>The ANSI standard did not fix the length of any of the integer data
>>types. I don't think chars are even required to be 8 bits, because
>>when they did the standard some machines had "bytes" of 7,9,10,etc.
>>bits. Now you can pretty much assume that a byte is 8 bits, but as
>>far as I know, the length of a short/long int is still not fixed.

> char >= 8-bits
> short >= char
> int >= short
> long >= int

> double >= float
Yikes. I've always assumed:
short, int >= 16 bits,
long >= 32 bits.

Is this some sort of standard, or is it pseudo standard, or just plain
wrong?

Anybody know any exceptions?

Bryan
--
Bryan "EE Geek" Larsen lar...@cs.uregina.ca
"C" is that some programming language?

Zach Heilig

unread,
Apr 18, 1994, 11:00:04 PM4/18/94
to
In article <1994Apr18....@ultb.isc.rit.edu>,

Pat Fleckenstein (HoseNode) <p...@nick.csh.rit.edu> wrote:
|> char >= 8-bits
|> short >= char
|> int >= short
|> long >= int
|>
|> double >= float

more precisely:
short >= 16-bits.
long >= 32-bits.

the ratios Pat gave are correct though.
--
Zach Heilig (hei...@cs.und.nodak.edu) ==
(hei...@agassiz.cas.und.nodak.edu)

Bryan Larsen

unread,
Apr 18, 1994, 11:11:17 PM4/18/94
to
lar...@hercules.cs.uregina.ca (Bryan Larsen) writes:
>Bryan "EE Geek" Larsen lar...@cs.uregina.ca
>"C" is that some programming language?

Gheez. Leave a terminal alone to buy a bag of chips....

Bryan

Robert Reay

unread,
Apr 19, 1994, 1:24:36 AM4/19/94
to
In article <2ovhfk$g...@agassiz.cas.und.NoDak.edu> hei...@cs.UND.NoDak.Edu (Zach Heilig) writes:
>In article <1994Apr18....@ultb.isc.rit.edu>,
>Pat Fleckenstein (HoseNode) <p...@nick.csh.rit.edu> wrote:
>|> char >= 8-bits
>|> short >= char
>|> int >= short
>|> long >= int
>|>
>|> double >= float
>more precisely:
> short >= 16-bits.
> long >= 32-bits.

Actually ANSI c does not say this. It says only that


>|> short >= char
>|> int >= short

Now this has been true on all the systems I've worked on, but is not
garenteed to be true for all machines.

-Rob

I'm not even sure the spec says a char is >= 8 bits, but it wouldn't
suprise me.

--
gre...@mail.csh.rit.edu
"please Jesus, save Bob, please Jesus, please Jesus, please Jesus, save Bob."

Pat Fleckenstein (HoseNode)

unread,
Apr 19, 1994, 1:31:04 AM4/19/94
to
In article <2ovhfk$g...@agassiz.cas.und.NoDak.edu> hei...@cs.UND.NoDak.Edu (Zach Heilig) writes:
>more precisely:
> short >= 16-bits.
> long >= 32-bits.
>
>the ratios Pat gave are correct though.

Ah, 'tis true. Never read 'The New Testament' thoroughly, but
I don't recall that restriction in the First Edition. But,
while not worded greatly, both of those are specified in Chapter
2.2 of K&R. Thanks for the update.

alter,
pat
--
It can be explained by calculus but I really can't do that myself.
-- lack...@student.msu.edu (Daniel Lackner)
this makes much more sense to me, regardless of if its correct...
-- lam...@u.washington.edu (Lamont Granquist)

James Ojaste

unread,
Apr 19, 1994, 8:29:09 AM4/19/94
to
In article <2ou91o$j...@hydra.cs.hope.edu>, kru...@cs.hope.edu (John Krueger) writes:
|> In article A...@cid.aes.doe.ca, oja...@devw751.ice.ncr.doe.ca (James Ojaste) writes:
|> >In article <2oj6md$g...@hebron.connected.com>, coh...@hebron.connected.com (A cohort's CoHort) writes:
|> >|> From radians to our degrees, the scales vary far and wide. I would
|> >|> suspect that the reason 0-255 is used is because it fits in a short (8-bit)
|> >|> int. It really doesn't matter what you use in YOUR routines, as long as
|> >
|> >Yikes! 8 bits is a byte - a short int is 16 bits. A long int is 32 bits.
|>
|> The ANSI standard did not fix the length of any of the integer data
|> types. I don't think chars are even required to be 8 bits, because
|> when they did the standard some machines had "bytes" of 7,9,10,etc.
|> bits. Now you can pretty much assume that a byte is 8 bits, but as
|> far as I know, the length of a short/long int is still not fixed.

I've never had the opportunity to work with a machine that didn't have 8-bit bytes,
or 16-bit shorts or 32-bit longs (although int toggles back and forth between 16
and 32 bits quite often). I hope I never have to.

Besides, this is rec.games.programmer. How many people have PCs (that's personal
computers, not IBM clones) that use non-8-bit bytes and non-16-bit shorts?

Personally, I don't care what ANSI says - I tend to go by the de facto standard.
There are too many "standards" out there otherwise.

Pat Fleckenstein (HoseNode)

unread,
Apr 19, 1994, 4:02:08 PM4/19/94
to
In article <1994Apr19.0...@sue.cc.uregina.ca> lar...@hercules.cs.uregina.ca (Bryan Larsen) writes:
>p...@nick.csh.rit.edu (Pat Fleckenstein (HoseNode)) writes:
>
>>In article <2ou91o$j...@hydra.cs.hope.edu> kru...@cs.hope.edu writes:
>>>The ANSI standard did not fix the length of any of the integer data
>>>types.
>
>Is this some sort of standard, or is it pseudo standard, or just plain
>wrong?


Ok. p. 36 of 'The Second Edition: The C [ANSI-C] Programming
Language' by Kernighan and Ritchie, chapter 2.2 Data types and
sizes:

[violation of copyright laws on]

There are only a few basic data types in C:
'char' a single byte, capable of holding one character
in the local character set.
'int' an integer, typically reflecting the natural size
of integers on the host machine.
'float' single-precision floating point.
'double' double-precision floating point.

In addition, there are a number of qualifiers that can be applied to
thses basic types. 'short' and 'long' apply to integers:

short int sh;
long int counter;

The word 'int' can be omitted in such declarations, and typically is.

The intend is that 'short' and 'long' should provide different lengths
of integers where practical; 'int' will norrmally be the natural size
for a particular machine. 'short' is often 16 bits, 'long' 32 bits,
and 'int' either 16 or 32 bits. Each compiler is free to choose
appropriate sizes for its own hardware, subject only to the
restriction that 'short's and 'int's are at least 16 bits, 'long's are
at least 32 bits, and 'short' is no longer than 'int', which is no
longer than 'long'.

[violation of copyright laws off]

I don't have a copy of 'The First Edition' (Old Testament) around
to verify my memory that the bit sizes weren't in the last sentence
of that paragraph. But, my memory has done such things before.

Looking at it again, it doesn't really say 'char' has to be at least
8-bit, but I wouldn't want to see what would happen to 98% of the
software written today if 'char' dropped to 6 or 7 bits.

And, for those skeptical on gods' word.... This from 'The C++
Programming Language: The Second Edition' by Stroustrup, Section
2.3.1. Fundamental Types:

[violation of copyright laws reconvened]

... This is what is gauranteed about sizes of the fundamental types:
1 = sizeof(char) <= sizeof(short) <= sizeof(int) <= sizeof(long)

sizeof(float) <= sizeof(double) <= sizeof(long double)

sizeof(I) = sizeof(signed I) = sizeof(unsigned I)

where I can be 'char', 'short', 'int', or 'long'. In addition, it is
gauranteed that a 'char' has at least 8 bits, a 'short' at least 16
bits, and a 'long' at least 32 bits. A 'char' can hold a character
of the machine's character set. This means that it is usually safe to
assume that a 'char' can hold integers in the rang 0..127. Assuming
more is hazardous.

[violation of copyright laws off]

So, even though Bjarne gaurantees us 8 bits in C++, he seems reticent
to tell us we can use the 8-th. Alas, know your compilers for they
have the final say.

Zach Heilig

unread,
Apr 20, 1994, 3:53:42 AM4/20/94
to
In article <1994Apr19.0...@ultb.isc.rit.edu>,

Robert Reay <gre...@nick.csh.rit.edu> wrote:
>Actually ANSI c does not say this. It says only that
>>|> short >= char
>>|> int >= short
>Now this has been true on all the systems I've worked on, but is not
>garenteed to be true for all machines.
>
>I'm not even sure the spec says a char is >= 8 bits, but it wouldn't
>suprise me.

[ very anal retentive mode on ]

Hmm. You seem to have caught me here, but I do have some ammunition to
back me up, the ANSI spec gives ranges for the various data types, not
bit lengths, so here they are (minimum ranges, that is):

unsigned char : 0 : 255
signed char : -127 : 127
unsigned short: 0 : 65 535
signed short : -32 767 : 32 767
unsigned int : 0 : 65 535
signed int : -32 767 : 32 767
unsigned long : 0 : 4 294 967 295
signed long : -2 147 483 647 : 2 147 483 647

(note that the ranges are symetrical, so C could be implemented on a
one's complement architecture)

and the data type sizes I gave are the smallest number of bits that
will hold those ranges on a binary two's complement machine.

[ very anal retentive mode off ]

I'm still not sure if I'm agreeing or disagreeing with you :-).

Bryan Liles

unread,
Apr 21, 1994, 1:58:13 PM4/21/94
to

bmc...@vaxc.stevens-tech.edu wrote:

: i think by "most programmers" you mean "most vectorball demo programmers"..

Hey I resemble that comment! Are you saying that I'm doing something
wrong in my demos?

0 new messages