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 4 of 8 — ← Prev page 1 2 3 [4] 5 6 7 8 Next page →
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-12-20 12:35 +0000 |
| Message-ID | <2016Dec20.133512@mips.complang.tuwien.ac.at> |
| In reply to | #53442 |
mhx@iae.nl writes:
>On Tuesday, December 20, 2016 at 10:02:09 AM UTC+1, Andrew Haley wrote:
>> Bernd Paysan <bernd@net2o.de> wrote:
>>
>> > At least so far, I didn't ever had the urge to use F~ at all.
>>
>> I don't think anyone has.
It's used for checking FP results in ttester.fs
<http://www.forth200x.org/tests/ttester.fs>. Interestingly, it
defines three words FEXACTLY=, FABS= and FREL= that would be served
better with F=, F~ABS and F~REL than with F~. Especially, FEXACTLY=
would produce FALSE for 0e -0e FEXACTLY=, which is probably not
intended.
>Most of the uses below are for *testing* F~ (excluded here).
>The others are to find out if two floats are "close". It is
>a useful word, but a library routine would have sufficed.
>I guess F~ is in the standard because there might be 'homegrown'
>FP implementations where it is not obvious how to do perform
>this function portably.
If a library function suffices, there must be a portable way to
perform these functions; I also think it's pretty obvious, even though
obviousness is not required for library functions.
My guess is that the motivation for providing approximate FP equality
instead of F= is that F= often returns FALSE when the corresponding
operations on real numbers would have returned true, and sometimes
even vice versa (the classical issue "a!=b, but a-b=0" for FP numbers
without denormals is an example of the latter); this problem is
compounded by differences between different FP variants (as were still
rampant when Forth-94 was developed).
So, to avoid leading users into that trap, it's a good idea to provide
approximate equality; sometimes you want an absolute bound on the
approximation (F~ABS), sometimes you want the approximation to be
relative to the sizes of the involved numbers (F~REL). Word count
minimization then gave use the Frankenstein word F~.
I don't know what the thinking behind the specification for r3=0 was.
I don't think it makes any sense at all.
- 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 2016: http://www.euroforth.org/ef16/
[toc] | [prev] | [next] | [standalone]
| From | Charles Montgomery <cgm@physics.utoledo.edu> |
|---|---|
| Date | 2016-12-20 21:23 -0500 |
| Message-ID | <o3cp09$muc$1@dont-email.me> |
| In reply to | #53446 |
Anton Ertl wrote: > ... > My guess is that the motivation for providing approximate FP equality > instead of F= is that F= often returns FALSE when the corresponding > operations on real numbers would have returned true, and sometimes > even vice versa (the classical issue "a!=b, but a-b=0" for FP numbers > without denormals is an example of the latter); this problem is > compounded by differences between different FP variants (as were still > rampant when Forth-94 was developed). > > So, to avoid leading users into that trap, it's a good idea to provide > approximate equality; sometimes you want an absolute bound on the > approximation (F~ABS), sometimes you want the approximation to be > relative to the sizes of the involved numbers (F~REL). Word count > minimization then gave use the Frankenstein word F~. > It is precisely because the equality of two floating point numbers has a different meaning than the equality of two real numbers that tests for equality of floating point values are rarely used in serious floating point computation. It is not uncommon to test whether the difference between two fp values is less than a specified value. F0= is already in the Standard floating word set. If exact equality is wanted, it is easy to get: F- FABS F0= That seems hardly worth an additional Standard word. (Note that this tests whether the internal representation of the difference is the same as the internal representation of 0e , which might in unusual situations be different from a bitwise comparison of the two internal representations. If this could matter, I'd say you are treading on such thin ice that you should probably find a safer path to your destination.) If what I intend is to test approximate equality, I would never use F~. First I would need to recall which form of the third argument provides what I want and then make sure it is entered correctly. Two opportunities for a bug. A human reading the code (probably me) has the same problems. It is easy, quick, and clear to spell out just what is wanted. Apart from its desirability or value, I consider F~ to be badly designed. If there are two values on the fp stack to compare, it is a bad idea to put a third value on top of them which will have to moved out of the way with some sort of floating stack dancing. Ugh. regards to all cgm
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-12-21 07:29 +0000 |
| Message-ID | <2016Dec21.082902@mips.complang.tuwien.ac.at> |
| In reply to | #53460 |
Charles Montgomery <cgm@physics.utoledo.edu> writes:
>Anton Ertl wrote:
>> ...
>> My guess is that the motivation for providing approximate FP equality
>> instead of F= is that F= often returns FALSE when the corresponding
>> operations on real numbers would have returned true, and sometimes
>> even vice versa (the classical issue "a!=b, but a-b=0" for FP numbers
>> without denormals is an example of the latter); this problem is
>> compounded by differences between different FP variants (as were still
>> rampant when Forth-94 was developed).
...
>F0= is already in the Standard floating word set.
It is, to my surprise.
>If exact equality is wanted, it is easy to get: F- FABS F0=
Works in IEEE FP and the FABS is unnecessary. But without denormals,
it produces true for some pairs of numbers where F= produces false.
>(Note that this tests whether the internal representation of the difference
>is the same as the internal representation of 0e , which might in
>unusual situations be different from a bitwise comparison of the two
>internal representations. If this could matter, I'd say you are treading on
>such thin ice that you should probably find a safer path to your
>destination.)
F= is not a bitwise comparison, either:
0e -0e f= . -1 ok
(0e has a different bit representation than -0e, but they compare
equal).
0e 0e f/ fdup f= . 0 ok
Here we compare a NaN with itself, and that returns false despite
having the same bit representation.
>If what I intend is to test approximate equality, I would never use F~.
>First I would need to recall which form of the third argument provides
>what I want and then make sure it is entered correctly. Two opportunities
>for a bug. A human reading the code (probably me) has the same problems.
>It is easy, quick, and clear to spell out just what is wanted.
Please demonstrate. I wonder how you avoid the "enter correctly" bug
opportunity. And spelling out the equivalent of F~REL is not
particularly easy, quick, and clear. It's not as bad for F~ABS, but
you still involve a number of words, making it harder to read and
opening an opportunity for bugs.
>Apart from its desirability or value, I consider F~ to be badly designed.
>If there are two values on the fp stack to compare, it is a bad idea to
>put a third value on top of them which will have to moved out of the way
>with some sort of floating stack dancing. Ugh.
That aspect of F~ is well designed. It's better to require stack
juggling in the implementation of a word than in the use of a word.
If you had F~ ( r3 r1 r2 -- f ) instead, a typical use of F~ would
look like
... 1e-6 frot frot f~
instead of (for the standard F~ ( r1 r2 r3 -- f )):
... 1e-6 f~
- 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 2016: http://www.euroforth.org/ef16/
[toc] | [prev] | [next] | [standalone]
| From | Charles Montgomery <cgm@physics.utoledo.edu> |
|---|---|
| Date | 2016-12-21 22:24 -0500 |
| Message-ID | <o3fgvh$5qe$1@dont-email.me> |
| In reply to | #53463 |
Anton Ertl wrote: > Charles Montgomery <cgm@physics.utoledo.edu> writes: >>If exact equality is wanted, it is easy to get: F- FABS F0= > > Works in IEEE FP and the FABS is unnecessary. But without denormals, > it produces true for some pairs of numbers where F= produces false. > The FABS was included because it wasn't clear to me that the Standard specifies that F0= returns a true flag for -0e if it has a different internal representation than 0e. I am also unsure of how the F= whose behavior you describe here and below is specified. F= with these behaviors would certainly be reasonable, but I could imagine an implementation of an F= which behaves differently in some situations. >>(Note that this tests whether the internal representation of the >>difference is the same as the internal representation of 0e , which might >>in unusual situations be different from a bitwise comparison of the two >>internal representations. If this could matter, I'd say you are treading >>on such thin ice that you should probably find a safer path to your >>destination.) > > F= is not a bitwise comparison, either: > > 0e -0e f= . -1 ok > > (0e has a different bit representation than -0e, but they compare > equal). > > 0e 0e f/ fdup f= . 0 ok > > Here we compare a NaN with itself, and that returns false despite > having the same bit representation. > Is f= required to behave this way? It might be. I don't know. >>If what I intend is to test approximate equality, I would never use F~. >>First I would need to recall which form of the third argument provides >>what I want and then make sure it is entered correctly. Two opportunities >>for a bug. A human reading the code (probably me) has the same problems. >>It is easy, quick, and clear to spell out just what is wanted. > > Please demonstrate. I wonder how you avoid the "enter correctly" bug > opportunity. And spelling out the equivalent of F~REL is not > particularly easy, quick, and clear. It's not as bad for F~ABS, but > you still involve a number of words, making it harder to read and > opening an opportunity for bugs. > : close? ( f1 f2 -- flag ) f- fabs 1e-6 f< ; \ true if |f1-f2| is less than 1e-6 Easy, quick, and clear. Of course "1e-6" could be replaced with some fvalue previously generated in the program. Yes, the relative case needs some more fovers and frots ; the test is for a more complicated relation. As for "entering correctly", I have been known to omit a needed minus sign or hit a wrong key, and have learned to check for such. I acknowledge that that is a programmer issue rather than a language one. "Recalling and using the correct form of the third argument" should be counted as one opportunity for a bug. >>Apart from its desirability or value, I consider F~ to be badly designed. >>If there are two values on the fp stack to compare, it is a bad idea to >>put a third value on top of them which will have to moved out of the way >>with some sort of floating stack dancing. Ugh. > > That aspect of F~ is well designed. It's better to require stack > juggling in the implementation of a word than in the use of a word. > If you had F~ ( r3 r1 r2 -- f ) instead, a typical use of F~ would > look like > > ... 1e-6 frot frot f~ > > instead of (for the standard F~ ( r1 r2 r3 -- f )): > > ... 1e-6 f~ > My objection is to having three arguments to a test on two values. Another value to be used is better provided separately, in my opinion. If there are three arguments, I agree that the extra one should be on top. One word which does three different things, depending on its arguments, is not something I like in Forth. There are languages in which A+B does one thing if A and B are both integers, a different thing if either A or B is a floating point number, something different yet if A and B are character strings. That's not nice Forth. regards to all cgm
[toc] | [prev] | [next] | [standalone]
| From | "David N. Williams" <williams@umich.edu> |
|---|---|
| Date | 2016-12-22 08:10 -0500 |
| Message-ID | <o3gj8t$cd4$1@dont-email.me> |
| In reply to | #53480 |
On 12/21/16 10:24 PM, Charles Montgomery wrote:
> Anton Ertl wrote:
>
>> [...]
>>
>> F= is not a bitwise comparison, either:
>>
>> 0e -0e f= . -1 ok
>>
>> (0e has a different bit representation than -0e, but they compare
>> equal).
>>
>> 0e 0e f/ fdup f= . 0 ok
>>
>> Here we compare a NaN with itself, and that returns false despite
>> having the same bit representation.
>>
> Is f= required to behave this way? It might be. I don't know.
The answer is yes, if f= is the IEEE comparison:
http://www.umich.edu/~williams/archive/temp/ieee-fp-0.5.4a.txt
8.3 Comparison
--------------
[...]
IEEE identifies four fundamental, mutually exclusive comparisons:
less than ("<"), equal ("="), greater than (">"), and unordered (see
rule 3 below). Each of these is true iff each of the others is false.
The basic rules are the following:
1. The sign of zero is ignored.
2. The sign of infinity is not ignored, and is treated in the
natural way for the "ordinary" comparisons with real numbers
or infinity, namely <, =, and >. In particular, either
signed infinity is equal to itself.
3. The unordered comparison is true iff at least one of its two
arguments is a nan. That implies that any of the other
three, "ordinary" comparisons involving a nan is false.
Regards, David W.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-12-22 17:39 +0000 |
| Message-ID | <2016Dec22.183906@mips.complang.tuwien.ac.at> |
| In reply to | #53480 |
Charles Montgomery <cgm@physics.utoledo.edu> writes:
>I am also unsure of how the F= whose behavior you describe here and below
>is specified.
It's what the hardware FP equality comparison does, and what typically
FP equality in other languages does.
>F= with these behaviors would certainly be reasonable,
>but I could imagine an implementation of an F= which behaves differently in
>some situations.
But what the mainstream Forth systems do is to use the hardware FP
equality comparison. In particular, SwiftForth and Gforth and VFX
produce 0 for
0e 0e f/ fdup f= .
In addition, VFX reports a "NDP Potential Exception" when the Forth
text interpreter prints "ok".
>> F= is not a bitwise comparison, either:
>>
>> 0e -0e f= . -1 ok
>>
>> (0e has a different bit representation than -0e, but they compare
>> equal).
>>
>> 0e 0e f/ fdup f= . 0 ok
>>
>> Here we compare a NaN with itself, and that returns false despite
>> having the same bit representation.
>>
>Is f= required to behave this way? It might be. I don't know.
The IEEE FP standard that all recent FP hardware implements does
require this behaviour, so it's the common behaviour for F=.
>: close? ( f1 f2 -- flag ) f- fabs 1e-6 f< ; \ true if |f1-f2| is less than
>1e-6
>Easy, quick, and clear. Of course "1e-6" could be replaced with some fvalue
>previously generated in the program.
>Yes, the relative case needs some more fovers and frots ; the test is for a
>more complicated relation.
>As for "entering correctly", I have been known to omit a needed minus sign
>or hit a wrong key, and have learned to check for such. I acknowledge that
>that is a programmer issue rather than a language one.
More relavantly, this kind of bug will affect the code above just as
it will affect
: close? ( r1 r2 -- f ) 1e-6 f~abs ;
And IMO the latter variant is easier, quicker, and clearer; only a
little for the F~ABS case; quite a bit more for the F~REL case.
>My objection is to having three arguments to a test on two values. Another
>value to be used is better provided separately, in my opinion.
What kind of separate provision do you have in mind? Programmers can
define words like CLOSE? above or FABS=, FREL=, and FNEARLY= (in
ttester.fs) to have a textual separation of r3 from the other two
parameters; IMO putting the third parameter on the stack and leaving
the rest to the programmers is the appropriate thing to do for a
standard for F~ABS and F~REL.
>One word which does three different things, depending on its arguments, is
>not something I like in Forth.
Yes, that's the problem with F~.
- 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 2016: http://www.euroforth.org/ef16/
[toc] | [prev] | [next] | [standalone]
| From | albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2016-12-15 12:53 +0100 |
| Message-ID | <o2u071$vac$1@cherry.spenarnc.xs4all.nl> |
| In reply to | #53349 |
In article <2016Dec15.114203@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>Forth is the ultimate blue-collar practical language,
>>eschewing highfalutin theories in favour of what it takes to get real
>>work done.
>
>There is quite a bit of pragmatism around, but also quite a bit of
>dogmatism (especially based on Chuck Moore sayings, but I consider
>word-counting which gave us "gems" like F~ to also be in that camp),
>and then there are opinions without any rationale ("I don't like
>..."). And some may see an organizing principle where others see a
>highfalutin theory.
Coming back to pragmatism. I see that as the refusal to develop
theories, even where there obvious is need to. Certainly a bad thing.
You can't make up a good design without some theoretizations,
what others call thinking. First you need to experiment, otherwise
there is nothing to think about. So pragmatism is bad, makes you
make the same mistake over and again.
Opinions without rationale are certainly better than opinions
with a wrong rationalization. I realize that after 30 years
of using modeless editors my brain is not wired for an
editor like emacs or vim. Some people are inclined to say
that ee is better than vi, not me.
I agree that F~ is an abomination. I will waste two blocks on it,
when the first person asks for it.
>
>- anton
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 | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2016-12-15 05:59 -0600 |
| Message-ID | <QMidnYihLbQjGM_FnZ2dnUU7-TfNnZ2d@supernews.com> |
| In reply to | #53352 |
Albert van der Horst <albert@cherry.spenarnc.xs4all.nl> wrote: > > Coming back to pragmatism. I see that as the refusal to develop > theories, even where there obvious is need to. Certainly a bad thing. > You can't make up a good design without some theoretizations, > what others call thinking. First you need to experiment, otherwise > there is nothing to think about. So pragmatism is bad, makes you > make the same mistake over and again. How does it follow that pragmatism makes you make the same mistake over and again? Surely the essence of pragmatism is that you do what works, and what works is known from experience. There is certainly nothing about pragmatism which is the refusal to develop theories, only that those theories should be evaluated in terms of the success of their practical application. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | "Robert L." <No_spamming@noWhere_7073.org> |
|---|---|
| Date | 2017-01-03 16:15 +0000 |
| Message-ID | <o4gin2$g41$1@gioia.aioe.org> |
| In reply to | #53348 |
On 12/15/2016, Andrew Haley wrote: > Forth is the ultimate blue-collar practical language, > eschewing highfalutin theories in favour of what it takes to get real > work done. Obviously, that is absolutely wrong. For example, local variables are considered wicked by Forth worshippers not because they don't help in getting real work done, but because of mystical, ideological reasons. Programming in Forth is very impractical and inefficient. Very, very little data processing is done in Forth. It is used occasionally to flush toilets. -- When the Israeli bombers and torpedo-planes were sent to attack and destroy the ship, the Jewish commander, seeing that it was an American vessel, had misgivings and reported to the High Command, which simply repeated the orders to attack and sink the Liberty. www.revilo-oliver.com/rpo/Bit_of_Good_News.html
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-12-14 17:06 +0000 |
| Message-ID | <2016Dec14.180655@mips.complang.tuwien.ac.at> |
| In reply to | #53313 |
The Beez <the.beez.speaks@gmail.com> writes:
>But "hacking your interpreter" is NOT every elegant either. Chuck Moore HAT=
>ED hooks: "Don't anticipate" was his motto.
Hooks like the NOTFOUND hook found in all systems I looked at are not
anticipation of not-yet-existing usages, but are used as a way to
organize the code: In particular, floating-point words, including
floating-point input, can be loaded later than the text interpreter,
and in SwiftForth and VFX that is actually left to the user.
Recognizers are a generalization of NOTFOUND and similar hooks in the
text interpreter.
Chuck Moore made a general hook very central to Forth: The text
interpreter in combination with the dictionary. That's the extreme in
anticipation: it allows adding new words later and calling them,
whereas a fundamentalist follower of his sayings on this topic would
only support special-purpose programs without general extensibility
through a dictionary.
> Because in the end,=
> if you hate state smart words so much, why don't you simply and completely=
> outlaw them?
First, we need a good replacement for doing the things that some
people do with STATE-smart words. The '/['] approach does not have
the problems of STATE-smart words, but other, more obvious problems.
The Forth-94/2012 approach for, e.g., S", complicates things even if
we avoid the pitfalls of STATE-smartness (as, e.g., Gforth does).
The number recognizer built into the text interpreter has none of
these problems. That's why I think that we should provide a portable
way to add new recognizers.
Once we have that, we have the replacement for doing the things that
some people do with STATE-smart words; then we can think about phasing
out STATE-smart words and STATE itself.
- 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 2016: http://www.euroforth.org/ef16/
[toc] | [prev] | [next] | [standalone]
| From | "HAA" <someone@microsoft.com> |
|---|---|
| Date | 2016-12-18 10:58 +1100 |
| Message-ID | <o34jeo$9g4$1@gioia.aioe.org> |
| In reply to | #53262 |
Anton Ertl wrote: > "HAA" <someone@microsoft.com> writes: > > ... > >How is having less complicated compiler a "deficiency" ? > > You pointed out the deficiency: The need to use system-specific code > (or, in your words, to "hack your interpreter") in order to provide > number prefixes. > > Concerning "less complicated compiler", where is your proof of that? > Systems have provided floating-point literals, number prefixes, > support for other double indicators, dot-parsers etc. through > system-specific means, which may well be more complicated than one > general recognizer mechanism. I could ask where is the evidence recognizers have replaced anything? VFX doesn't have recognizers but includes code for it in their 'Examples' directory installed using the 'system-specific means' you critique above. System-specific hooks are alive and well, not because they're portable, but because of the diverse things they can achieve. Don't want floating- point, a particular ANS wordset, recognizers, or the latest comp.lang.forth novelty cluttering up your system when you don't need or tire of them? Hooks will do that for you. > >Forth was never intended for dummies. > > Do you suggest to design complicated interfaces, that don't work as > expected under some circumstances, and when a user falls into the > trap, defend the interface by calling the user a dummy? Yes, the > reaction appeals to the elitist reflexes in programmers, but that > still does not make such interfaces a good idea. Elitism is the idea that I can learn and use Forth but before the rest of the world can, it needs to be dumbed down.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2016-12-17 17:26 -0800 |
| Message-ID | <87shpm10zj.fsf@nightsong.com> |
| In reply to | #53399 |
"HAA" <someone@microsoft.com> writes: > I could ask where is the evidence recognizers have replaced anything? Amforth?
[toc] | [prev] | [next] | [standalone]
| From | "HAA" <someone@microsoft.com> |
|---|---|
| Date | 2016-12-19 13:16 +1100 |
| Message-ID | <o37ft7$aa2$1@gioia.aioe.org> |
| In reply to | #53400 |
Paul Rubin wrote: > "HAA" <someone@microsoft.com> writes: > > I could ask where is the evidence recognizers have replaced anything? > > Amforth? Not exactly overwhelming. I note from the documentation the author is a supporter of 200x and includes quotations as well as recognizers. 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?
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-12-18 19:19 -0800 |
| Message-ID | <75f41165-bcf1-4114-99e1-b72d11223058@googlegroups.com> |
| In reply to | #53422 |
On Sunday, December 18, 2016 at 7:16:12 PM UTC-7, HAA wrote: > Paul Rubin wrote: > > "HAA" <someone@microsoft.com> writes: > > > I could ask where is the evidence recognizers have replaced anything? > > > > Amforth? > > Not exactly overwhelming. I note from the documentation the author is > a supporter of 200x and includes quotations as well as recognizers. > 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? I am a big supporter of quotations --- I mean quotations that have access to the parent function's local variables --- I have quotations in Straight Forth. Straight Forth is a 64-bit Forth designed for desktop computers. Quotations are provided to support general-purpose data-structures. I don't think quotations are very useful in a micro-controller. A lot of micro-controllers have only a small amount of RAM --- they don't have data-structures; they only have simple variables and possibly a small array --- without data-structures, quotations don't have any use. I can write a cross-compiler for a Forth on a micro-controller --- this Forth won't be Straight Forth (because there are no 64-bit micro-controllers) --- I will leave the design of this Forth to people who know more about micro-controllers than I do (Raimond Dragomir's LFTforth would be a good start). One of the major mistakes of ANS-Forth was that it tried to be a Standard for both desktop computers and micro-controllers --- that made sense in the 1980s when the same processors (the 65c02 and the Z80) were used for both --- that no longer made sense in 1994 because different processors were used for desktop computers (the 32-bit x86 and PowerPC) and micro-controllers (the 8-bit 80c320 and MC6808, 16-bit MC6812, etc.). I am dubious that a Standard is needed for micro-controller Forth systems --- the programs aren't going to be portable anyway, due to being tied to the I/O --- the purpose of a Standard is portability of programs, so if the programs aren't portable anyway, then what benefit does the Standard provide?
[toc] | [prev] | [next] | [standalone]
| From | john <anon@example.com> |
|---|---|
| Date | 2016-12-19 11:03 +0000 |
| Message-ID | <MPG.32c1cee1a1d03d1a9896de@news.virginmedia.com> |
| In reply to | #53423 |
In article <75f41165-bcf1-4114-99e1-b72d11223058@googlegroups.com>, hughaguilar96@gmail.com says... > I am dubious that a Standard is needed for micro-controller Forth systems --- the programs aren't going to be portable anyway, > due to being tied to the I/O --- the purpose of a Standard is portability of > programs, so if the programs aren't portable anyway, then what benefit does > the Standard provide? > > Maintenance Support Repair Evolution Forensics Training More so than any other environment. Without a standard forth would have floated away on the winds of the 1980's software revolution, never to be seen again. Real world issues, real world systems have to cope with.. -- john ========================= http://johntech.co.uk "Bleeding Edge Forum" http://johntech.co.uk/forum/ =========================
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2016-12-20 01:46 -0800 |
| Message-ID | <55f5bd1b-d4cd-44c7-a67d-8970cef99c86@googlegroups.com> |
| In reply to | #53431 |
On Monday, 19 December 2016 11:02:36 UTC, john wrote: > In article <75f41165-bcf1-4114-99e1-b72d11223058@googlegroups.com>, > hughaguilar96@gmail.com says... > > I am dubious that a Standard is needed for micro-controller Forth systems --- the programs aren't going to be portable anyway, > > due to being tied to the I/O --- the purpose of a Standard is portability of > > programs, so if the programs aren't portable anyway, then what benefit does > > the Standard provide? > > > > > > Maintenance > Support > Repair > Evolution > Forensics > Training > More so than any other environment. > > Without a standard forth would have floated away on the winds > of the 1980's software revolution, never to be seen again. > > Real world issues, real world systems have to cope with.. > > -- > > john > > ========================= > http://johntech.co.uk > > "Bleeding Edge Forum" > http://johntech.co.uk/forum/ > > ========================= A standard is required for embedded systems, though it doesn't have to be an international standard. An in-house standard, as long as it is adhered to, is fine. Hard-core embedded features such as analogue I/O, digital I/O, touch screens, SD cards, I2C, SPI, CAN, DNP3 etc. would be a strange fit in ANS. The most appropriate place for an embedded standard would be as an optional word set. Of course, the implementation of these embedded interfaces is generally not difficult, and can often be implemented in ANS Forth with a hardware specific abstraction layer (you might need words to access ports, for example, which would need to fall back to the machine code of the host CPU). TCP/IP probably requires the most effort. Because they are easy to implement they tend to be developed in-house on an ad-hock/as needed basis without a lot of fuss. It's just not that big a deal. Folk just roll their own and they become in-house de-facto standards that probably start off a bit shaky but emerge in solid and dependable software.
[toc] | [prev] | [next] | [standalone]
| From | john <anon@example.com> |
|---|---|
| Date | 2016-12-20 12:14 +0000 |
| Message-ID | <MPG.32c330dfea82e0349896df@news.virginmedia.com> |
| In reply to | #53443 |
In article <55f5bd1b-d4cd-44c7-a67d-8970cef99c86@googlegroups.com>, markwills1970@gmail.com says... > A standard is required for embedded systems, though it doesn't have > to be an international standard. An in-house standard, as long as it is > adhered to, is fine. Hard-core embedded features such as analogue I/O, > digital I/O, touch screens, SD cards, I2C, SPI, CAN, DNP3 etc. would be > a strange fit in ANS. The most appropriate place for an embedded standard > would be as an optional word set. > > Of course, the implementation of these embedded interfaces is generally > not difficult, and can often be implemented in ANS Forth with a hardware > specific abstraction layer (you might need words to access ports, for > example, which would need to fall back to the machine code of the host > CPU). TCP/IP probably requires the most effort. > > Because they are easy to implement they tend to be developed in-house on > an ad-hock/as needed basis without a lot of fuss. It's just not that big > a deal. Folk just roll their own and they become in-house de-facto standards > that probably start off a bit shaky but emerge in solid and dependable > software. > Once upon a time I'd agree with much of that Mark. But things have changed. The old ways of doing things are becoming more and more physically dangerous. I therefore stick entirely with my previous post. House styles in particlular must go. and indeed are being removed as standards such as Industry 4 are implemented. I'll try and make some time to put a few words on my forum if anyone wants to dicsuss that but briefly - the marketing brochure for med-tech 2017 landed on my desk this week - Page 32 has a title in very big bold letters of: "Automation and Enforcement for the Med-Tech Industry" The word used is "enforcement." Fail to comply and your house will get no more visitors. The cave walls are closing in - heads up is in every ones interest. -- john ========================= http://johntech.co.uk "Bleeding Edge Forum" http://johntech.co.uk/forum/ =========================
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-12-20 17:34 -0800 |
| Message-ID | <d58f347f-2f88-4717-9600-149d530742d9@googlegroups.com> |
| In reply to | #53443 |
On Tuesday, December 20, 2016 at 2:46:15 AM UTC-7, Mark Wills wrote: > On Monday, 19 December 2016 11:02:36 UTC, john wrote: > > In article <75f41165-bcf1-4114-99e1-b72d11223058@googlegroups.com>, > > hughaguilar96@gmail.com says... > > > I am dubious that a Standard is needed for micro-controller Forth systems --- the programs aren't going to be portable anyway, > > > due to being tied to the I/O --- the purpose of a Standard is portability of > > > programs, so if the programs aren't portable anyway, then what benefit does > > > the Standard provide? > > > > > > > > > > Maintenance > > Support > > Repair > > Evolution > > Forensics > > Training > > More so than any other environment. > > > > Without a standard forth would have floated away on the winds > > of the 1980's software revolution, never to be seen again. > > > > Real world issues, real world systems have to cope with.. > > > > -- > > > > john > > > > ========================= > > http://johntech.co.uk > > > > "Bleeding Edge Forum" > > http://johntech.co.uk/forum/ > > > > ========================= > > A standard is required for embedded systems, though it doesn't have > to be an international standard. An in-house standard, as long as it is > adhered to, is fine. Hard-core embedded features such as analogue I/O, > digital I/O, touch screens, SD cards, I2C, SPI, CAN, DNP3 etc. would be > a strange fit in ANS. The most appropriate place for an embedded standard > would be as an optional word set. > > Of course, the implementation of these embedded interfaces is generally > not difficult, and can often be implemented in ANS Forth with a hardware > specific abstraction layer (you might need words to access ports, for > example, which would need to fall back to the machine code of the host > CPU). TCP/IP probably requires the most effort. > > Because they are easy to implement they tend to be developed in-house on > an ad-hock/as needed basis without a lot of fuss. It's just not that big > a deal. Folk just roll their own and they become in-house de-facto standards > that probably start off a bit shaky but emerge in solid and dependable > software. I'm not opposed to having a standard for a micro-controller Forth --- I just don't think think that I'm qualified to write such a standard, because I don't have much experience with micro-controllers --- if you et. al., should write a standard for micro-controller Forth, I will be able to write a cross-compiler for your Forth in Straight Forth (Raimond Dragomir's LFTforth might be a good start). I am opposed to having one standard that covers both micro-controller Forth and desktop-computer Forth --- also, an extension library for micro-controllers isn't going to work, because it wouldn't be able to deal with such issues as distinguishing between FLASH and RAM --- Straight Forth is for desktop computers, typically with a 64-bit processor (the Float version could be used on any computer with a numerical coprocessor for IEEE-754 whether the computer is 32-bit or 64-bit).
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2016-12-18 19:25 -0800 |
| Message-ID | <87r3544n2q.fsf@jester.gateway.pace.com> |
| In reply to | #53422 |
"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.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-12-18 19:45 -0800 |
| Message-ID | <d7eeabac-9982-4a1d-83df-37a219c1d6f5@googlegroups.com> |
| In reply to | #53424 |
On Sunday, December 18, 2016 at 8:25:34 PM UTC-7, 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. This is much more easily accomplished simply by making a few words used by the outer-interpreter vectored, such as NUMBER? and LITERAL --- nothing in ANS-Forth is vectored though --- the "Starting Forth" book described vectored execution as being a "hairy" subject, and apparently Elizabeth Rather didn't understand the subject, because vectored execution was not used in her toy language ANS-Forth. Also, btw, NUMBER? wasn't put in ANS-Forth. WTF??? A cross-compiler needs LITERAL to be vectored if it is going to use the built-in outer-interpreter. This won't be solved by recognizers. A cross-compiler needs QUIT to be vectored if it is going to have a custom-written outer-interpreter. This won't be solved by recognizers. Recognizers are over-complicated and they don't solve the problems anyway --- to a large extent, Straight Forth primarily breaks from Forth-200x in that Straight Forth doesn't provide recognizers but does standardized vectored execution of important words such as NUMBER? LITERAL QUIT etc..
[toc] | [prev] | [next] | [standalone]
Page 4 of 8 — ← Prev page 1 2 3 [4] 5 6 7 8 Next page →
Back to top | Article view | comp.lang.forth
csiph-web