Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #53117 > unrolled thread
| Started by | josv@planet.nl |
|---|---|
| First post | 2016-12-06 03:40 -0800 |
| Last post | 2016-12-31 06:42 -0800 |
| Articles | 20 on this page of 149 — 25 participants |
Back to article view | Back to comp.lang.forth
f.) for Gorth josv@planet.nl - 2016-12-06 03:40 -0800
Re: f.) for Gorth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-12-06 15:48 +0100
Re: f.) for Gorth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-12-06 17:59 +0000
Re: f.) for Gorth josv@planet.nl - 2016-12-06 13:17 -0800
Re: f.) for Gorth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-12-07 11:11 +0000
Re: f.) for Gorth Julian Fondren <julian.fondren@gmail.com> - 2016-12-07 06:11 -0800
Re: f.) for Gorth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-12-07 17:50 +0000
Re: f.) for Gorth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-12-07 15:23 +0100
Re: f.) for Gorth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-12-08 16:18 +0000
Re: f.) for Gorth josv@planet.nl - 2016-12-07 06:46 -0800
Re: f.) for Gorth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-12-07 17:41 +0000
Re: f.) for Gorth hughaguilar96@gmail.com - 2016-12-06 10:34 -0800
Re: f.) for Gorth josv@planet.nl - 2016-12-09 12:11 -0800
Re: f.) for Gorth "HAA" <someone@microsoft.com> - 2016-12-23 13:23 +1100
Re: f.) for Gorth hughaguilar96@gmail.com - 2016-12-15 15:42 -0800
Re: f.) for Gorth "HAA" <someone@microsoft.com> - 2016-12-07 13:06 +1100
Re: f.) for Gorth hughaguilar96@gmail.com - 2016-12-06 18:32 -0800
Re: f.) for Gorth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-12-07 12:41 +0100
Re: f.) for Gorth hughaguilar96@gmail.com - 2016-12-07 19:49 -0800
Re: f.) for Gorth Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2016-12-08 08:12 +0000
Re: f.) for Gorth Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2016-12-08 18:53 -0500
Re: f.) for Gorth Alex <alex@rivadpm.com> - 2016-12-09 00:01 +0000
Re: f.) for Gorth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-12-09 12:17 +0100
Re: f.) for Gorth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-12-09 13:01 +0000
Re: f.) for Gorth "HAA" <someone@microsoft.com> - 2016-12-09 11:19 +1100
Re: f.) for Gorth hughaguilar96@gmail.com - 2016-12-08 22:23 -0800
Re: f.) for Gorth hughaguilar96@gmail.com - 2016-12-09 07:11 -0800
Re: f.) for Gorth hughaguilar96@gmail.com - 2016-12-20 22:40 -0800
Re: f.) for Gorth Julian Fondren <julian.fondren@gmail.com> - 2016-12-20 23:59 -0800
Re: f.) for Gorth hughaguilar96@gmail.com - 2016-12-21 21:17 -0800
Re: f.) for Gorth The Beez <the.beez.speaks@gmail.com> - 2016-12-13 08:51 -0800
Re: f.) for Gorth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-12-09 12:47 +0000
Re: f.) for Gorth "HAA" <someone@microsoft.com> - 2016-12-10 11:54 +1100
Re: f.) for Gorth hughaguilar96@gmail.com - 2016-12-09 17:28 -0800
Re: f.) for Gorth hughaguilar96@gmail.com - 2016-12-09 18:20 -0800
Re: f.) for Gorth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-12-10 14:26 +0000
Re: f.) for Gorth The Beez <the.beez.speaks@gmail.com> - 2016-12-13 09:14 -0800
Re: f.) for Gorth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-12-13 19:24 +0100
Re: f.) for Gorth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-12-14 07:29 -0600
Re: f.) for Gorth Hans Bezemer <the.beez.speaks@gmail.com> - 2016-12-14 18:29 +0100
Re: f.) for Gorth Julian Fondren <julian.fondren@gmail.com> - 2016-12-14 10:13 -0800
Re: f.) for Gorth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-12-15 03:45 -0600
Re: f.) for Gorth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-12-15 10:42 +0000
Re: f.) for Gorth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-12-15 05:11 -0600
Re: f.) for Gorth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-12-15 12:36 +0000
Re: f.) for Gorth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-12-15 07:33 -0600
Re: f.) for Gorth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-12-15 14:31 +0000
Re: f.) for Gorth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-12-15 14:34 -0600
Re: f.) for Gorth Paul Rubin <no.email@nospam.invalid> - 2016-12-15 16:20 -0800
Re: f.) for Gorth Julian Fondren <julian.fondren@gmail.com> - 2016-12-15 16:46 -0800
Re: f.) for Gorth Julian Fondren <julian.fondren@gmail.com> - 2016-12-17 09:23 -0800
Re: f.) for Gorth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-12-19 02:56 -0600
Re: f.) for Gorth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-12-16 08:10 +0000
Re: f.) for Gorth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-12-16 10:00 -0600
Re: f.) for Gorth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-12-18 10:32 +0000
Re: f.) for Gorth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-12-19 03:22 -0600
Re: f.) for Gorth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-12-16 14:14 +0100
Re: f.) for Gorth Bernd Paysan <bernd@net2o.de> - 2016-12-19 19:41 +0000
Re: f.) for Gorth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-12-20 03:02 -0600
Re: f.) for Gorth mhx@iae.nl - 2016-12-20 01:27 -0800
Re: f.) for Gorth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-12-20 12:35 +0000
Re: f.) for Gorth Charles Montgomery <cgm@physics.utoledo.edu> - 2016-12-20 21:23 -0500
Re: f.) for Gorth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-12-21 07:29 +0000
Re: f.) for Gorth Charles Montgomery <cgm@physics.utoledo.edu> - 2016-12-21 22:24 -0500
Re: f.) for Gorth "David N. Williams" <williams@umich.edu> - 2016-12-22 08:10 -0500
Re: f.) for Gorth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-12-22 17:39 +0000
Re: f.) for Gorth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-12-15 12:53 +0100
Re: f.) for Gorth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-12-15 05:59 -0600
Re: f.) for Gorth "Robert L." <No_spamming@noWhere_7073.org> - 2017-01-03 16:15 +0000
Re: f.) for Gorth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-12-14 17:06 +0000
Re: f.) for Gorth "HAA" <someone@microsoft.com> - 2016-12-18 10:58 +1100
Re: f.) for Gorth Paul Rubin <no.email@nospam.invalid> - 2016-12-17 17:26 -0800
Re: f.) for Gorth "HAA" <someone@microsoft.com> - 2016-12-19 13:16 +1100
Re: f.) for Gorth hughaguilar96@gmail.com - 2016-12-18 19:19 -0800
Re: f.) for Gorth john <anon@example.com> - 2016-12-19 11:03 +0000
Re: f.) for Gorth Mark Wills <markwills1970@gmail.com> - 2016-12-20 01:46 -0800
Re: f.) for Gorth john <anon@example.com> - 2016-12-20 12:14 +0000
Re: f.) for Gorth hughaguilar96@gmail.com - 2016-12-20 17:34 -0800
Re: f.) for Gorth Paul Rubin <no.email@nospam.invalid> - 2016-12-18 19:25 -0800
Re: f.) for Gorth hughaguilar96@gmail.com - 2016-12-18 19:45 -0800
Re: f.) for Gorth "HAA" <someone@microsoft.com> - 2016-12-22 11:32 +1100
Re: f.) for Gorth Bernd Paysan <bernd@net2o.de> - 2017-01-03 19:33 +0000
Re: f.) for Gorth hughaguilar96@gmail.com - 2017-01-03 22:13 -0800
Re: f.) for Gorth Alex <alex@rivadpm.com> - 2017-01-04 23:03 +0000
Re: f.) for Gorth hughaguilar96@gmail.com - 2017-01-06 22:52 -0800
Re: f.) for Gorth Alex <alex@rivadpm.com> - 2017-01-07 22:45 +0000
Re: f.) for Gorth hughaguilar96@gmail.com - 2017-01-07 17:23 -0800
Re: f.) for Gorth Alex <alex@rivadpm.com> - 2017-01-08 09:13 +0000
Re: f.) for Gorth hughaguilar96@gmail.com - 2017-01-08 17:10 -0800
Re: f.) for Gorth Alex <alex@rivadpm.com> - 2017-01-09 10:22 +0000
Re: f.) for Gorth stephen@mpeforth.com - 2017-01-08 07:00 -0800
Re: f.) for Gorth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-05-20 14:09 +0200
Re: f.) for Gorth Matthias Trute <matthias.trute@gmail.com> - 2017-01-11 01:14 -0800
Re: f.) for Gorth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-12-07 12:26 +0100
Re: f.) for Gorth "HAA" <someone@microsoft.com> - 2016-12-08 10:21 +1100
Re: f.) for Gorth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-12-20 15:45 +0100
Re: f.) for Gorth Alex <alex@rivadpm.com> - 2016-12-20 15:33 +0000
Re: f.) for Gorth "HAA" <someone@microsoft.com> - 2016-12-22 11:37 +1100
Re: f.) for Gorth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-12-22 14:19 +0100
Re: f.) for Gorth "HAA" <someone@microsoft.com> - 2016-12-23 12:11 +1100
Re: f.) for Gorth hughaguilar96@gmail.com - 2016-12-22 17:49 -0800
Re: f.) for Gorth "HAA" <someone@microsoft.com> - 2016-12-23 20:41 +1100
Re: f.) for Gorth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-05-20 14:21 +0200
Re: f.) for Gorth hughaguilar96@gmail.com - 2016-12-15 22:31 -0800
Re: f.) for Gorth hughaguilar96@gmail.com - 2016-12-16 18:26 -0800
Re: f.) for Gorth hughaguilar96@gmail.com - 2016-12-18 16:41 -0800
Re: f.) for Gorth stephen@mpeforth.com - 2016-12-20 02:20 -0800
Re: f.) for Gorth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-12-20 13:04 +0000
Re: f.) for Gorth hughaguilar96@gmail.com - 2016-12-20 17:27 -0800
Re: f.) for Gorth hughaguilar96@gmail.com - 2016-12-17 10:36 -0800
Re: f.) for Gorth Julian Fondren <julian.fondren@gmail.com> - 2016-12-17 11:51 -0800
Re: f.) for Gorth hughaguilar96@gmail.com - 2016-12-18 19:35 -0800
Re: f.) for Gorth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-12-19 14:17 +0100
Re: f.) for Gorth hughaguilar96@gmail.com - 2016-12-19 10:10 -0800
Re: f.) for Gorth Alex <alex@rivadpm.com> - 2016-12-19 20:33 +0000
Re: f.) for Gorth hughaguilar96@gmail.com - 2016-12-19 18:11 -0800
Re: f.) for Gorth Julian Fondren <julian.fondren@gmail.com> - 2016-12-19 19:03 -0800
Re: f.) for Gorth Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2016-12-20 08:10 +0000
Re: f.) for Gorth hughaguilar96@gmail.com - 2016-12-20 18:05 -0800
Re: f.) for Gorth - what is a number? Jan Coombs <jenfhaomndgfwutc@murmic.plus.com> - 2016-12-21 09:04 +0000
Re: f.) for Gorth Alex <alex@rivadpm.com> - 2016-12-20 15:26 +0000
Re: f.) for Gorth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-12-20 11:30 -0600
Language stds (was Re: f.) for Gorth) Alex <alex@rivadpm.com> - 2016-12-20 19:49 +0000
Re: Language stds (was Re: f.) for Gorth) john <anon@example.com> - 2016-12-20 20:06 +0000
Re: f.) for Gorth hughaguilar96@gmail.com - 2016-12-20 17:52 -0800
Re: f.) for Gorth Alex <alex@rivadpm.com> - 2016-12-21 13:47 +0000
Re: f.) for Gorth hughaguilar96@gmail.com - 2016-12-21 20:46 -0800
Re: f.) for Gorth Alex <alex@rivadpm.com> - 2016-12-22 14:33 +0000
Re: f.) for Gorth hughaguilar96@gmail.com - 2016-12-22 07:06 -0800
Re: f.) for Gorth Julian Fondren <julian.fondren@gmail.com> - 2016-12-22 07:21 -0800
Re: f.) for Gorth Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2016-12-23 07:41 +0000
Re: f.) for Gorth Alex <alex@rivadpm.com> - 2016-12-23 08:33 +0000
Re: f.) for Gorth hughaguilar96@gmail.com - 2016-12-23 18:22 -0800
Re: f.) for Gorth Julian Fondren <julian.fondren@gmail.com> - 2016-12-23 20:28 -0800
Re: f.) for Gorth hughaguilar96@gmail.com - 2016-12-26 18:30 -0800
Language stds (Re: f.) for Gorth) "HAA" <someone@microsoft.com> - 2016-12-24 12:12 +1100
Re: Language stds (Re: f.) for Gorth) Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-12-24 03:28 -0600
Re: Language stds (Re: f.) for Gorth) "Elizabeth D. Rather" <erather@forth.com> - 2016-12-24 10:02 -0600
Re: Language stds (Re: f.) for Gorth) hughaguilar96@gmail.com - 2016-12-24 16:13 -0800
Re: Language stds (Re: f.) for Gorth) Alex <alex@rivadpm.com> - 2016-12-24 18:13 +0000
Re: Language stds (Re: f.) for Gorth) "HAA" <someone@microsoft.com> - 2016-12-28 09:24 +1100
Re: Language stds (Re: f.) for Gorth) "Elizabeth D. Rather" <erather@forth.com> - 2016-12-27 17:10 -0600
Re: Language stds (Re: f.) for Gorth) hughaguilar96@gmail.com - 2016-12-27 22:58 -0800
Re: Language stds (Re: f.) for Gorth) "HAA" <someone@microsoft.com> - 2016-12-29 10:12 +1100
Re: Language stds (Re: f.) for Gorth) "Elizabeth D. Rather" <erather@forth.com> - 2016-12-29 17:03 -0800
Re: Language stds (Re: f.) for Gorth) hughaguilar96@gmail.com - 2016-12-29 19:35 -0800
Re: Language stds (Re: f.) for Gorth) Howerd <howerdo@yahoo.co.uk> - 2016-12-30 05:27 -0800
Re: Language stds (Re: f.) for Gorth) hughaguilar96@gmail.com - 2016-12-30 19:11 -0800
Re: Language stds (Re: f.) for Gorth) hughaguilar96@gmail.com - 2016-12-31 06:42 -0800
Page 5 of 8 — ← Prev page 1 2 3 4 [5] 6 7 8 Next page →
| From | "HAA" <someone@microsoft.com> |
|---|---|
| Date | 2016-12-22 11:32 +1100 |
| Message-ID | <o3f77i$1n7g$1@gioia.aioe.org> |
| In reply to | #53424 |
Paul Rubin wrote: > "HAA" <someone@microsoft.com> writes: > > I don't wish to comment on individual choices but do you not question > > what practical use a forth for microcontroller has for these things? > > In Amforth, the floating point wordset is a relatively heavyweight > optional library, since it has to implement the floating point > arithmetic in software. If you don't have the wordset loaded, there's > no reason to make the text interpreter able to parse floating point > literals. So parsing them is done by a recognizer that's loaded with > the library. I think that was the original motivation for recognizers. The underlying support code for recognizers (which is not insignificant) must exist whether floating point is present or not. The question for Forth implementations is whether they can find enough Forth parsing uses beyond conventional needs such as f/p to justify the investment. IMO the issues recognizers solve are arcane enough not to warrant. If I were to provide recognizers for the 'one in a million' times I needed it would be in the form VFX did - as a loadable add-on that's patched into the system via an existing hook.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd@net2o.de> |
|---|---|
| Date | 2017-01-03 19:33 +0000 |
| Message-ID | <o4gub0$2g8$1@dont-email.me> |
| In reply to | #53478 |
Am Thu, 22 Dec 2016 11:32:11 +1100 schrieb HAA: > The underlying support code for recognizers (which is not insignificant) > must exist whether floating point is present or not. The question for > Forth implementations is whether they can find enough Forth parsing uses > beyond conventional needs such as f/p to justify the investment. IMO > the issues recognizers solve are arcane enough not to warrant. If I > were to provide recognizers for the 'one in a million' times I needed it > would be in the form VFX did - as a loadable add-on that's patched into > the system via an existing hook. The existing hooks in VFX are many, and cost more than having a general purpose recognizer interface. That's because they are all special- purpose hooks, so each hook is a deferred word, and called at some point in the interpreter, usually if some condition is met. Of course, the outer interpreter as such is another deferred word, so it can be completely replaced. Matthias Trute, who implemented the recognizer in a rather small Forth (amForth) realized that it is about as much effort to implement it as the normal Forth interpreter is. You have a get-stack/set-stack helper, which can be used for get-order/set-order as well (so very little additional costs), you have the recognizer loop, which iterates over the recognizer, and it's pretty small, and then for switching between interpretation and compilation, you simply switch the one word which handles the output of the recognizer loop. Or interpret the value in STATE as cell offset into the table returned... -- Bernd Paysan "If you want it done right, you have to do it yourself" net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ* http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-01-03 22:13 -0800 |
| Message-ID | <1fe7f91d-b849-4f61-a497-96ce92c8f11f@googlegroups.com> |
| In reply to | #53717 |
On Tuesday, January 3, 2017 at 12:35:24 PM UTC-7, Bernd Paysan wrote: > Am Thu, 22 Dec 2016 11:32:11 +1100 schrieb HAA: > > The underlying support code for recognizers (which is not insignificant) > > must exist whether floating point is present or not. The question for > > Forth implementations is whether they can find enough Forth parsing uses > > beyond conventional needs such as f/p to justify the investment. IMO > > the issues recognizers solve are arcane enough not to warrant. If I > > were to provide recognizers for the 'one in a million' times I needed it > > would be in the form VFX did - as a loadable add-on that's patched into > > the system via an existing hook. > > The existing hooks in VFX are many, and cost more than having a general > purpose recognizer interface. That's because they are all special- > purpose hooks, so each hook is a deferred word, and called at some point > in the interpreter, usually if some condition is met. Of course, the > outer interpreter as such is another deferred word, so it can be > completely replaced. > > Matthias Trute, who implemented the recognizer in a rather small Forth > (amForth) realized that it is about as much effort to implement it as the > normal Forth interpreter is. You have a get-stack/set-stack helper, > which can be used for get-order/set-order as well (so very little > additional costs), you have the recognizer loop, which iterates over the > recognizer, and it's pretty small, and then for switching between > interpretation and compilation, you simply switch the one word which > handles the output of the recognizer loop. Or interpret the value in > STATE as cell offset into the table returned... VFX doesn't defer LITERAL which is needed for cross-compilers. The recognizers can't fix this problem either. I think that nobody on the ANS-Forth or Forth-200x committee wants to allow common Forth programmers to write cross-compilers in competition with Forth Inc. and MPE --- how difficult would it be to just define LITERAL as being deferred??? --- but ANS-Forth didn't do this, and Forth-200x won't either. LITERAL will be defined as deferred in Straight Forth (also, DLITERAL and FLITERAL etc.) --- this alone makes gives Straight Forth a future --- Forth-200x has no future at all.
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-01-04 23:03 +0000 |
| Message-ID | <o4juu4$qp$1@dont-email.me> |
| In reply to | #53726 |
On 1/4/2017 06:13, hughaguilar96@gmail.com wrote: > > I think that nobody on the ANS-Forth or Forth-200x committee wants to > allow common Forth programmers to write cross-compilers in > competition with Forth Inc. and MPE --- how difficult would it be to > just define LITERAL as being deferred??? --- but ANS-Forth didn't do > this, and Forth-200x won't either. There is no word DEFER in ANS Forth, so it would not have made sense to define LITERAL that way. Forth 200x added DEFER and some supporting words as CORE EXT in 2004. LITERAL is CORE. Your proposal would require DEFER and other words to be defined as CORE, something I'm sure many would object to due to unecessary bloat in the CORE wordset. > > LITERAL will be defined as deferred in Straight Forth (also, DLITERAL > and FLITERAL etc.) --- this alone makes gives Straight Forth a future > --- Forth-200x has no future at all. > Straight Forth will always be in the future. -- Alex
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-01-06 22:52 -0800 |
| Message-ID | <08fef6a1-fb35-472e-b63a-8ca863914221@googlegroups.com> |
| In reply to | #53738 |
On Wednesday, January 4, 2017 at 4:04:01 PM UTC-7, Alex wrote: > On 1/4/2017 06:13, hughaguilar96@gmail.com wrote: > > > > > I think that nobody on the ANS-Forth or Forth-200x committee wants to > > allow common Forth programmers to write cross-compilers in > > competition with Forth Inc. and MPE --- how difficult would it be to > > just define LITERAL as being deferred??? --- but ANS-Forth didn't do > > this, and Forth-200x won't either. > > There is no word DEFER in ANS Forth, so it would not have made sense to > define LITERAL that way. > > Forth 200x added DEFER and some supporting words as CORE EXT in 2004. > LITERAL is CORE. Your proposal would require DEFER and other words to be > defined as CORE, something I'm sure many would object to due to > unecessary bloat in the CORE wordset. It is not necessary to define DEFER --- I don't even like DEFER (I have VECTOR in the novice-package that is more efficient because it doesn't use CREATE DOES> like DEFER does). All that is necessary is to define a word called 'LITERAL and also say that LITERAL is defined like this: : literal 'literal @ execute ; immediate IIRC this is how vectored execution was done in the "Starting Forth" book --- considering that this is the only book that Elizabeth Rather has ever read, she should have been familiar with the concept --- the book does describe vectored execution as being a "hairy subject" though, which likely explains why she skipped that section of the book. > > LITERAL will be defined as deferred in Straight Forth (also, DLITERAL > > and FLITERAL etc.) --- this alone makes gives Straight Forth a future > > --- Forth-200x has no future at all. > > Straight Forth will always be in the future. This assumes that I'm incompetent and unable to write a Forth compiler. You have said before that I "have a serious misunderstanding of how pointers work" and "really don't know how CREATE DOES> works" --- so apparently you do think that I'm utterly incompetent --- actually, I'm one of the few people in the world who has been paid to write a Forth cross-compiler, and I know more about the subject that anybody that I'm aware of. I am putting some thought into the Straight Forth design --- that is why it is taking a lot of time --- by comparison, there seems to be no thought whatsoever being put into Forth-200x, which is just a great pile of manure that grows bigger every year without any apparent strategy or goal... I recently decided to change the definition of what a "number" is in Straight Forth --- this entails a complete rewrite of what I have done so far --- this change came about from having discussed the design with some Forth programmers (this was not on comp.lang.forth; they were sober and thoughtful).
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-01-07 22:45 +0000 |
| Message-ID | <o4rqvt$omi$1@dont-email.me> |
| In reply to | #53800 |
On 1/7/2017 06:52, hughaguilar96@gmail.com wrote: > On Wednesday, January 4, 2017 at 4:04:01 PM UTC-7, Alex wrote: >> On 1/4/2017 06:13, hughaguilar96@gmail.com wrote: >> >>> >>> I think that nobody on the ANS-Forth or Forth-200x committee >>> wants to allow common Forth programmers to write cross-compilers >>> in competition with Forth Inc. and MPE --- how difficult would it >>> be to just define LITERAL as being deferred??? --- but ANS-Forth >>> didn't do this, and Forth-200x won't either. >> >> There is no word DEFER in ANS Forth, so it would not have made >> sense to define LITERAL that way. >> >> Forth 200x added DEFER and some supporting words as CORE EXT in >> 2004. LITERAL is CORE. Your proposal would require DEFER and other >> words to be defined as CORE, something I'm sure many would object >> to due to unecessary bloat in the CORE wordset. > > It is not necessary to define DEFER --- I don't even like DEFER (I > have VECTOR in the novice-package that is more efficient because it > doesn't use CREATE DOES> like DEFER does). That's an implementation decision. DEFER does not mandate CREATE DOES>. > > All that is necessary is to define a word called 'LITERAL and also > say that LITERAL is defined like this: : literal 'literal @ execute > ; immediate > This is a standard definition we're talking about, so now we must define 'LITERAL, a sort of variable (qv BASE or >IN), otherwise there will be no standard way of revectoring LITERAL. Your proposal would require 'LITERAL to be defined as CORE, something I'm sure many would object to due to unecessary bloat in the CORE wordset. The name is not correct, since it's not the tick of LITERAL. We could go on, but you get the point. Making a standard isn't the work of a few seconds tossing off-the-cuff ideas into the mix and thinking you're done. -- Alex
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-01-07 17:23 -0800 |
| Message-ID | <2fd2f63e-ae7c-4002-a949-5bb89953ece1@googlegroups.com> |
| In reply to | #53828 |
On Saturday, January 7, 2017 at 3:45:47 PM UTC-7, Alex wrote: > On 1/7/2017 06:52, hughaguilar96@gmail.com wrote: > > All that is necessary is to define a word called 'LITERAL and also > > say that LITERAL is defined like this: : literal 'literal @ execute > > ; immediate > > > > This is a standard definition we're talking about, so now we must define > 'LITERAL, a sort of variable (qv BASE or >IN), otherwise there will be > no standard way of revectoring LITERAL. Your proposal would require > 'LITERAL to be defined as CORE, something I'm sure many would object to > due to unecessary bloat in the CORE wordset. The purpose of defining LITERAL as a vectored word is to allow the built-in outer-interpreter to be used in a cross-compiler and to support literal numbers in TARG mode. VFX has a lot of vectored words, but LITERAL isn't one of them --- obviously, Stephen Pelc is striving to prevent VFX users from writing their own cross-compiler in competition with him --- people pay hundreds of dollars for VFX, but they get cripple-ware.
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-01-08 09:13 +0000 |
| Message-ID | <o4svp5$k25$1@dont-email.me> |
| In reply to | #53836 |
On 1/8/2017 01:23, hughaguilar96@gmail.com wrote: > On Saturday, January 7, 2017 at 3:45:47 PM UTC-7, Alex wrote: >> On 1/7/2017 06:52, hughaguilar96@gmail.com wrote: >>> All that is necessary is to define a word called 'LITERAL and >>> also say that LITERAL is defined like this: : literal 'literal @ >>> execute ; immediate >>> >> >> This is a standard definition we're talking about, so now we must >> define 'LITERAL, a sort of variable (qv BASE or >IN), otherwise >> there will be no standard way of revectoring LITERAL. Your proposal >> would require 'LITERAL to be defined as CORE, something I'm sure >> many would object to due to unecessary bloat in the CORE wordset. > > The purpose of defining LITERAL as a vectored word is to allow the > built-in outer-interpreter to be used in a cross-compiler and to > support literal numbers in TARG mode. A use case of 1, and a minority sport. > > VFX has a lot of vectored words, but LITERAL isn't one of them --- > obviously, Stephen Pelc is striving to prevent VFX users from writing > their own cross-compiler in competition with him --- people pay > hundreds of dollars for VFX, but they get cripple-ware. > Well, obviously, since you say so. But how about answering the question; how are you going to get this into the standard? -- Alex
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-01-08 17:10 -0800 |
| Message-ID | <ed83d71c-3525-48d5-acfc-676796e192e4@googlegroups.com> |
| In reply to | #53845 |
On Sunday, January 8, 2017 at 2:13:39 AM UTC-7, Alex wrote: > But how about answering the question; how are you going to get this into > the standard? By declaring Straight Forth to be the standard.
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-01-09 10:22 +0000 |
| Message-ID | <o4vo6v$5g5$1@dont-email.me> |
| In reply to | #53877 |
On 1/9/2017 01:10, hughaguilar96@gmail.com wrote: > On Sunday, January 8, 2017 at 2:13:39 AM UTC-7, Alex wrote: >> But how about answering the question; how are you going to get this into >> the standard? > > By declaring Straight Forth to be the standard. > Good luck. -- Alex
[toc] | [prev] | [next] | [standalone]
| From | stephen@mpeforth.com |
|---|---|
| Date | 2017-01-08 07:00 -0800 |
| Message-ID | <ffb81c67-b89e-4f06-8896-c5717b5de5ec@googlegroups.com> |
| In reply to | #53836 |
On Sunday, 8 January 2017 02:23:33 UTC+1, hughag...@gmail.com wrote: > VFX has a lot of vectored words, but LITERAL isn't one of them You are absolutely right, but LITERAL does not handle integers, it compiles a single integer. Please try to keep up. The sequence you are trying to follow is: C#LITERAL (deferred) #LITERAL LITERAL Stephen
[toc] | [prev] | [next] | [standalone]
| From | albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2017-05-20 14:09 +0200 |
| Message-ID | <ofpblc$kan$1@cherry.spenarnc.xs4all.nl> |
| In reply to | #53828 |
In article <o4rqvt$omi$1@dont-email.me>, Alex <alex@rivadpm.com> wrote: >On 1/7/2017 06:52, hughaguilar96@gmail.com wrote: >> On Wednesday, January 4, 2017 at 4:04:01 PM UTC-7, Alex wrote: >>> On 1/4/2017 06:13, hughaguilar96@gmail.com wrote: >>> >>>> >>>> I think that nobody on the ANS-Forth or Forth-200x committee >>>> wants to allow common Forth programmers to write cross-compilers >>>> in competition with Forth Inc. and MPE --- how difficult would it >>>> be to just define LITERAL as being deferred??? --- but ANS-Forth >>>> didn't do this, and Forth-200x won't either. >>> >>> There is no word DEFER in ANS Forth, so it would not have made >>> sense to define LITERAL that way. >>> >>> Forth 200x added DEFER and some supporting words as CORE EXT in >>> 2004. LITERAL is CORE. Your proposal would require DEFER and other >>> words to be defined as CORE, something I'm sure many would object >>> to due to unecessary bloat in the CORE wordset. >> >> It is not necessary to define DEFER --- I don't even like DEFER (I >> have VECTOR in the novice-package that is more efficient because it >> doesn't use CREATE DOES> like DEFER does). > >That's an implementation decision. DEFER does not mandate CREATE DOES>. > >> >> All that is necessary is to define a word called 'LITERAL and also >> say that LITERAL is defined like this: : literal 'literal @ execute >> ; immediate >> > >This is a standard definition we're talking about, so now we must define >'LITERAL, a sort of variable (qv BASE or >IN), otherwise there will be >no standard way of revectoring LITERAL. Your proposal would require >'LITERAL to be defined as CORE, something I'm sure many would object to >due to unecessary bloat in the CORE wordset. > >The name is not correct, since it's not the tick of LITERAL. > >We could go on, but you get the point. Making a standard isn't the work >of a few seconds tossing off-the-cuff ideas into the mix and thinking >you're done. If I draw this into the context of my tiny recognizers (prefixes). If I'd need special numbers in a cross compiler, I just would define number recognizers ( the prefixes 0 1 2 .. 9) in the search pad above the normal number recognizers. LITERAL would not come into play. I'm sure that the more sophisticated official recognizers are able to do the same. > >-- >Alex Groetjes Albert -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | Matthias Trute <matthias.trute@gmail.com> |
|---|---|
| Date | 2017-01-11 01:14 -0800 |
| Message-ID | <77f4cfd0-921b-4958-8a73-7681136d15f0@googlegroups.com> |
| In reply to | #53478 |
> The underlying support code for recognizers (which is not insignificant) > must exist whether floating point is present or not. Indeed. But if you handle all possible data input types that way, the overhead is gone. That is what I've done in amforth. The implementations of the text interpreter before recognizers and afterwards take almost exactly the same amount of dictionary space. As a bonus the text interpreter got properly factorized ;) > The question for Forth > implementations is whether they can find enough Forth parsing uses > beyond conventional needs such as f/p to justify the investment. Forth 2012 introduced a new number format 'a'. Adding this to the interpreter is an almost noop. And who knows, which formats the future will give us. http://theforth.net/package/recognizers may give some ideas. > IMO the > issues recognizers solve are arcane enough not to warrant. If I were to > provide recognizers for the 'one in a million' times I needed it would be in > the form VFX did - as a loadable add-on that's patched into the system > via an existing hook. If such a hook exists in you preferred forth a valid approach. At the end of the day, recognizers are an optional word set.
[toc] | [prev] | [next] | [standalone]
| From | albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2016-12-07 12:26 +0100 |
| Message-ID | <o28rli$b5j$1@cherry.spenarnc.xs4all.nl> |
| In reply to | #53145 |
In article <o27qqu$alb$1@gioia.aioe.org>, HAA <someone@microsoft.com> wrote:
>josv@planet.nl wrote:
>> \ (f.) Makes it very easy to send a floating point number to some target.
>
>An early ANS draft had (F.) and (E.). Had they gone with it you wouldn't
>now be looking for a solution for what every other language provides :)
>
>12.1.0084 (F.) "Paren-f-dot-paren"
> ( -- c-addr u )( F: r -- ) or ( r -- c-addr u )
>
> Convert the top number on the floating-point stack to its character
> string representation using fixed point notation:
> [-] <digit>.<digits0>
> The number of digits after the decimal point is determined by PLACES.
>
I'd like to have
12.1.0084 (F.C) "Paren-f-convert"
( -- c-addr u )( F: r -- ) or ( r -- c-addr u )
Convert the top number on the floating-point stack to an implementation
defined string representation. The representation much be such that
evaluation of the string yields a floating point number without significant
loss of precision.
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | "HAA" <someone@microsoft.com> |
|---|---|
| Date | 2016-12-08 10:21 +1100 |
| Message-ID | <o2a5ib$4c0$1@gioia.aioe.org> |
| In reply to | #53148 |
Albert van der Horst wrote: > In article <o27qqu$alb$1@gioia.aioe.org>, HAA <someone@microsoft.com> wrote: > >josv@planet.nl wrote: > >> \ (f.) Makes it very easy to send a floating point number to some target. > > > >An early ANS draft had (F.) and (E.). Had they gone with it you wouldn't > >now be looking for a solution for what every other language provides :) > > > >12.1.0084 (F.) "Paren-f-dot-paren" > > ( -- c-addr u )( F: r -- ) or ( r -- c-addr u ) > > > > Convert the top number on the floating-point stack to its character > > string representation using fixed point notation: > > [-] <digit>.<digits0> > > The number of digits after the decimal point is determined by PLACES. > > > > I'd like to have > > 12.1.0084 (F.C) "Paren-f-convert" > ( -- c-addr u )( F: r -- ) or ( r -- c-addr u ) > > Convert the top number on the floating-point stack to an implementation > defined string representation. The representation much be such that > evaluation of the string yields a floating point number without significant > loss of precision. You don't need a special routine for that. Use a non-normative value for PLACES such as -1 and let the function do it for you.
[toc] | [prev] | [next] | [standalone]
| From | albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2016-12-20 15:45 +0100 |
| Message-ID | <o3bg6s$kk2$1@cherry.spenarnc.xs4all.nl> |
| In reply to | #53175 |
In article <o2a5ib$4c0$1@gioia.aioe.org>, HAA <someone@microsoft.com> wrote: >Albert van der Horst wrote: >> In article <o27qqu$alb$1@gioia.aioe.org>, HAA <someone@microsoft.com> wrote: >> >josv@planet.nl wrote: >> >> \ (f.) Makes it very easy to send a floating point number to some target. >> > >> >An early ANS draft had (F.) and (E.). Had they gone with it you wouldn't >> >now be looking for a solution for what every other language provides :) >> > >> >12.1.0084 (F.) "Paren-f-dot-paren" >> > ( -- c-addr u )( F: r -- ) or ( r -- c-addr u ) >> > >> > Convert the top number on the floating-point stack to its character >> > string representation using fixed point notation: >> > [-] <digit>.<digits0> >> > The number of digits after the decimal point is determined by PLACES. >> > >> >> I'd like to have >> >> 12.1.0084 (F.C) "Paren-f-convert" >> ( -- c-addr u )( F: r -- ) or ( r -- c-addr u ) >> >> Convert the top number on the floating-point stack to an implementation >> defined string representation. The representation much be such that >> evaluation of the string yields a floating point number without significant >> loss of precision. > >You don't need a special routine for that. Use a non-normative value for >PLACES such as -1 and let the function do it for you. > > > "We don't need a $ prefix, just do [ HEX ] #NUMBER# [ DECIMAL ] or HEX #NUMBER# DECIMAL whenever you feel like you need hex." Come to think of it F>$ would be a better name. Groetjes Albert -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2016-12-20 15:33 +0000 |
| Message-ID | <o3bisp$acv$1@dont-email.me> |
| In reply to | #53448 |
On 12/20/2016 14:45, Albert van der Horst wrote: > > "We don't need a $ prefix, just do > [ HEX ] #NUMBER# [ DECIMAL ] Works inside a definition (while compiling), but clumsy. Doesn't work outside. > or > HEX #NUMBER# DECIMAL Doesn't work inside a definition, works outside (while interpreting). > > whenever you feel like you need hex." Whenever being the operative word, since compile time isn't interpret time. And it assumes that you want to end up in DECIMAL once you're finished. -- Alex
[toc] | [prev] | [next] | [standalone]
| From | "HAA" <someone@microsoft.com> |
|---|---|
| Date | 2016-12-22 11:37 +1100 |
| Message-ID | <o3f77k$1n7g$2@gioia.aioe.org> |
| In reply to | #53448 |
Albert van der Horst wrote: > In article <o2a5ib$4c0$1@gioia.aioe.org>, HAA <someone@microsoft.com> wrote: > >Albert van der Horst wrote: > >> In article <o27qqu$alb$1@gioia.aioe.org>, HAA <someone@microsoft.com> wrote: > >> >josv@planet.nl wrote: > >> >> \ (f.) Makes it very easy to send a floating point number to some target. > >> > > >> >An early ANS draft had (F.) and (E.). Had they gone with it you wouldn't > >> >now be looking for a solution for what every other language provides :) > >> > > >> >12.1.0084 (F.) "Paren-f-dot-paren" > >> > ( -- c-addr u )( F: r -- ) or ( r -- c-addr u ) > >> > > >> > Convert the top number on the floating-point stack to its character > >> > string representation using fixed point notation: > >> > [-] <digit>.<digits0> > >> > The number of digits after the decimal point is determined by PLACES. > >> > > >> > >> I'd like to have > >> > >> 12.1.0084 (F.C) "Paren-f-convert" > >> ( -- c-addr u )( F: r -- ) or ( r -- c-addr u ) > >> > >> Convert the top number on the floating-point stack to an implementation > >> defined string representation. The representation much be such that > >> evaluation of the string yields a floating point number without significant > >> loss of precision. > > > >You don't need a special routine for that. Use a non-normative value for > >PLACES such as -1 and let the function do it for you. > > > > > > > > "We don't need a $ prefix, just do > [ HEX ] #NUMBER# [ DECIMAL ] > or > HEX #NUMBER# DECIMAL > > whenever you feel like you need hex." > > Come to think of it F>$ would be a better name. > > Groetjes Albert Unsure what you mean but f/p numbers typically have more precision than is necessary or desired and specifying the number of places after the decimal point is the traditional way applications have of limiting it. It also solves the ambiguity inherent in the ANS definition for F. which btw also exists in your (F.C) definition i.e. exactly how many digits should you print for a given case? It's indeterminate.
[toc] | [prev] | [next] | [standalone]
| From | albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2016-12-22 14:19 +0100 |
| Message-ID | <o3gjt9$723$1@cherry.spenarnc.xs4all.nl> |
| In reply to | #53479 |
In article <o3f77k$1n7g$2@gioia.aioe.org>, HAA <someone@microsoft.com> wrote: >Albert van der Horst wrote: >> In article <o2a5ib$4c0$1@gioia.aioe.org>, HAA <someone@microsoft.com> wrote: >> >Albert van der Horst wrote: >> >> In article <o27qqu$alb$1@gioia.aioe.org>, HAA <someone@microsoft.com> wrote: >> >> >josv@planet.nl wrote: >> >> >> \ (f.) Makes it very easy to send a floating point number to some target. >> >> > >> >> >An early ANS draft had (F.) and (E.). Had they gone with it you wouldn't >> >> >now be looking for a solution for what every other language provides :) >> >> > >> >> >12.1.0084 (F.) "Paren-f-dot-paren" >> >> > ( -- c-addr u )( F: r -- ) or ( r -- c-addr u ) >> >> > >> >> > Convert the top number on the floating-point stack to its character >> >> > string representation using fixed point notation: >> >> > [-] <digit>.<digits0> >> >> > The number of digits after the decimal point is determined by PLACES. >> >> > >> >> >> >> I'd like to have >> >> >> >> 12.1.0084 (F.C) "Paren-f-convert" >> >> ( -- c-addr u )( F: r -- ) or ( r -- c-addr u ) >> >> >> >> Convert the top number on the floating-point stack to an implementation >> >> defined string representation. The representation much be such that >> >> evaluation of the string yields a floating point number without significant >> >> loss of precision. >> > >> >You don't need a special routine for that. Use a non-normative value for >> >PLACES such as -1 and let the function do it for you. >> > >> > >> > >> >> "We don't need a $ prefix, just do >> [ HEX ] #NUMBER# [ DECIMAL ] >> or >> HEX #NUMBER# DECIMAL >> >> whenever you feel like you need hex." >> >> Come to think of it F>$ would be a better name. >> >> Groetjes Albert > >Unsure what you mean but f/p numbers typically have more precision >than is necessary or desired and specifying the number of places after >the decimal point is the traditional way applications have of limiting it. >It also solves the ambiguity inherent in the ANS definition for F. which >btw also exists in your (F.C) definition i.e. exactly how many digits >should you print for a given case? It's indeterminate. That's the most clear ever. You will typically use it in hex, and the answer is all digits, maybe leaving out trailing zeroes. In numeric computing one wants to pass fp numbers to another program. It is bad design to assume the internal format is the same for both programs. so we want ascii not binary. Forth is in the unique position to just print all heximals, pass this exact external format and get it over with. If the other program cannot handle all heximals, fine, at least it gets as close as possible. (We must introduce _ for an exponent sign first with basis other than 10). Groetjes Albert > > > -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | "HAA" <someone@microsoft.com> |
|---|---|
| Date | 2016-12-23 12:11 +1100 |
| Message-ID | <o3htj5$1qka$1@gioia.aioe.org> |
| In reply to | #53490 |
Albert van der Horst wrote: > In article <o3f77k$1n7g$2@gioia.aioe.org>, HAA <someone@microsoft.com> wrote: > >Albert van der Horst wrote: > >> In article <o2a5ib$4c0$1@gioia.aioe.org>, HAA <someone@microsoft.com> wrote: > >> >Albert van der Horst wrote: > >> >> ... > >> >> I'd like to have > >> >> > >> >> 12.1.0084 (F.C) "Paren-f-convert" > >> >> ( -- c-addr u )( F: r -- ) or ( r -- c-addr u ) > >> >> > >> >> Convert the top number on the floating-point stack to an implementation > >> >> defined string representation. The representation much be such that > >> >> evaluation of the string yields a floating point number without significant > >> >> loss of precision. > >> > > >> >You don't need a special routine for that. Use a non-normative value for > >> >PLACES such as -1 and let the function do it for you. > >> > > >> > > >> > > >> > >> "We don't need a $ prefix, just do > >> [ HEX ] #NUMBER# [ DECIMAL ] > >> or > >> HEX #NUMBER# DECIMAL > >> > >> whenever you feel like you need hex." > >> > >> Come to think of it F>$ would be a better name. > >> > >> Groetjes Albert > > > >Unsure what you mean but f/p numbers typically have more precision > >than is necessary or desired and specifying the number of places after > >the decimal point is the traditional way applications have of limiting it. > >It also solves the ambiguity inherent in the ANS definition for F. which > >btw also exists in your (F.C) definition i.e. exactly how many digits > >should you print for a given case? It's indeterminate. > > That's the most clear ever. You will typically use it in hex, and > the answer is all digits, maybe leaving out trailing zeroes. > > In numeric computing one wants to pass fp numbers to another > program. It is bad design to assume the internal format is the same > for both programs. so we want ascii not binary. > Forth is in the unique position to just print all heximals, pass this > exact external format and get it over with. If the other program > cannot handle all heximals, fine, at least it gets as close as > possible. > > (We must introduce _ for an exponent sign first with basis other > than 10). > > Groetjes Albert Ok but isn't the need for hexadecimal float notation still the exception rather than the rule? It's pointless if not wasteful to send data at 'full precision' when the data itself either doesn't have that precision or will never be employed at that precision. e.g. engineering applications typically only require a few digits of precision.
[toc] | [prev] | [next] | [standalone]
Page 5 of 8 — ← Prev page 1 2 3 4 [5] 6 7 8 Next page →
Back to top | Article view | comp.lang.forth
csiph-web