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 6 of 8 — ← Prev page 1 2 3 4 5 [6] 7 8 Next page →
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-12-22 17:49 -0800 |
| Message-ID | <ec21734f-c932-4d5f-a720-7f50acdcc5f1@googlegroups.com> |
| In reply to | #53498 |
On Thursday, December 22, 2016 at 6:11:06 PM UTC-7, HAA wrote: > 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. I haven't been paying much attention to this thread. The OP asked for code to convert floats into strings and I provided it. When did we start talking about about hexadecimal floats??? Has this ever been suggested in the real world??? This is the pattern I've noticed on comp.lang.forth: 1.) Somebody asks for code to do something practical. 2.) I write code, or I already have it in the novice-package. 3.) My code is declared to be "crap" and/or it is just ignored. 4.) The thread diverges into bizarre nonsense about improbable requirements and/or lofty discussions of the "Forth Way," all of which is of no use to the OP. Why should anybody need to ask for code, in the year 2016, to convert a float into a string? Shouldn't this have been done decades ago? The Forth-200x committee's definition of "leadership" doesn't seem to involve writing Forth code with practical use. I've read that nobody knows what causes global warming --- do they know about all the hot air that is expelled by ANS-Forth enthusiasts? --- might be a clue there!
[toc] | [prev] | [next] | [standalone]
| From | "HAA" <someone@microsoft.com> |
|---|---|
| Date | 2016-12-23 20:41 +1100 |
| Message-ID | <o3irfu$110l$1@gioia.aioe.org> |
| In reply to | #53499 |
hughaguilar96@gmail.com wrote: > ... > Why should anybody need to ask for code, in the year 2016, to convert a float into a > string? Shouldn't this have been done decades ago? In true Forth style, ANS abandoned the ready-to-use functions originally planned and supplied REPRESENT so you can DIY. The result of which functions like (F.) keep on being reinvented with varying degrees of competence. What's not to like :) > ... > The bug is in VFX's code to convert strings into > floats. I don't have the source-code to VFX so I'm not going to debug VFX The source for the f/p is provided. VFX >FLOAT uses >NUMBER for the conversion which limits the mantissa to 19 digits on a 32-bit forth. Convert more and it silently fails. Win32F faced a similar issue with the x87 FBLD instruction which accepts only 18 digits. IIUC their solution is to FBLD the first 18 digits of the mantissa which returns a real, then manually adjust for the remaining digits.
[toc] | [prev] | [next] | [standalone]
| From | albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2017-05-20 14:21 +0200 |
| Message-ID | <ofpcbe$kdu$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. In porting fp's between Forth's one should use hex. In that case the representation is exact, just stop as soon as the representation is equal to the number, i.e. only zero's remaining. I've finally come around adding floating point last year to ciforth. Of course we should loose the E for representing the exponent in hex. Like so PI FDUP FS. 3.141592653589793238E0 OK HEX 40 F.R 3.243F6A8885A308D0000000000000000000000000000000000000000000000000_0 OK This is not an approximation, it is exactly the rational that the Forth uses to represent pi. We could leave out a couple of trailing zeroes without changing the number. 3.243F6A8885A308D0000000000000000000000000000000000000000000000000_0 PI F= OK . -1 OK 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 | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-12-15 22:31 -0800 |
| Message-ID | <3334df53-cd64-44bd-a144-9189084e7ddf@googlegroups.com> |
| In reply to | #53117 |
On Tuesday, December 6, 2016 at 4:40:16 AM UTC-7, jo...@planet.nl wrote:
> \ (f.) Makes it very easy to send a floating point number to some target.
> \ After looking to f. I now use the following code:
>
> : +pad ( adr cnt -- ) pad +place ;
>
> : f$ ( f -- n )
> pad off scratch represent 0=
> if 2drop scratch 3 min +pad rdrop exit then
> if s" -" +pad then ;
>
> : (f.) ( r -- ) ( -- adr cnt )
> \G Writes (the floating-point number) @i{r} without exponent,
> \G to a string. Includes last zeros when needed.
> f$ dup >r 0<=
> if s" 0" +pad
> else scratch r@ min +pad r@ precision - zeros
> then
> s" ." +pad r@ negate zeros
> scratch r> 0 max /string 0 max
> +pad pad count ;
>
> \ Eg:
> : crf. ( f - ) cr (f.) type ;
> 7 set-precision
> -12.3e crf. -1.003e crf.
> -1.3e crf. 0e crf.
>
> \\\ Output
> -12.30000
> -1.003000
> -1.300000
> 0.000000 ok
> \ Jos
Your use of PAD is bad Forth. Some function might be holding data in PAD and then call your function which clobbers its data in PAD --- even if you document which functions use PAD you will likely still have this happen --- and if you do realize that calling a function will clobber your data in PAD you then have to figure out somewhere to put the data other than PAD so it doesn't get clobbered.
All in all, PAD is terrible Forth --- this was most likely a hack that Charles Moore did to get some program working in the 1970s, and then he got kicked out of Forth Inc. in 1982 so he never had a chance to get rid of PAD and implement a heap.
My <SCIENTIFIC> currently supports scientific and engineering notation. Engineering provides an exponent for numbers >= 1000 but not for smaller ones. It should be easy to modify this so numbers >= 1,000,000,000 get an exponent but not smaller numbers. Also, it should be easy to modify it so there is a comma after every 3rd digit left of the decimal point. Would that work for you?
Can you do this upgrade yourself, or do you need me to do it?
This is an example of what I currently have:
1234.56789e engineering type 1.2345679e3 ok
123.456789e engineering type 123.45679 ok
12.3456789e engineering type 12.345679 ok
1.23456789e engineering type 1.2345679 ok
.123456789e engineering type 123.45679e-3 ok
.0123456789e engineering type 12.345679e-3 ok
.00123456789e engineering type 1.2345679e-3 ok
.000123456789e engineering type 123.45679e-6 ok
If you do the upgrade, you get to be famous and have your name listed in the novice-package as a contributor. Hurry though, because I'm releasing the next novice-package upgrade in a few days.
I want people to write Forth code that works --- every time anybody writes Forth code that works, this makes the Forth-200x committee look foolish.
* Why, in the year 2016, are they struggling to write code to convert floats into strings?
* Why do they feel obliged to agree with Elizabeth Rather that I'm not a Forth programmer?
* Why do they feel obliged to hurl weird insults at me, such as saying that I have a "serious misunderstanding of how pointers work"? Who do they think they are fooling?
The Forth-200x committee are failing badly --- they deserve to fail --- their failure will be the best thing that could happen for the Forth community.
BTW --- Am I the only person who thinks that Andrew Haley is a clown?
On Thursday, December 15, 2016 at 2:45:33 AM UTC-7, Andrew Haley wrote:
> Pragmatism is no more than an approach that evaluates
> theories or beliefs in terms of the success of their practical
> application. Forth is the ultimate blue-collar practical language,
> eschewing highfalutin theories in favour of what it takes to get real
> work done.
On Thursday, December 15, 2016 at 5:00:03 AM UTC-7, Andrew Haley wrote:
> 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 | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-12-16 18:26 -0800 |
| Message-ID | <8b980626-280f-4cec-8eb3-9007b58d36a6@googlegroups.com> |
| In reply to | #53374 |
On Thursday, December 15, 2016 at 11:31:33 PM UTC-7, hughag...@gmail.com wrote:
> My <SCIENTIFIC> currently supports scientific and engineering notation. Engineering provides an exponent for numbers >= 1000 but not for smaller ones. It should be easy to modify this so numbers >= 1,000,000,000 get an exponent but not smaller numbers. Also, it should be easy to modify it so there is a comma after every 3rd digit left of the decimal point. Would that work for you?
>
> Can you do this upgrade yourself, or do you need me to do it?
Well, I went ahead and did it myself. I found a bug in <BIG.> --- not actually a bug, just a bad design (it was left padding with blanks, which it shouldn't have been doing). Here is the new <BIG.> without the padding:
------------------------------------------------------------------------------------
item sgn \ used by ?# and ?COMMA
: ?# ( d -- new-d ) \ needs SGN set \ similar to _# except puts a - in there if SGN is set
2dup d0= if
sgn if sgn sign then
false to sgn
else
# then ;
: ?comma ( d -- d ) \ needs SGN set \ similar to _comma except puts a - in there if SGN is set
2dup d0= if
sgn if sgn sign then
false to sgn
else
comma then ;
: <big.> ( d -- adr cnt ) \ used for big numbers that need commas for clarity
2dup d0< to sgn dabs
<#
# ?# ?# ?comma
?# ?# ?# ?comma
?# ?# ?# ?comma
?# ?# ?# ?comma
?# ?# ?# ?comma
?# ?# ?# ?comma
?#
#> ;
: big. ( d -- )
<big.> type ;
-------------------------------------------------------------------------------------
And here are <ENG> and ENG that will generate the string without the exponent if the magnitude is small:
-------------------------------------------------------------------------------------
2000000001 constant eng-lim \ must be a positive integer
\ In <ENG> any float >= the lim goes to ENGINEERING and otherwise is done without an 'e'
: <eng> ( -- adr cnt lim ) \ float: n --
fdup fabs s>d d>f f>= fdup fabs 1e f< or if engineering exit then
<cstr
fdup f0< if [char] - char+cstr then
fabs
fdup f>d 2dup <big.> <+cstr>
d>f f- \ float: integer-part
fdup f0= 0= if
[char] . char+cstr
precision 0 ?do 10.e f* loop
true to ~#soft
fround f>d <# precision 0 ?do ~# loop #> <+cstr>
then
cstr> count ;
: eng ( -- adr cnt ) \ float: n --
eng-lim <eng> ;
----------------------------------------------------------------------------------
Here are some tests:
----------------------------------------------------------------------------------
2000000000.0001e ok F:-1
eng type 2,000,000,000.0001 ok
2000000001.0001e ok F:-1
eng type 2e9 ok
2000000000.000123456789e ok F:-1
eng type 7,751,640.03949188 ok \ this is a bug in VFX --- F. doesn't work either
2000000000.0001e ok F:-1
eng type 2,000,000,000.0001 ok
2000000.0001234567e ok F:-1
eng type 2,000,000.00012346 ok
0.0e ok F:-1
eng type 0 ok
-0.0e ok F:-1
eng type 0 ok
-0.0001e ok F:-1
eng type -100e-6 ok
----------------------------------------------------------------------------------
Notice that I found a bug in VFX during my testing. My Forth is pretty good --- when problems occur, my first thought is that there is a bug in the compiler rather than in my own code --- most of the time, this is the case.
Andrew Haley should be pleased that I wrote this code: "eschewing highfalutin theories in favour of what it takes to get real work done." LOL
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-12-18 16:41 -0800 |
| Message-ID | <bb8bcf81-feda-4b44-a8ba-15d7e159d571@googlegroups.com> |
| In reply to | #53384 |
On Friday, December 16, 2016 at 7:26:12 PM UTC-7, hughag...@gmail.com wrote: > Here are some tests: > ---------------------------------------------------------------------------------- > 2000000000.0001e ok F:-1 > eng type 2,000,000,000.0001 ok > 2000000001.0001e ok F:-1 > eng type 2e9 ok > 2000000000.000123456789e ok F:-1 > eng type 7,751,640.03949188 ok \ this is a bug in VFX --- F. doesn't work either > 2000000000.0001e ok F:-1 > eng type 2,000,000,000.0001 ok > 2000000.0001234567e ok F:-1 > eng type 2,000,000.00012346 ok > 0.0e ok F:-1 > eng type 0 ok > -0.0e ok F:-1 > eng type 0 ok > -0.0001e ok F:-1 > eng type -100e-6 ok > > ---------------------------------------------------------------------------------- > > Notice that I found a bug in VFX during my testing. My Forth is pretty good --- when problems occur, my first thought is that there is a bug in the compiler rather than in my own code --- most of the time, this is the case. Well, I tried this under VFX using my STRING-STACK.4TH package: ------------------------------------------------------------------------------------ 2000000000.000123456789e ok F:-1 f. 7751640. ok s" 2000000000.000123456789" str>num ok-1 F:-1 . 3 ok F:-1 f. 2000000000. ok ok s" 2000000000.123456789" str>num ok-1 F:-1 . 3 ok F:-1 f. 2000000000. ok s" 2000000.123456789" str>num ok-1 F:-1 . 3 ok F:-1 f. 2000000.1 ok precision . 8 ok s" 2000000.123456789" str>num ok-1 F:-1 . 3 ok F:-1 max-engineering type 2.000000123e6 ok s" 2000000.123456789" >float ok-1 F:-1 . -1 ok F:-1 max-engineering type 2.000000123e6 ok ------------------------------------------------------------------------------------ VFX has a bug in its code used by the outer-interpreter that converts strings into floats. My STR>NUM works fine (note that the 3 is a code indicating that the string was a float; 1 indicates a single-precision integer and 2 indicates a double-precision integer). My STR>NUM works fine; it obtains a float of full precision. The reason why only 8 digits are getting output by F. is that PRECISION is set to 8. When I use MAX-ENGINEERING I output 10 digits which is the MAX-PREC value. So, my code works. >FLOAT also works. The bug is in VFX's code to convert strings into floats. I don't have the source-code to VFX so I'm not going to debug VFX --- Stephen Pelc is ignoring me anyway --- Elizabeth Rather says that I'm not a Forth programmer, and she appointed Stephen Pelc to the Forth-200x committee, so Stephen Pelc is obliged to believe everything that she tells him to believe (otherwise she will kick him off the committee and replace him with somebody more loyal, such as Julien Fondren who is obviously angling for the appointment).
[toc] | [prev] | [next] | [standalone]
| From | stephen@mpeforth.com |
|---|---|
| Date | 2016-12-20 02:20 -0800 |
| Message-ID | <71401695-5656-48b0-aaa4-7f0f5be62b90@googlegroups.com> |
| In reply to | #53419 |
On Monday, 19 December 2016 01:41:05 UTC+1, hughag...@gmail.com wrote: > On Friday, December 16, 2016 at 7:26:12 PM UTC-7, hughag...@gmail.com wrote: > > Here are some tests: > > ---------------------------------------------------------------------------------- > > 2000000000.0001e ok F:-1 > > eng type 2,000,000,000.0001 ok > > 2000000001.0001e ok F:-1 > > eng type 2e9 ok > > 2000000000.000123456789e ok F:-1 > > eng type 7,751,640.03949188 ok \ this is a bug in VFX --- F. doesn't work either > > 2000000000.0001e ok F:-1 > > eng type 2,000,000,000.0001 ok > > 2000000.0001234567e ok F:-1 > > eng type 2,000,000.00012346 ok > > 0.0e ok F:-1 > > eng type 0 ok > > -0.0e ok F:-1 > > eng type 0 ok > > -0.0001e ok F:-1 > > eng type -100e-6 ok Hugh's 'bug' is actually a numeric overflow. The conversion routine converts to a 64 bit double number. Hugh's 22 digits require 73 bits for correct representation. Stephen
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-12-20 13:04 +0000 |
| Message-ID | <2016Dec20.140420@mips.complang.tuwien.ac.at> |
| In reply to | #53444 |
stephen@mpeforth.com writes:
>> > 2000000000.000123456789e ok F:-1
>> > eng type 7,751,640.03949188 ok \ this is a bug in VFX --- F. doesn't work either
...
>Hugh's 'bug' is actually a numeric overflow. The conversion routine converts to a 64 bit double number. Hugh's 22 digits require 73 bits for correct representation.
vfxlin "include /usr/local/VfxLinEval/Lib/x86/Ndp387.fth"
VFX Forth for Linux IA32 Version: 4.72 [build 0555]
Including /usr/local/VfxLinEval/Lib/x86/Ndp387.fth
2000000000.000123456789e f. 7751640. ok
Here both the string->FP conversion and the FP->string conversion come
from Ndp387.fth. Looks like a bug in Ndp387.fth to me. Investigating
further, it looks like the bug is in the input conversion:
2000000000.e .000123456789e f+ f. 2000000000. ok
If not all bits can be represented, that is ok and normal for FP. But
then you round to get rid of the least significant bits and get a
number that is close to the input number (just as you do for 0.1e,
which cannot be represented exactly in binary FP, either).
- 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 | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-12-20 17:27 -0800 |
| Message-ID | <06e75a4c-d2e6-432e-ada4-a2270a879a8b@googlegroups.com> |
| In reply to | #53447 |
On Tuesday, December 20, 2016 at 6:13:25 AM UTC-7, Anton Ertl wrote: > stephen@mpeforth.com writes: > >> > 2000000000.000123456789e ok F:-1 > >> > eng type 7,751,640.03949188 ok \ this is a bug in VFX --- F. doesn't work either > ... > >Hugh's 'bug' is actually a numeric overflow. The conversion routine converts to a 64 bit double number. Hugh's 22 digits require 73 bits for correct representation. > > vfxlin "include /usr/local/VfxLinEval/Lib/x86/Ndp387.fth" > VFX Forth for Linux IA32 Version: 4.72 [build 0555] > Including /usr/local/VfxLinEval/Lib/x86/Ndp387.fth > 2000000000.000123456789e f. 7751640. ok > > Here both the string->FP conversion and the FP->string conversion come > from Ndp387.fth. Looks like a bug in Ndp387.fth to me. Investigating > further, it looks like the bug is in the input conversion: > > 2000000000.e .000123456789e f+ f. 2000000000. ok > > If not all bits can be represented, that is ok and normal for FP. But > then you round to get rid of the least significant bits and get a > number that is close to the input number (just as you do for 0.1e, > which cannot be represented exactly in binary FP, either). Obviously! Here is VFX's outer-interpreter failing: 123.123456789123456789e f. -6.003752 ok Here is VFX's >FLOAT failing: s" 123.123456789123456789e" >float f. -6.003752 ok-1 . -1 ok \ the TRUE return means that it was successful, but it wasn't Here is my STR>NUM succeeding: s" 123.123456789123456789" str>num f. 123.1235 ok-1 . 3 ok \ the 3 is the code for a float (0 is invalid, 1 is a single, 2 is a double) Here is my STR>NUM working correctly: s" 123.123456789123456789e" str>num ok-1 F:-1 f. 123.1235 ok-1 . 0 ok It returned 0 here because the 'e' on the end lacked an exponent --- it actually makes no sense to have 'e' without a number after it. Here is my STR>NUM working correctly again: s" 123.123456789123456789e3" str>num f. 123123.5 ok-1 . 3 ok This time it returned 3 because the 'e' had a number after it which makes sense. Here is my STR>NUM working correctly on a float (it is okay to have commas on the right side of the decimal point): s" 12.123,456" str>num ok-1 F:-1 f. 12.12346 ok-1 . 3 ok Here is my STR>NUM working correctly on a float (this time we have commas on the left side of the decimal point): s" 12,345,678.123" str>num ok-1 F:-1 f. 12345680. ok-1 . 3 ok Here is my STR>NUM working correctly on a single-precision integer (commas okay again; the lack of a decimal point makes it an integer): s" 12,345,678" str>num ok-2 . 1 ok-1 . 12345678 ok Here is my STR>NUM working correctly on a double-precision integer (commas okay again; the comma at the front makes it a double-precision rather than single-precision integer): s" ,12,345,678" str>num ok-3 . 2 ok-2 d. 12345678 ok I invented the convention of putting a comma on the front of an integer to signify that it is double rather than single --- it seems reasonable to me --- it is a lot better than ANS-Forth's convention of a decimal point signifying a double-precision integer, which makes no sense (in the real world, a decimal point signifies a float).
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-12-17 10:36 -0800 |
| Message-ID | <1e41c9a2-f59a-44db-99ff-42987ec1c8fc@googlegroups.com> |
| In reply to | #53117 |
On Thursday, December 15, 2016 at 2:45:33 AM UTC-7, Andrew Haley wrote: > Pragmatism is no more than an approach that evaluates > theories or beliefs in terms of the success of their practical > application. Forth is the ultimate blue-collar practical language, > eschewing highfalutin theories in favour of what it takes to get real > work done. In the past, I've described myself as a "blue-collar" programmer on c.l.f.. In no way however, should this imply that I'm an ignoramus. I only meant that I am one of the very few people in the world who have been employed as a Forth programmer. When I wrote MFX, the development system for the MiniForth processor (now called RACE), the entire point of the compiler was that it should be able to compile the motion-control program (and the goal of the MiniForth processor was that it should do motion-control faster than the competitor's MC68000 system). The goal of the project wasn't just a vague speculation that it might be useful for something in the future --- there was a specific goal --- certainly, it is impossible to say if a project is a success or a failure unless there is a specific goal. My background is that I grew up in cattle-ranching country in Colorado. I remember in the 1970s as a boy that there were men who were ignoramuses. They typically worked as mechanics on cattle ranches. That farm equipment that they were maintaining had been manufactured in the 1950s or even the 1940s and it wasn't complicated technically. Also, if you maintain the same piece of machinery for 20 years, you are going to learn it inside and out, even if it does have some technical complexity (a baler is a technical marvel as compared to pitch-forking hay into a big pile). They were ignorant of technology beyond these pieces of equipment though. I saw that lots of people are ignorant of a variety of subjects (I was totally ignorant of how computers worked, although I was fascinated by the idea of a thinking machine which I had read about in sci-fi tales) --- an ignoramus however, is somebody who is proud of his ignorance, which he describes as "common sense" --- the ignoramus routinely denounces "educated fools" with their "book learnin'" and their "highfalutin theories." It is impossible to have a conversation with an ignoramus because invariably this results in getting told that you don't know the "way things have always been done" and that you just need to learn at the journeyman's knee so that in 10 or 20 years you can become a journeyman too. Consider this thread: https://groups.google.com/forum/#!topic/comp.lang.forth/pqhqqvWg9zk%5B51-75%5D Here Elizabeth Rather said that UARTs should only be supported for half-duplex unless full-duplex is absolutely needed, and that: On Monday, April 25, 2016 at 5:07:26 PM UTC-7, Elizabeth D. Rather wrote: > I can't think offhand of a case in which a > full-duplex port literally has concurrent streams of data flowing in and > out. Later we had this exchange: On Tuesday, April 26, 2016 at 2:04:29 AM UTC-7, Andrew Haley wrote: > Paul Rubin <no.email@nospam.invalid> wrote: > > Maybe if I know the application only uses half-duplex, I can > > implement some hacky thing that relies on that fact. But if I'm > > supplying a library facility it wouldn't occur to me to limit it > > like that. > > I'm sure it wouldn't, because you don't really think in the Forth way. > Don't speculate! > > Andrew. This is very familiar territory to me! All of this talk about the "Forth Way" is exactly what those ignoramuses were saying back in the 1970s about the: "way things have always been done." Ignoramuses always fall back on the "Way" which is can't really be argued against because there is no word in the English language that is the opposite of "Way." Here Andrew Haley commented further (quoted fully): On Tuesday, April 26, 2016 at 6:23:59 AM UTC-7, Andrew Haley wrote: > Paul Rubin <no.email@nospam.invalid> wrote: > > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: > >> I'm sure it wouldn't, because you don't really think in the Forth way. > >> Don't speculate! > > > > The Forth way seems to be to speculate that full duplex is not needed. > > You know for certain that it's not needed yet because you have a set > of already-complete applications that have not needed it. Of course > it might be needed in the future, but I remember what Forth Inc. said > to me a long time ago in a galaxy far, far away: > > "We can not promise you that in every case a feature in our systems > will be exactly what you need, but we can promise you that we've > thought about it." > > > I'd rather write something that works all the time, than write > > something that only works if a speculative presumption happens to > > come true. > > It's not really a presumption at all: it's the result of writing > applications. Forth systems (the industrial and professional kind) > weren't just written and then thrown over the wall: they are the > result of many years of using them to write applications and feeding > back the result into the product. > > > Why would I worry my beautiful mind trying to analyze whether > > bidirectional i/o would happen sometime later in the program > > development? That would be premature optimization. > > Because you don't get clean and simple programs by piling in features > speculatively. > > Are you really telling me that it's actually easier to create and use > multiple threads per device just in case they might be needed than to > say to yourself "I'll just do it half duplex for now. If that turns > out to be inadequate I'll do something more complex"? If you answer > "yes", I will say "I don't believe you." :-) > > Andrew. ANS-Forth is founded entirely upon writing new programs by cut-and-paste-and-tweak of code from old programs. This is very similar to the way that those ignoramus mechanics would maintain the same piece of farm equipment for decades. Over time it would break and get welded back together. Parts would fail and would get replaced. One time we had a tractor break in half --- the tractor had a cast-iron spine connecting the front with the back and which the engine is mounted on, and when I hit a badger hole while driving too fast it broke --- this actually got patched with steel plates and welded together! This is very similar to how PolyForth in MS-DOS days was just Charles Moore's old PDP-11 Forth ported over to the 8086. PolyForth had all of the system (compiler, dictionary, application program, application data, editor, etc.) in one 64KB segment --- this was because the PDP-11 was limited to addressing 64KB, and never mind that the 8086 could address multiple 64KB segments (UR/Forth had the machine code in the CS segment, the threaded-code and data in the DS segment, and the dictionary in the ES segment). PolyForth reminds me of that tractor that was patched together and put back into service after being broken in half --- ANS-Forth (the first-ever ANS-Forth compiler, which was written 3 years after the untested ANS-Forth got rubber-stamped by ANSI) is really just the same old 1970s technology slightly upgraded. And here in this thread we have Andrew Haley saying: On Thursday, December 15, 2016 at 5:00:03 AM UTC-7, Andrew Haley wrote: > 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. This is why ANS-Forth lacks code-libraries. As shown in this thread, ANS-Forth lacks any way to convert floating-point numbers into strings, and when I provide working code this is ignored because it is not the "Forth Way." We do have FFL but it has bugs that have been there for years, and the overall quality level is abysmal. Stephen Pelc vaguely promotes FFL, but he doesn't use it in his own programs. My own novice-package, which has far superior quality, is routinely denounced as "crap" by the ANS-Forth enthusiasts. Code-libraries have to be developed before they can be used (because time only flows forward, and never backward). The ANS-Forth enthusiasts say that code-libraries can't be used until they have proven their success in "practical application." How do they get used the first time though? I worked on a cattle ranch recently, and they now use the big round bales. The ranch owner said that she had to switch to round bales because the small rectangular bales (known as "idiot cubes") were no longer realistic --- she was feeding the cattle about 250 bales per day and needed 20 muscular Mexicans to do this by hand --- with the round bales only a few bales are needed and one guy with a diesel tractor can do the job by himself. Somebody had to be the first one to to use them though --- this had to be done despite the fact that they had not been already proven in "practical application" --- somebody had to *think* about the problem and realize that the new technology was better than the old technology, and just go ahead with it. Elizabeth Rather thinks that she is being clever by appointing her employee Andrew Haley to the Forth-200x committee, because he is super-loyal and will vote exactly the way that Forth Inc. tells him to vote. I think that this is a blunder though, and that this will kill Forth-200x, in the sense that everybody in the Forth community abandons Forth-200x. I think this for the following reasons: 1.) This is a gross violation of the rule that every company represented on the Forth-200x committee will have only one vote. In several cases we have both a boss and his employee on the committee. Leon Wagner and Andrew Haley both represent Forth Inc. Stephen Pelc and Peter Knaggs both represent MPE, and MPE does "joint projects" with Forth Inc. so Stephen Pelc has monetary motivation to just vote as Leon Wagner tells him to vote. Forth-200x is astro-turf --- it is obviously a Forth Inc. marketing gimmick faked up to look like a grass-roots project. 2.) Andrew Haley is obviously an ignoramus. He routinely makes idiotic statements parroting Elizabeth Rather's opposition to code-libraries. Forth-200x is supposed to support code-libraries --- there is no purpose in having a Standard unless it supports code-libraries --- yet the Forth-200x committee were all appointed by Elizabeth Rather who is dead-set against code-libraries. Forth-200x is going to fail --- Forth-200x deserves to fail --- Forth-200x's failure is the best thing that could happen for the Forth community, as this opens the door to having code-libraries, which is necessary for Forth to be used professionally.
[toc] | [prev] | [next] | [standalone]
| From | Julian Fondren <julian.fondren@gmail.com> |
|---|---|
| Date | 2016-12-17 11:51 -0800 |
| Message-ID | <fb2620c4-deb9-4648-a1a6-2db3fe500fb1@googlegroups.com> |
| In reply to | #53391 |
Hugh, condensed and annotated: On Saturday, December 17, 2016 at 12:36:39 PM UTC-6, hughag...@gmail.com wrote: > > In no way however, should this imply that I'm an ignoramus. Hugh is very smart. He is also a real Forth programmer. > the entire point of the compiler was that it should be able to compile the motion-control program Hugh's projects have definite goals by which they must be judged. Other people's projects though do not have goals (as far as Hugh can tell) so they may be judged by whatever metric Hugh finds for them that is most damning. Any lack in MFX? The motion-control program didn't need that. PolyForth not embracing segmented memory? Inexplicable and shameful. > I grew up in cattle-ranching country in Colorado. I remember in the 1970s In the bad old days, you could get employed based on your decades of expertise with a particular technological marvel. But if that's 'all' you knew, Hugh remembers you as an drooling idiot. Thankfully in these good new days you can get employed based on your decades of experience with Linux. But if you don't know Windows well enough to troubleshoot a Windows server's problems as well, some Hugh-like person will remember you as an idiot. And can you believe that some doctors only work with feet? > > It is impossible to have a conversation with an ignoramus because invariably this results in getting told that you don't know the "way things have always been done" and that you just need to learn at the journeyman's knee so that in 10 or 20 years you can become a journeyman too. Hugh has graduated from directly insulting his eternal life-enemies, and now chooses to tell stories about people he didn't like. Secretly he hopes that they will agree so that he can spring the trap: "YOU'RE JUST LIKE THAT PERSON. YOU SAID I WASN'T A REAL FORTH PROGRAMMER. HA HA HA YOU FINALLY ACKNOWLEDGED YOUR STUPIDITY BY PROXY." In a few years Hugh will graduate to telling original stories about nonexistent people who very clearly exhibit serious character flaws such as suggesting that Hugh hasn't yet mastered something. > This is why ANS-Forth lacks code-libraries. It lacks them, and also the ones that it has don't count. And the entire reason is Andrew Haley. What a jerk, that guy. He prevented other people - at a distance, and across time - from writing code libraries that count. And all by having this reckless opinion about pragmatism. Andrew Haley, you are admonished. > Code-libraries have to be developed before they can be used (because time only flows forward, and never backward). The ANS-Forth enthusiasts say that code-libraries can't be used until they have proven their success in "practical application." How do they get used the first time though? Here, Hugh actually forgets that he wrote his slide rule program with support from his novice library. The rest you have read before. -- Julian
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-12-18 19:35 -0800 |
| Message-ID | <d9c0c746-b39a-4464-85c4-4e5b399294c4@googlegroups.com> |
| In reply to | #53392 |
On Saturday, December 17, 2016 at 12:51:12 PM UTC-7, Julian Fondren wrote: > > the entire point of the compiler was that it should be able to compile the motion-control program > > Hugh's projects have definite goals by which they must be judged. > Other people's projects though do not have goals (as far as Hugh can > tell) so they may be judged by whatever metric Hugh finds for them > that is most damning. What goal did ANS-Forth have? There was no ANS-Forth compiler written until 1997, which was 3 years after ANS-Forth got rubber-stamped by ANSI in 1994. This was SwiftForth which was too bug-ridden to be usable. Even as late as version-2 SwiftForth had serious bugs, such as crashing when (LOCAL) was used. Apparently whatever goal ANS-Forth had, this goal did not involve writing Forth programs, because you can't write Forth programs without a Forth compiler. Obviously, ANS-Forth was a marketing gimmick of Forth Inc. --- the goal was to convince the world that Forth Inc. owns Forth and that all Forth programmers depend upon Forth Inc. for leadership --- UR/Forth went from being the best Forth system available to being a non-standard wanna-be, and consequently LMI went out of business, which was Elizabeth Rather's primary goal. > Any lack in MFX? The motion-control program didn't need that. How do you know that? The competitor was using an MC68000 board for their laser-etcher motion-control. This provided better performance than the 80c320 board used by Testra. Because of this, Testra built the MiniForth processor based on a Lattice 1048isp PLD --- this provided better performance and lower cost than the competitor's MC68000 board --- the competitor dropped out of the laser-etcher business because of this. Julien Fondren is a troll --- nothing that he says is true. > PolyForth not embracing segmented memory? Inexplicable and shameful. The whole point of switching from the Z80 and 65c02 to the 8088 was that the 8088 provided segmented memory --- an MS-DOS computer could smoothly access 640KB of memory, which in those days was quite a lot --- by comparison, Z80 and 65c02 systems used awkward bank-switching schemes to get 128KB, but this was a major hassle. Most desktop software needed more than 64KB --- the lack of memory of the 8-bit systems was what primarily made them useless for business software --- so yes, PolyForth failing to take advantage of segmented memory on the 8088 made the entire Forth community look stupid. PolyForth, more than anything else, is what killed Forth's credibility.
[toc] | [prev] | [next] | [standalone]
| From | albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2016-12-19 14:17 +0100 |
| Message-ID | <o38mlq$9db$1@cherry.spenarnc.xs4all.nl> |
| In reply to | #53425 |
In article <d9c0c746-b39a-4464-85c4-4e5b399294c4@googlegroups.com>, <hughaguilar96@gmail.com> wrote: <SNIP> >What goal did ANS-Forth have? There was no ANS-Forth compiler written until= > 1997, which was 3 years after ANS-Forth got rubber-stamped by ANSI in 1994= >. This was SwiftForth which was too bug-ridden to be usable. Even as late a= >s version-2 SwiftForth had serious bugs, such as crashing when (LOCAL) was = >used. This assumes an overview of all that happens in the Forth world. Nobody thinks you have, but anyway. Not only had Marcel Hendrix the transputer Forth running before we had the hardware (he wrote an emulator), once we had the hardware it was very nearly ANS compliance because there were preliminary documents. A few day after it was rubber stamped transputer Forth was fully ANS compliant. <SNIP> >PolyForth, more than anything else, is what killed Forth's credibility. Reminds me of the joke of the old friends telling each other jokes, the same jokes over and over again. So one day they decided to save time by giving the jokes numbers. Conversations went like: "319" "haha" Like the idea? 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 | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-12-19 10:10 -0800 |
| Message-ID | <f7b15b6b-5693-4451-8029-a7059eb63bfd@googlegroups.com> |
| In reply to | #53433 |
On Monday, December 19, 2016 at 6:06:37 AM UTC-7, Albert van der Horst wrote: > Not only had Marcel Hendrix the transputer Forth running before we had > the hardware (he wrote an emulator), once we had the hardware it was > very nearly ANS compliance because there were preliminary documents. A > few day after it was rubber stamped transputer Forth was fully ANS > compliant. The concept of "fully ANS-Forth compliant" is utter nonsense --- ANS-Forth has ambiguities. None of the ANS-Forth compilers (VFX, SwiftForth, Win32Forth, Gforth) are compatible with each other --- for the most part, being "ANS-Forth compliant" just means that the Forth compiler-writer brown-nosed Elizabeth Rather and in exchange she declared his compiler to be ANS-Forth compliant --- this doesn't at all mean that ANS-Forth programs can be ported without modification between the so-called "ANS-Forth compliant" compilers. The ANS-Forth document is full of phrases such as: "may or may not," "implementation defined," "ambiguous," etc. --- all of these represent forks in the design --- we have multiple contradictory designs all of which have some basis in the ANS-Forth document to support their claim of being compliant. By far, the weirdest example of this is Gforth in which FIND returns different xt values for a particular name depending upon what STATE is at the time that FIND is executed --- no other ANS-Forth compliant compiler does this, and it was never done prior to ANS-Forth so it isn't "common practice" (it isn't "common-sense practice" either) --- if Gforth qualifies as being ANS-Forth compliant, then anything can qualify as being ANS-Forth compliant, including a pile of horse manure.
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2016-12-19 20:33 +0000 |
| Message-ID | <o39g4u$n27$1@dont-email.me> |
| In reply to | #53434 |
On 12/19/2016 18:10, hughaguilar96@gmail.com wrote: > On Monday, December 19, 2016 at 6:06:37 AM UTC-7, Albert van der > Horst wrote: >> Not only had Marcel Hendrix the transputer Forth running before we >> had the hardware (he wrote an emulator), once we had the hardware >> it was very nearly ANS compliance because there were preliminary >> documents. A few day after it was rubber stamped transputer Forth >> was fully ANS compliant. > > The concept of "fully ANS-Forth compliant" is utter nonsense --- > ANS-Forth has ambiguities. Most standards have ambiguities. There's even an IETF RFC for describing how to write specifications that have ambiguities; https://www.ietf.org/rfc/rfc2119.txt. See SHOULD, SHOULD NOT and MAY. Many standards use this RFC to make it clear when a specification has grey areas. > > The ANS-Forth document is full of phrases such as: "may or may not," > "implementation defined," "ambiguous," etc. --- all of these > represent forks in the design --- we have multiple contradictory > designs all of which have some basis in the ANS-Forth document to > support their claim of being compliant. > Ambiguities around Forth specifications don't stop people from writing ANS compliant code, while allowing compiler writers to implement efficient compilation environments on a variety of platforms. For someone who has already dismissed ANS Forth as useless, I am amazed that you need to continue to tell everyone, at length and every day, that it's grinding your gears. We get it. You can stop now. -- Alex
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-12-19 18:11 -0800 |
| Message-ID | <932bc6cf-7c0b-4e88-af6f-aea4186f747d@googlegroups.com> |
| In reply to | #53437 |
On Monday, December 19, 2016 at 1:33:57 PM UTC-7, Alex wrote: > For someone who has already dismissed ANS Forth as useless, I am amazed > that you need to continue to tell everyone, at length and every day, > that it's grinding your gears. We get it. You can stop now. Elizabeth Rather and her sycophants can stop claiming to be the leaders of the Forth community -- now would be a good time. The only way that Forth can succeed is for ANS-Forth to be defeated --- ANS-Forth was a steaming pile of salesmanship in 1994 and it continues to reek decades later --- it is time to press the flush lever and send ANS-Forth to its proper destination. In the 1980s the Forth enthusiasts did a lot of talk about how in Forth "anything is possible." The irony of this is that ANS-Forth came out in 1994 with a lot of ambiguity, meaning that almost any Forth implementation was ANS-Forth compliant, even if these implementations were contradictory to each other. Now in 2016, despite the fact that "anything is possible," the Forth-200x committee are incapable of writing basic software. For example, they don't know how to convert floats into strings. VFX also has a bug in its outer-interpreter code that converts strings into floats. That is pathetic! I write Forth code that works correctly, but the Forth-200x committee ignores it because Elizabeth Rather says that I'm not a Forth programmer. That is pathetic! ANS-Forth and Forth-200x must be flushed if Forth is going to be taken seriously in the real world.
[toc] | [prev] | [next] | [standalone]
| From | Julian Fondren <julian.fondren@gmail.com> |
|---|---|
| Date | 2016-12-19 19:03 -0800 |
| Message-ID | <7846c510-224b-4780-897b-d31ce7a5ac09@googlegroups.com> |
| In reply to | #53438 |
On Monday, December 19, 2016 at 8:11:42 PM UTC-6, hughag...@gmail.com wrote: > it is time to press the flush lever and send ANS-Forth to its proper destination. OK sure. You've convinced me, for real. I never liked ANSI anyway. So what, specifically, should I do? Waiting anxiously for your answer.
[toc] | [prev] | [next] | [standalone]
| From | Gerry Jackson <gerry@jackson9000.fsnet.co.uk> |
|---|---|
| Date | 2016-12-20 08:10 +0000 |
| Message-ID | <o3aov6$f28$1@dont-email.me> |
| In reply to | #53439 |
On 20/12/2016 03:03, Julian Fondren wrote: > On Monday, December 19, 2016 at 8:11:42 PM UTC-6, hughag...@gmail.com wrote: >> it is time to press the flush lever and send ANS-Forth to its proper destination. > > OK sure. You've convinced me, for real. I never liked ANSI anyway. > > So what, specifically, should I do? > > Waiting anxiously for your answer. > http://pcwww.liv.ac.uk/~pgro/TPM/procrastination.htm Perhaps continually slagging off ANS Forth, Forth 200X and its committee and other Forthers is the equivalent of 'sorting the screws in the garage' when developing StraightForth should be the priority. -- Gerry
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-12-20 18:05 -0800 |
| Message-ID | <d45ba0be-dd8b-413e-8a78-ff9a428a4fed@googlegroups.com> |
| In reply to | #53440 |
On Tuesday, December 20, 2016 at 1:10:37 AM UTC-7, Gerry wrote: > http://pcwww.liv.ac.uk/~pgro/TPM/procrastination.htm > > Perhaps continually slagging off ANS Forth, Forth 200X and its committee > and other Forthers is the equivalent of 'sorting the screws in the > garage' when developing StraightForth should be the priority. I am working on Straight Forth --- all this code that I write, such as STR>NUM etc., will go into Straight Forth --- code such as STR>NUM wasn't the work of one day (and, I should point out, the Forth-200x committee has been in existence for decades but have yet failed to write anything comparable to STR>NUM that I wrote in 3 days). It takes a while to get comfortable with a design for Straight Forth. Recently I began to wonder if my definition of a "number" was good. I have three possibilities for what a "number" is (a "number" is what + - * / etc. act on): A.) A number is a 64-bit fixed-point value with an assumed unity of 2^32 (also, we have mixed-precision functions such as */ that use an intermediate value which is 128-bit with an assumed unity of 2^64) --- this would require the data-stack to be 8 bytes wide. B.) A number is a double-precision IEEE-754 float --- this would require the data-stack to be 8 bytes wide. C.) A number is a pair of 64-bit integers, which are the numerator and denominator --- this would require the data-stack to be 16 bytes wide. I would like to get some input from the Forth community on questions such as this --- I am personally okay with any of the three definitions of "number" --- I would prefer to have some consensus on the question though, rather than impose my own opinion on everybody by fiat. So, what is your opinion? What is a number? P.S. Shining a spotlight on the stupidity of ANS-Forth is always worthwhile --- it is not a waste of time --- Forth can't succeed until ANS-Forth has finally been flushed.
[toc] | [prev] | [next] | [standalone]
| From | Jan Coombs <jenfhaomndgfwutc@murmic.plus.com> |
|---|---|
| Date | 2016-12-21 09:04 +0000 |
| Subject | Re: f.) for Gorth - what is a number? |
| Message-ID | <20161221090412.6370626c@t530.lan> |
| In reply to | #53459 |
On Tue, 20 Dec 2016 18:05:03 -0800 (PST) hughaguilar96@gmail.com wrote: > It takes a while to get comfortable with a design for Straight > Forth. Recently I began to wonder if my definition of a > "number" was good. I have three possibilities for what a > "number" is (a "number" is what + - * / etc. act on): > > A.) A number is a 64-bit fixed-point value with an assumed > unity of 2^32 (also, we have mixed-precision functions such as > */ that use an intermediate value which is 128-bit with an > assumed unity of 2^64) --- this would require the data-stack > to be 8 bytes wide. > > B.) A number is a double-precision IEEE-754 float --- this > would require the data-stack to be 8 bytes wide. > > C.) A number is a pair of 64-bit integers, which are the > numerator and denominator --- this would require the > data-stack to be 16 bytes wide. > > I would like to get some input from the Forth community on > questions such as this --- I am personally okay with any of > the three definitions of "number" --- I would prefer to have > some consensus on the question though, rather than impose my > own opinion on everybody by fiat. If you tag items and make them variable length you can save significant power by reducing memory traffic. Stack languages have a great advantage here, in that the stack need not be indexed or accessed outside the top few items. All three of the above approaches could benefit from this, for example, C.) might only require two bytes for small integers and simple fractions. If you design the hardware, then A.), B.), and BigNums could be combined into the single unum data type [1][2]. > So, what is your opinion? What is a number? It would be good to see the end of 'f~' and other complexities inflicted by the current float format, and have all simple numeric data types combined into one single type, unum. Jan Coombs -- [1] good old summary, many links: https://github.com/tbreloff/Unums.jl/wiki/Unum-Summary-(in-progress) [2] slide show: http://www.johngustafson.net/presentations/Right-SizingPrecision1.pdf
[toc] | [prev] | [next] | [standalone]
Page 6 of 8 — ← Prev page 1 2 3 4 5 [6] 7 8 Next page →
Back to top | Article view | comp.lang.forth
csiph-web