Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #19527 > unrolled thread
| Started by | Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> |
|---|---|
| First post | 2013-02-07 22:51 +0100 |
| Last post | 2013-02-10 00:06 -0500 |
| Articles | 20 on this page of 144 — 25 participants |
Back to article view | Back to comp.lang.forth
3D-graphics calculations using integers? Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-02-07 22:51 +0100
Re: 3D-graphics calculations using integers? "Paul E. Bennett" <Paul_E.Bennett@topmail.co.uk> - 2013-02-07 22:08 +0000
Re: 3D-graphics calculations using integers? AKE <assadebrahim2000@gmail.com> - 2013-02-07 14:32 -0800
Re: 3D-graphics calculations using integers? Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-02-07 23:40 +0100
Re: 3D-graphics calculations using integers? AKE <assadebrahim2000@gmail.com> - 2013-02-07 17:06 -0800
Re: 3D-graphics calculations using integers? AKE <assadebrahim2000@gmail.com> - 2013-02-07 17:07 -0800
Re: 3D-graphics calculations using integers? Pablo Hugo Reda <pabloreda@gmail.com> - 2013-02-07 14:36 -0800
Re: 3D-graphics calculations using integers? Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-02-07 23:46 +0100
Re: 3D-graphics calculations using integers? "Elizabeth D. Rather" <erather@forth.com> - 2013-02-07 16:38 -1000
Re: 3D-graphics calculations using integers? Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-02-08 10:22 +0100
Re: 3D-graphics calculations using integers? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-02-08 10:26 +0000
Re: 3D-graphics calculations using integers? "Elizabeth D. Rather" <erather@forth.com> - 2013-02-07 12:50 -1000
Re: 3D-graphics calculations using integers? Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-02-08 00:15 +0100
Re: 3D-graphics calculations using integers? kenney@cix.compulink.co.uk - 2013-02-08 14:51 -0600
Re: 3D-graphics calculations using integers? Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-02-08 22:02 +0100
Re: 3D-graphics calculations using integers? rickman <gnuarm@gmail.com> - 2013-02-07 18:21 -0500
Re: 3D-graphics calculations using integers? Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-02-08 00:30 +0100
Re: 3D-graphics calculations using integers? Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-02-08 00:39 +0100
Re: 3D-graphics calculations using integers? rickman <gnuarm@gmail.com> - 2013-02-07 18:51 -0500
Re: 3D-graphics calculations using integers? Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-02-08 12:28 +0100
Re: 3D-graphics calculations using integers? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-02-08 12:25 +0000
Re: 3D-graphics calculations using integers? Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-02-08 22:04 +0100
Re: 3D-graphics calculations using integers? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-02-09 15:27 +0000
Re: 3D-graphics calculations using integers? Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-02-09 16:36 +0100
Re: 3D-graphics calculations using integers? Mark Wills <forthfreak@gmail.com> - 2013-02-08 05:01 -0800
Re: 3D-graphics calculations using integers? Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-02-08 21:58 +0100
Re: 3D-graphics calculations using integers? Roberto Waltman <usenet@rwaltman.com> - 2013-02-08 10:08 -0500
Re: 3D-graphics calculations using integers? Roberto Waltman <usenet@rwaltman.com> - 2013-02-08 10:11 -0500
Re: 3D-graphics calculations using integers? Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-02-08 22:05 +0100
Re: 3D-graphics calculations using integers? Pablo Hugo Reda <pabloreda@gmail.com> - 2013-02-08 08:29 -0800
Re: 3D-graphics calculations using integers? Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-02-08 18:48 +0100
Re: 3D-graphics calculations using integers? rickman <gnuarm@gmail.com> - 2013-02-08 17:20 -0500
Re: 3D-graphics calculations using integers? Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-02-08 23:32 +0100
Re: 3D-graphics calculations using integers? rickman <gnuarm@gmail.com> - 2013-02-09 23:57 -0500
Re: 3D-graphics calculations using integers? "Elizabeth D. Rather" <erather@forth.com> - 2013-02-08 15:02 -1000
Re: 3D-graphics calculations using integers? Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-02-09 02:24 +0100
Re: 3D-graphics calculations using integers? "Elizabeth D. Rather" <erather@forth.com> - 2013-02-08 15:58 -1000
Re: 3D-graphics calculations using integers? Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-02-09 16:43 +0100
Re: 3D-graphics calculations using integers? "Elizabeth D. Rather" <erather@forth.com> - 2013-02-09 10:03 -1000
Re: 3D-graphics calculations using integers? "Ed" <invalid@nospam.com> - 2013-02-10 11:35 +1100
Re: 3D-graphics calculations using integers? humptydumpty <ouatubi@gmail.com> - 2013-02-08 23:48 -0800
Re: 3D-graphics calculations using integers? Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-02-09 16:37 +0100
OT: ANS Forth Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-02-09 17:27 +0100
Re: OT: ANS Forth "Elizabeth D. Rather" <erather@forth.com> - 2013-02-09 10:06 -1000
Re: OT: ANS Forth Paul Rubin <no.email@nospam.invalid> - 2013-02-09 12:26 -0800
Re: OT: ANS Forth Elizabeth D Rather <erather@forth.com> - 2013-02-09 14:38 -1000
Re: OT: ANS Forth "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2013-02-22 12:52 -0500
Re: OT: ANS Forth "Elizabeth D. Rather" <erather@forth.com> - 2013-02-22 09:25 -1000
Re: OT: ANS Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-02-10 08:15 -0600
Re: OT: ANS Forth Paul Rubin <no.email@nospam.invalid> - 2013-02-10 23:34 -0800
Re: OT: ANS Forth Josh Grams <josh@qualdan.com> - 2013-02-11 22:14 +0000
Re: OT: ANS Forth "Elizabeth D. Rather" <erather@forth.com> - 2013-02-11 13:34 -1000
Re: OT: ANS Forth "Ed" <invalid@nospam.com> - 2013-02-11 11:52 +1100
Re: OT: ANS Forth Paul Rubin <no.email@nospam.invalid> - 2013-02-10 17:11 -0800
Re: OT: ANS Forth "Elizabeth D. Rather" <erather@forth.com> - 2013-02-10 22:06 -1000
Re: OT: ANS Forth "Charles Childers" <crc@retroforth.org> - 2013-02-11 17:17 -0500
Re: OT: ANS Forth "Ed" <invalid@nospam.com> - 2013-02-13 11:42 +1100
Re: OT: ANS Forth "Elizabeth D. Rather" <erather@forth.com> - 2013-02-12 16:07 -1000
Re: OT: ANS Forth "Ed" <invalid@nospam.com> - 2013-02-15 09:42 +1100
Re: OT: ANS Forth Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-02-15 00:16 +0100
Re: OT: ANS Forth "Ed" <invalid@nospam.com> - 2013-02-17 16:05 +1100
Re: OT: ANS Forth Howerd <howerdo@yahoo.co.uk> - 2013-02-17 04:16 -0800
Re: OT: ANS Forth albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-02-17 13:12 +0000
Re: OT: ANS Forth Howerd <howerdo@yahoo.co.uk> - 2013-02-17 09:15 -0800
Re: OT: ANS Forth Brad Eckert <hwfwguy@gmail.com> - 2013-02-19 09:35 -0800
Re: OT: ANS Forth Andy Valencia <user@vsta.org> - 2013-02-19 19:25 +0000
Re: OT: ANS Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-02-19 15:35 -0600
Re: OT: ANS Forth Paul Rubin <no.email@nospam.invalid> - 2013-02-21 00:37 -0800
Re: OT: ANS Forth "Elizabeth D. Rather" <erather@forth.com> - 2013-02-20 23:07 -1000
Re: OT: ANS Forth Paul Rubin <no.email@nospam.invalid> - 2013-02-21 01:38 -0800
Re: OT: ANS Forth "Elizabeth D. Rather" <erather@forth.com> - 2013-02-21 08:50 -1000
Re: OT: ANS Forth Paul Rubin <no.email@nospam.invalid> - 2013-02-23 15:44 -0800
Re: OT: ANS Forth albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-02-24 03:41 +0000
Re: OT: ANS Forth Paul Rubin <no.email@nospam.invalid> - 2013-02-23 20:00 -0800
Re: OT: ANS Forth stephenXXX@mpeforth.com (Stephen Pelc) - 2013-02-24 13:49 +0000
Re: OT: ANS Forth albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-02-24 15:04 +0000
Re: OT: ANS Forth Paul Rubin <no.email@nospam.invalid> - 2013-02-24 14:52 -0800
Re: OT: ANS Forth albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-02-24 23:51 +0000
Re: OT: ANS Forth Paul Rubin <no.email@nospam.invalid> - 2013-02-24 16:23 -0800
Re: OT: ANS Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-02-21 03:55 -0600
Re: OT: ANS Forth "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2013-02-22 13:01 -0500
Re: OT: ANS Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-02-22 12:26 -0600
Re: OT: ANS Forth Andy Valencia <user@vsta.org> - 2013-02-19 21:54 +0000
Re: OT: ANS Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-02-19 18:21 -0600
Re: OT: ANS Forth Brad Eckert <hwfwguy@gmail.com> - 2013-02-20 08:45 -0800
Re: OT: ANS Forth Paul Rubin <no.email@nospam.invalid> - 2013-02-20 11:01 -0800
Re: OT: ANS Forth "Elizabeth D. Rather" <erather@forth.com> - 2013-02-20 11:25 -1000
Re: OT: ANS Forth Paul Rubin <no.email@nospam.invalid> - 2013-02-21 00:22 -0800
Re: OT: ANS Forth "Elizabeth D. Rather" <erather@forth.com> - 2013-02-20 22:50 -1000
Re: OT: ANS Forth Paul Rubin <no.email@nospam.invalid> - 2013-02-21 01:08 -0800
Re: OT: ANS Forth albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-02-21 12:42 +0000
Re: OT: ANS Forth Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-21 13:50 +0100
Re: OT: ANS Forth Paul Rubin <no.email@nospam.invalid> - 2013-02-21 09:36 -0800
Re: OT: ANS Forth Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-22 01:32 +0100
Re: OT: ANS Forth Paul Rubin <no.email@nospam.invalid> - 2013-02-23 00:50 -0800
Re: OT: ANS Forth Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-24 03:03 +0100
Re: OT: ANS Forth Brad Eckert <hwfwguy@gmail.com> - 2013-02-21 09:12 -0800
Re: OT: ANS Forth Paul Rubin <no.email@nospam.invalid> - 2013-02-23 00:38 -0800
Re: OT: ANS Forth "Elizabeth D. Rather" <erather@forth.com> - 2013-02-21 09:01 -1000
Re: OT: ANS Forth mhx@iae.nl (Marcel Hendrix) - 2013-02-22 00:05 +0200
Re: OT: ANS Forth Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-21 13:24 +0100
Re: OT: ANS Forth Paul Rubin <no.email@nospam.invalid> - 2013-02-21 09:33 -0800
Re: OT: ANS Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-02-21 13:04 -0600
Re: OT: ANS Forth Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-22 01:41 +0100
Re: OT: ANS Forth Paul Rubin <no.email@nospam.invalid> - 2013-02-23 00:31 -0800
Re: OT: ANS Forth "Paul E. Bennett" <Paul_E.Bennett@topmail.co.uk> - 2013-02-23 09:15 +0000
Re: OT: ANS Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-02-23 04:33 -0600
Re: OT: ANS Forth albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-02-23 13:49 +0000
Re: OT: ANS Forth Roberto Waltman <usenet@rwaltman.com> - 2013-02-23 13:35 -0500
Re: OT: ANS Forth Roberto Waltman <usenet@rwaltman.com> - 2013-02-23 13:46 -0500
Re: OT: ANS Forth Paul Rubin <no.email@nospam.invalid> - 2013-02-23 15:26 -0800
Re: OT: ANS Forth Roberto Waltman <usenet@rwaltman.com> - 2013-02-24 09:41 -0500
Re: OT: ANS Forth "Elizabeth D. Rather" <erather@forth.com> - 2013-02-21 09:09 -1000
Re: OT: ANS Forth Paul Rubin <no.email@nospam.invalid> - 2013-02-23 00:37 -0800
Re: OT: ANS Forth albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-02-23 13:57 +0000
Re: OT: ANS Forth "Elizabeth D. Rather" <erather@forth.com> - 2013-02-23 08:47 -1000
Re: OT: ANS Forth Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-22 01:27 +0100
Re: OT: ANS Forth Paul Rubin <no.email@nospam.invalid> - 2013-02-23 00:16 -0800
Re: OT: ANS Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-02-23 04:36 -0600
Re: OT: ANS Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-02-23 16:52 +0000
Re: OT: ANS Forth Paul Rubin <no.email@nospam.invalid> - 2013-02-23 12:39 -0800
Re: OT: ANS Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-02-25 16:27 +0000
Re: OT: ANS Forth "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2013-02-23 18:08 -0500
Re: OT: ANS Forth Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-24 02:20 +0100
Re: OT: ANS Forth Paul Rubin <no.email@nospam.invalid> - 2013-02-24 20:16 -0800
Re: OT: ANS Forth Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-25 16:04 +0100
Re: OT: ANS Forth albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-02-25 17:12 +0000
Re: OT: ANS Forth Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-25 20:44 +0100
Re: OT: ANS Forth Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-25 16:45 +0100
Re: OT: ANS Forth Andy Valencia <user@vsta.org> - 2013-02-24 02:09 +0000
Re: OT: ANS Forth Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-24 04:03 +0100
Re: OT: ANS Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-02-25 17:58 +0000
Re: OT: ANS Forth Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-25 20:57 +0100
Re: OT: ANS Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-03-02 16:43 +0000
Re: OT: ANS Forth Bernd Paysan <bernd.paysan@gmx.de> - 2013-03-02 18:14 +0100
Re: OT: ANS Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-03-03 13:56 +0000
Re: OT: ANS Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-02-24 03:45 -0600
Re: OT: ANS Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-02-13 04:12 -0600
Re: OT: ANS Forth stephenXXX@mpeforth.com (Stephen Pelc) - 2013-02-13 12:24 +0000
Re: OT: ANS Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-02-11 14:41 +0000
Re: OT: ANS Forth Andy Valencia <user@vsta.org> - 2013-02-11 19:44 +0000
Re: OT: ANS Forth albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-02-11 21:14 +0000
Re: 3D-graphics calculations using integers? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-02-09 18:14 -0600
Re: 3D-graphics calculations using integers? rickman <gnuarm@gmail.com> - 2013-02-10 00:06 -0500
Page 1 of 8 [1] 2 3 4 5 6 7 8 Next page →
| From | Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> |
|---|---|
| Date | 2013-02-07 22:51 +0100 |
| Subject | 3D-graphics calculations using integers? |
| Message-ID | <slrnkh8c16.67i.zbigniew2011REMOVE@Tichy.myhome.org> |
I would to create a program - kind of 3D-graphics demo - and for learning purposes I would to use integer calculation, but the more I think about it, the more it seems, that using floating point would be much easier. Well, maybe someone of you know, what I'm missing(?), and could make a tip. The problem is, that performing matrix calculations I should expect fractional values sometimes, and actually got no idea, how to keep the fractions convenient way. For example: if I'm going to calculate a result of 323423424234 5674545 /MOD I've got a 56995 and the rest 2731959 The rest itself isn't enough; to have entire fraction I've got to keep also the denominator - then instead of 1 cell, actually for each value I should reserve even 3 cells, just to keep the fractional part in 2nd and 3rd cell. Since Forth was very commonly used - or maybe I should write "is" - exactly for graphics purposes, I'm pretty sure, that I'm not the first one facing such kind of problem. Does there exist a convenient way using integers - or really should I switch to floating point calculations for this? -- It's us, the scobs.
[toc] | [next] | [standalone]
| From | "Paul E. Bennett" <Paul_E.Bennett@topmail.co.uk> |
|---|---|
| Date | 2013-02-07 22:08 +0000 |
| Message-ID | <anin3bFhp5tU1@mid.individual.net> |
| In reply to | #19527 |
Zbiggy wrote: > I would to create a program - kind of 3D-graphics demo - and for learning > purposes I would to use integer calculation, but the more I think about > it, the more it seems, that using floating point would be much easier. > Well, maybe someone of you know, what I'm missing(?), and could make a > tip. > > The problem is, that performing matrix calculations I should expect > fractional values sometimes, and actually got no idea, how to keep the > fractions convenient way. For example: if I'm going to calculate a result > of > > 323423424234 5674545 /MOD > > I've got a 56995 and the rest 2731959 > The rest itself isn't enough; to have entire fraction I've got to keep > also the denominator - then instead of 1 cell, actually for each value I > should reserve even 3 cells, just to keep the fractional part in 2nd and > 3rd cell. > > Since Forth was very commonly used - or maybe I should write "is" - > exactly for graphics purposes, I'm pretty sure, that I'm not the first one > facing such kind of problem. Does there exist a convenient way using > integers - or really should I switch to floating point calculations for > this? At one of the EuroForml conference I recall that one of the (French?) delegates submitted a paper about performing such calculations for a CAD programme in Forth. It would be worth a browse through the proceedings (assuming that that particular year has been scanned and up-loaded). -- ******************************************************************** Paul E. Bennett...............<email://Paul_E.Bennett@topmail.co.uk> Forth based HIDECS Consultancy Mob: +44 (0)7811-639972 Tel: +44 (0)1235-510979 Going Forth Safely ..... EBA. www.electric-boat-association.org.uk.. ********************************************************************
[toc] | [prev] | [next] | [standalone]
| From | AKE <assadebrahim2000@gmail.com> |
|---|---|
| Date | 2013-02-07 14:32 -0800 |
| Message-ID | <83aa8443-eb9b-482b-8582-5a680a833d4c@googlegroups.com> |
| In reply to | #19527 |
On Thursday, February 7, 2013 9:51:34 PM UTC, Zbiggy wrote: > I would to create a program - kind of 3D-graphics demo - and for learning > > purposes I would to use integer calculation, but the more I think about it, > > the more it seems, that using floating point would be much easier. Well, > > maybe someone of you know, what I'm missing(?), and could make a tip. > > > > The problem is, that performing matrix calculations I should expect > > fractional values sometimes, and actually got no idea, how to keep the > > fractions convenient way. For example: if I'm going to calculate a result of > > > > 323423424234 5674545 /MOD > > > > I've got a 56995 and the rest 2731959 > > The rest itself isn't enough; to have entire fraction I've got to keep also > > the denominator - then instead of 1 cell, actually for each value I should > > reserve even 3 cells, just to keep the fractional part in 2nd and 3rd cell. > > > > Since Forth was very commonly used - or maybe I should write "is" - exactly > > for graphics purposes, I'm pretty sure, that I'm not the first one facing > > such kind of problem. Does there exist a convenient way using integers - or > > really should I switch to floating point calculations for this? > > -- > > It's us, the scobs. Why not used fixed point arithmetic with rounding? This can work quite well if you know that the values in your problem are bounded. You would be using the */ operator which automatically expands the multiplication to a double word and then chops it back down to a single word using the divisor you specify. For a simple example (without rounding): If we want 3.14 * 2.99 to two decimal places, we would have: 314 299 100 */ This gives 938, which is 9.38 to two decimal places. The exact answer is 9.3886, so this is correct up to TRUNCATION. Now the problem with truncation is that any iterative method will start to accumulate truncation error very quickly. So in this case you use */ to truncate leaving one EXTRA digit, and then you use a rounding rule to deal with the final digit. That brings down your error accumulation to one associated with rounding. You pick how many places you want to carry based upon your tolerance for error.
[toc] | [prev] | [next] | [standalone]
| From | Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> |
|---|---|
| Date | 2013-02-07 23:40 +0100 |
| Message-ID | <slrnkh8esk.92c.zbigniew2011REMOVE@Tichy.myhome.org> |
| In reply to | #19529 |
In comp.lang.forth, AKE wrote: > Why not used fixed point arithmetic with rounding? This can work quite > well if you know that the values in your problem are bounded. The problem is, it's not always just a matter of "100 /" - I did such calculations in TCL before, and the fractions can be long; say 10 numbers after decimal dot, or so. Rounding them each time means adding still more and more distortion, if - for example - you're moving any 3D corpse around, while rotating it during movement (say, it's a sattellite of Earth, or something like that). I didn't mean just a typical coordinates of the screen - say 800x600 - but moving around in "virtual world" with dimensions sized as multiple of this. Like 80000 dots each dimension, or more. -- It's us, the scobs.
[toc] | [prev] | [next] | [standalone]
| From | AKE <assadebrahim2000@gmail.com> |
|---|---|
| Date | 2013-02-07 17:06 -0800 |
| Message-ID | <9cadc1b8-f033-4e6b-8360-6ff990db6756@googlegroups.com> |
| In reply to | #19531 |
On Thursday, February 7, 2013 10:40:20 PM UTC, Zbiggy wrote: > In comp.lang.forth, AKE wrote: > > > > > Why not used fixed point arithmetic with rounding? This can work quite > > > well if you know that the values in your problem are bounded. > > > > The problem is, it's not always just a matter of "100 /" - I did such > > calculations in TCL before, and the fractions can be long; say 10 numbers > > after decimal dot, or so. Rounding them each time means adding still more > > and more distortion, if - for example - you're moving any 3D corpse around, > > while rotating it during movement (say, it's a sattellite of Earth, or > > something like that). > > > > I didn't mean just a typical coordinates of the screen - say 800x600 - but > > moving around in "virtual world" with dimensions sized as multiple of this. > > Like 80000 dots each dimension, or more. > > -- > > It's us, the scobs. This is where a 'good' rounding rule shines. I usually use parity rounding, so check the last bit, and if it is set, round up; round down in unset. In this way, odd fixed point integers are rounded up, while evens are rounded down. The random distribution of evens and odds in most computations means that your error accumulation is low. This is preferable to the usual round up after 5 rule since here biases tend to accumulate.
[toc] | [prev] | [next] | [standalone]
| From | AKE <assadebrahim2000@gmail.com> |
|---|---|
| Date | 2013-02-07 17:07 -0800 |
| Message-ID | <06256cc0-3515-4691-b056-1630d44215ec@googlegroups.com> |
| In reply to | #19531 |
On Thursday, February 7, 2013 10:40:20 PM UTC, Zbiggy wrote: > In comp.lang.forth, AKE wrote: > > > > > Why not used fixed point arithmetic with rounding? This can work quite > > > well if you know that the values in your problem are bounded. > > > > The problem is, it's not always just a matter of "100 /" - I did such > > calculations in TCL before, and the fractions can be long; say 10 numbers > > after decimal dot, or so. Rounding them each time means adding still more > > and more distortion, if - for example - you're moving any 3D corpse around, > > while rotating it during movement (say, it's a sattellite of Earth, or > > something like that). > > > > I didn't mean just a typical coordinates of the screen - say 800x600 - but > > moving around in "virtual world" with dimensions sized as multiple of this. > > Like 80000 dots each dimension, or more. > > -- > > It's us, the scobs. This is where a 'good' rounding rule shines. I usually use parity rounding, so check the last bit, and if it is set, round up; round down in unset. In this way, odd fixed point integers are rounded up, while evens are rounded down. The random distribution of evens and odds in most computations means that your error accumulation is low. This is preferable to the usual round up after 5 rule since here biases tend to accumulate.
[toc] | [prev] | [next] | [standalone]
| From | Pablo Hugo Reda <pabloreda@gmail.com> |
|---|---|
| Date | 2013-02-07 14:36 -0800 |
| Message-ID | <9e137ba3-0354-42bf-a992-98dd01c69458@googlegroups.com> |
| In reply to | #19527 |
El jueves, 7 de febrero de 2013 18:51:34 UTC-3, Zbiggy escribió: > I would to create a program - kind of 3D-graphics demo - and for learning > > purposes I would to use integer calculation, but the more I think about it, > > the more it seems, that using floating point would be much easier. Well, > > maybe someone of you know, what I'm missing(?), and could make a tip. > > > > The problem is, that performing matrix calculations I should expect > > fractional values sometimes, and actually got no idea, how to keep the > > fractions convenient way. For example: if I'm going to calculate a result of > > > > 323423424234 5674545 /MOD > > > > I've got a 56995 and the rest 2731959 > > The rest itself isn't enough; to have entire fraction I've got to keep also > > the denominator - then instead of 1 cell, actually for each value I should > > reserve even 3 cells, just to keep the fractional part in 2nd and 3rd cell. > > > > Since Forth was very commonly used - or maybe I should write "is" - exactly > > for graphics purposes, I'm pretty sure, that I'm not the first one facing > > such kind of problem. Does there exist a convenient way using integers - or > > really should I switch to floating point calculations for this? > > -- > > It's us, the scobs. I use fixed point for 3d graphics, work very well. I use 32 bits integer then use 16 bits por integer part and 16 bits for fractional..one cell for number.
[toc] | [prev] | [next] | [standalone]
| From | Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> |
|---|---|
| Date | 2013-02-07 23:46 +0100 |
| Message-ID | <slrnkh8f7g.92c.zbigniew2011REMOVE@Tichy.myhome.org> |
| In reply to | #19530 |
In comp.lang.forth, Pablo Hugo Reda wrote: > I use fixed point for 3d graphics, work very well. > I use 32 bits integer then use 16 bits por integer part and 16 bits for > fractional..one cell for number. But how do you represent the fraction? Not as "simple fraction"? The second problem is: I'm going to use DX-Forth for DOS. Therefore I won't have 32 bits cells. -- It's us, the scobs.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2013-02-07 16:38 -1000 |
| Message-ID | <wdadnTKsmLLe-InMnZ2dnUVZ_vSdnZ2d@supernews.com> |
| In reply to | #19532 |
On 2/7/13 12:46 PM, Zbiggy wrote: > In comp.lang.forth, Pablo Hugo Reda wrote: > >> I use fixed point for 3d graphics, work very well. >> I use 32 bits integer then use 16 bits por integer part and 16 bits for >> fractional..one cell for number. > > But how do you represent the fraction? Not as "simple fraction"? > > The second problem is: I'm going to use DX-Forth for DOS. Therefore I won't > have 32 bits cells. > What's a "fraction"? Your application has a certain intrinsic level of accuracy in its original data. For example, if your measurements are accurate to 1 mm then you can work in tenths of millimeters. Just don't think of them as "fractions of a meter", although you may represent them that way on the screen or page. When you do an operation in floating point, you can represent the result with many decimal places. but that doesn't mean your numbers are actual accurate to all those decimal places. It behooves all of us to keep track of how much real resolution we have on our numbers. And why can't you use a Forth that has the facilities you need? Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
| From | Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> |
|---|---|
| Date | 2013-02-08 10:22 +0100 |
| Message-ID | <slrnkh9kga.22m.zbigniew2011REMOVE@Tichy.myhome.org> |
| In reply to | #19542 |
In comp.lang.forth, Elizabeth D. Rather wrote: > What's a "fraction"? Well, something like this: 345 ----- 72384 If I'm correct, it's called "a fraction". > Your application has a certain intrinsic level of > accuracy in its original data. For example, if your measurements are > accurate to 1 mm then you can work in tenths of millimeters. Just don't > think of them as "fractions of a meter", although you may represent them > that way on the screen or page. No, actually, if it won't make the calculations too time-consuming (I would to make it work smoothly), I would to use "vulgar fractions", to make rounding only in the end - I mean during representation on 2D display, where I have to use integers anyway. > When you do an operation in floating point, you can represent the result > with many decimal places. but that doesn't mean your numbers are actual > accurate to all those decimal places. It behooves all of us to keep > track of how much real resolution we have on our numbers. > > And why can't you use a Forth that has the facilities you need? I don't know. I really can't? -- It's us, the scobs.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2013-02-08 10:26 +0000 |
| Message-ID | <2013Feb8.112615@mips.complang.tuwien.ac.at> |
| In reply to | #19532 |
Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> writes:
>The second problem is: I'm going to use DX-Forth for DOS. Therefore I won't
>have 32 bits cells.
Then, if DX-Forth supports 64+-bit FP, I suggest using it. It will be
faster on any moder CPU, and will probably be quite a bit easier to
program for the same result quality.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2013: http://www.euroforth.org/ef13/
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2013-02-07 12:50 -1000 |
| Message-ID | <xZGdnX8KxZ1csonMnZ2dnUVZ_jCdnZ2d@supernews.com> |
| In reply to | #19527 |
On 2/7/13 11:51 AM, Zbiggy wrote: > I would to create a program - kind of 3D-graphics demo - and for learning > purposes I would to use integer calculation, but the more I think about it, > the more it seems, that using floating point would be much easier. Well, > maybe someone of you know, what I'm missing(?), and could make a tip. > > The problem is, that performing matrix calculations I should expect > fractional values sometimes, and actually got no idea, how to keep the > fractions convenient way. For example: if I'm going to calculate a result of > > 323423424234 5674545 /MOD > > I've got a 56995 and the rest 2731959 > The rest itself isn't enough; to have entire fraction I've got to keep also > the denominator - then instead of 1 cell, actually for each value I should > reserve even 3 cells, just to keep the fractional part in 2nd and 3rd cell. > > Since Forth was very commonly used - or maybe I should write "is" - exactly > for graphics purposes, I'm pretty sure, that I'm not the first one facing > such kind of problem. Does there exist a convenient way using integers - or > really should I switch to floating point calculations for this? > I agree, scaled fixed-point is the way to go. FP introduces a lot of unnecessary noise bits. Also: by all means go ahead and use a bunch of integers, or (better still) a structure with things like image dimensions, window dimensions, scales, cursor position, etc. Don't fall into the trap of trying to keep a bunch of 3-vectors on the stack! And define a few primitives for common arithmetic operations. The ones I found helpful when I was doing this stuff included: V+ (add 2 vectors) V*/ (Multiply a vector by a ratio of scalers) Maybe more, I don't remember :-) Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
| From | Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> |
|---|---|
| Date | 2013-02-08 00:15 +0100 |
| Message-ID | <slrnkh8gun.aq6.zbigniew2011REMOVE@Tichy.myhome.org> |
| In reply to | #19533 |
In comp.lang.forth, Elizabeth D. Rather wrote: > Also: by all means go ahead and use a bunch of integers, or (better > still) a structure with things like image dimensions, window dimensions, > scales, cursor position, etc. Don't fall into the trap of trying to keep > a bunch of 3-vectors on the stack! > > And define a few primitives for common arithmetic operations. The ones I > found helpful when I was doing this stuff included: Then actually I should be prepared, it has to be that way (I mean: 9 cells of data for each dot/vector in 3D space), if I want accuracy - and concentrate on creating proper words for operating on such kind of data? -- It's us, the scobs.
[toc] | [prev] | [next] | [standalone]
| From | kenney@cix.compulink.co.uk |
|---|---|
| Date | 2013-02-08 14:51 -0600 |
| Message-ID | <m_6dnVJQotnQ-IjMnZ2dnUVZ8r6dnZ2d@giganews.com> |
| In reply to | #19534 |
In article <slrnkh8gun.aq6.zbigniew2011REMOVE@Tichy.myhome.org>, zbigniew2011REMOVE@gmail.REMOVE.com (Zbiggy) wrote: > Then actually I should be prepared, it has to be that way (I mean: 9 > cells of data for each dot/vector in 3D space) I am not sure exactly what you want to do but for wire frame graphics you only need x,y and z values. For a computer display this has to be transformed to a flat projection which is true but pixel positions on the screen are described by two integers. That is unless you use polar coordinates. Mind you this seems a lot of work to duplicate facilities that are already available. There are plenty of free ray tracing programs out there and at least one language that was designed for games writing with built in 3D and sprites. Ken Young
[toc] | [prev] | [next] | [standalone]
| From | Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> |
|---|---|
| Date | 2013-02-08 22:02 +0100 |
| Message-ID | <slrnkhath1.cu1.zbigniew2011REMOVE@Tichy.myhome.org> |
| In reply to | #19555 |
In comp.lang.forth, kenney@cix.compulink.co.uk wrote: > I am not sure exactly what you want to do but for wire frame graphics > you only need x,y and z values. For a computer display this has to be > transformed to a flat projection which is true but pixel positions on > the screen are described by two integers. That is unless you use polar > coordinates. Well, it's not only about displaying the static 3D corpse - but about real-time movement in 3D-space, with "active" NPCs. > Mind you this seems a lot of work to duplicate facilities that are > already available. There are plenty of free ray tracing programs out > there and at least one language that was designed for games writing with > built in 3D and sprites. Yes, I'm aware. Actually there are ready-to-use OpenGL functions, available in Gforth already - but the design mentioned it's another exercise for me. -- It's us, the scobs.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2013-02-07 18:21 -0500 |
| Message-ID | <kf1cu9$359$2@dont-email.me> |
| In reply to | #19527 |
On 2/7/2013 4:51 PM, Zbiggy wrote: > I would to create a program - kind of 3D-graphics demo - and for learning > purposes I would to use integer calculation, but the more I think about it, > the more it seems, that using floating point would be much easier. Well, > maybe someone of you know, what I'm missing(?), and could make a tip. > > The problem is, that performing matrix calculations I should expect > fractional values sometimes, and actually got no idea, how to keep the > fractions convenient way. For example: if I'm going to calculate a result of > > 323423424234 5674545 /MOD > > I've got a 56995 and the rest 2731959 > The rest itself isn't enough; to have entire fraction I've got to keep also > the denominator - then instead of 1 cell, actually for each value I should > reserve even 3 cells, just to keep the fractional part in 2nd and 3rd cell. > > Since Forth was very commonly used - or maybe I should write "is" - exactly > for graphics purposes, I'm pretty sure, that I'm not the first one facing > such kind of problem. Does there exist a convenient way using integers - or > really should I switch to floating point calculations for this? Hi Zbiggy, When I learned 3D graphics I was taught it was not such a good idea to perform repetitive calculations on the data for multiple transformations. Instead you can treat your transformations as a 4x4 matrix and multiply successive matrices for successive transformations to produce one matrix for the compound transformation. Then perhaps you don't need to retain the fractional part of your calculations. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> |
|---|---|
| Date | 2013-02-08 00:30 +0100 |
| Message-ID | <slrnkh8hr0.bdj.zbigniew2011REMOVE@Tichy.myhome.org> |
| In reply to | #19535 |
In comp.lang.forth, rickman wrote: > When I learned 3D graphics I was taught it was not such a good idea to > perform repetitive calculations on the data for multiple > transformations. Instead you can treat your transformations as a 4x4 > matrix and multiply successive matrices for successive transformations > to produce one matrix for the compound transformation. Then perhaps you > don't need to retain the fractional part of your calculations. You mean to use "homogeneous coordinates"? And in such coordinates I'm starting and ending always with integers? Must check it then - while there would be some more calculations to be done, but the data handling could be easier, if I hadn't to keep the fractions around. -- It's us, the scobs.
[toc] | [prev] | [next] | [standalone]
| From | Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> |
|---|---|
| Date | 2013-02-08 00:39 +0100 |
| Message-ID | <slrnkh8iat.br9.zbigniew2011REMOVE@Tichy.myhome.org> |
| In reply to | #19536 |
No, it's not going to save me from keeping the transitional values somewhere (I still mean matrix calculations). -- It's us, the scobs.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2013-02-07 18:51 -0500 |
| Message-ID | <kf1ela$m7h$3@dont-email.me> |
| In reply to | #19537 |
On 2/7/2013 6:39 PM, Zbiggy wrote: > No, it's not going to save me from keeping the transitional values somewhere > (I still mean matrix calculations). Do you need to retain perfect accuracy in your computations? If so, floating point won't work for you either. In fact, 32 bit floating point has fewer significant bits than 32 bit fixed point. You need to consider what your requirements are and then figure out what will meet them. Perfect accuracy in computations is not practical (or needed) for most apps including graphics. What exactly are you doing? Usually the data is only transformed to be displayed. As long as your data is accurate, the transform can be "good enough" for display. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> |
|---|---|
| Date | 2013-02-08 12:28 +0100 |
| Message-ID | <slrnkh9rsm.7ia.zbigniew2011REMOVE@Tichy.myhome.org> |
| In reply to | #19539 |
In comp.lang.forth, rickman wrote: > What exactly are you doing? Usually the data is only transformed to be > displayed. As long as your data is accurate, the transform can be "good > enough" for display. Yes, but when talking about compound calculation, pay attention, that rotation matrices use trigonometrical functions. How should I calculate sin, cos etc. without involving fractions? -- It's us, the scobs.
[toc] | [prev] | [next] | [standalone]
Page 1 of 8 [1] 2 3 4 5 6 7 8 Next page →
Back to top | Article view | comp.lang.forth
csiph-web