Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #47022 > unrolled thread
| Started by | murphy.darin@gmail.com |
|---|---|
| First post | 2016-05-11 13:54 -0700 |
| Last post | 2016-05-16 05:35 +0000 |
| Articles | 20 on this page of 91 — 18 participants |
Back to article view | Back to comp.lang.forth
Looking for some help with this gforth program. Thanks! murphy.darin@gmail.com - 2016-05-11 13:54 -0700
Re: Looking for some help with this gforth program. Thanks! all2001@spambog.com (Wolfgang Allinger) - 2016-05-11 17:59 -0300
Re: Looking for some help with this gforth program. Thanks! hughaguilar96@gmail.com - 2016-05-11 19:16 -0700
Re: Looking for some help with this gforth program. Thanks! murphy.darin@gmail.com - 2016-05-11 19:40 -0700
Re: Looking for some help with this gforth program. Thanks! Paul Rubin <no.email@nospam.invalid> - 2016-05-11 23:22 -0700
Re: Looking for some help with this gforth program. Thanks! murphy.darin@gmail.com - 2016-05-12 00:01 -0700
Re: Looking for some help with this gforth program. Thanks! hughaguilar96@gmail.com - 2016-05-12 00:08 -0700
Re: Looking for some help with this gforth program. Thanks! murphy.darin@gmail.com - 2016-05-12 12:09 -0700
Re: Looking for some help with this gforth program. Thanks! rickman <gnuarm@gmail.com> - 2016-05-12 20:48 -0400
Re: Looking for some help with this gforth program. Thanks! murphy.darin@gmail.com - 2016-05-12 18:04 -0700
Re: Looking for some help with this gforth program. Thanks! rickman <gnuarm@gmail.com> - 2016-05-12 21:21 -0400
Re: Looking for some help with this gforth program. Thanks! Cecil Bayona <cbayona@cbayona.com> - 2016-05-12 20:27 -0500
Re: Looking for some help with this gforth program. Thanks! Paul Rubin <no.email@nospam.invalid> - 2016-05-12 18:46 -0700
Re: Looking for some help with this gforth program. Thanks! Cecil Bayona <cbayona@cbayona.com> - 2016-05-12 23:28 -0500
Re: Looking for some help with this gforth program. Thanks! murphy.darin@gmail.com - 2016-05-13 00:52 -0700
Re: Looking for some help with this gforth program. Thanks! Pablo Hugo Reda <pabloreda@gmail.com> - 2016-05-13 04:07 -0700
Re: Looking for some help with this gforth program. Thanks! rickman <gnuarm@gmail.com> - 2016-05-14 00:42 -0400
Re: Looking for some help with this gforth program. Thanks! murphy.darin@gmail.com - 2016-05-14 00:05 -0700
Re: Looking for some help with this gforth program. Thanks! rickman <gnuarm@gmail.com> - 2016-05-15 00:10 -0400
Re: Looking for some help with this gforth program. Thanks! anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-05-15 10:34 +0000
Re: Looking for some help with this gforth program. Thanks! rickman <gnuarm@gmail.com> - 2016-05-15 09:43 -0400
Re: Looking for some help with this gforth program. Thanks! anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-05-16 12:21 +0000
Re: Looking for some help with this gforth program. Thanks! hughaguilar96@gmail.com - 2016-05-16 07:38 -0700
Re: Looking for some help with this gforth program. Thanks! anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-05-16 14:56 +0000
Re: Looking for some help with this gforth program. Thanks! rickman <gnuarm@gmail.com> - 2016-05-16 12:07 -0400
Re: Looking for some help with this gforth program. Thanks! Paul Rubin <no.email@nospam.invalid> - 2016-05-16 09:18 -0700
Re: Looking for some help with this gforth program. Thanks! Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-05-16 13:19 -0500
Re: Looking for some help with this gforth program. Thanks! anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-05-17 12:39 +0000
Re: Looking for some help with this gforth program. Thanks! Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-05-17 10:34 -0500
Re: Looking for some help with this gforth program. Thanks! anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-05-17 15:54 +0000
Re: Looking for some help with this gforth program. Thanks! mhx@iae.nl - 2016-05-17 12:44 -0700
Re: Looking for some help with this gforth program. Thanks! hughaguilar96@gmail.com - 2016-05-15 11:03 -0700
Re: Looking for some help with this gforth program. Thanks! rickman <gnuarm@gmail.com> - 2016-05-15 21:56 -0400
Re: Looking for some help with this gforth program. Thanks! Paul Rubin <no.email@nospam.invalid> - 2016-05-15 19:02 -0700
Re: Looking for some help with this gforth program. Thanks! hughaguilar96@gmail.com - 2016-05-15 20:03 -0700
Re: Looking for some help with this gforth program. Thanks! rickman <gnuarm@gmail.com> - 2016-05-16 02:13 -0400
Re: Looking for some help with this gforth program. Thanks! murphy.darin@gmail.com - 2016-05-16 00:37 -0700
Re: Looking for some help with this gforth program. Thanks! anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-05-16 13:41 +0000
Re: Looking for some help with this gforth program. Thanks! Bernd Paysan <bernd.paysan@gmx.de> - 2016-05-16 21:42 +0000
Re: Looking for some help with this gforth program. Thanks! hughaguilar96@gmail.com - 2016-05-16 16:23 -0700
Re: Looking for some help with this gforth program. Thanks! Paul Rubin <no.email@nospam.invalid> - 2016-05-16 16:41 -0700
Re: Looking for some help with this gforth program. Thanks! murphy.darin@gmail.com - 2016-05-16 20:32 -0700
Re: Looking for some help with this gforth program. Thanks! murphy.darin@gmail.com - 2016-05-16 20:47 -0700
Re: Looking for some help with this gforth program. Thanks! anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-05-17 06:32 +0000
Re: Looking for some help with this gforth program. Thanks! Paul Rubin <no.email@nospam.invalid> - 2016-05-17 07:56 -0700
Re: Looking for some help with this gforth program. Thanks! Bernd Paysan <bernd.paysan@gmx.de> - 2016-05-17 23:05 +0000
Re: Looking for some help with this gforth program. Thanks! Paul Rubin <no.email@nospam.invalid> - 2016-05-17 21:16 -0700
Re: Looking for some help with this gforth program. Thanks! Bernd Paysan <bernd.paysan@gmx.de> - 2016-06-04 22:44 +0000
Re: Looking for some help with this gforth program. Thanks! anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-05-17 13:42 +0000
Re: Looking for some help with this gforth program. Thanks! Bernd Paysan <bernd.paysan@gmx.de> - 2016-05-17 22:31 +0000
Re: Looking for some help with this gforth program. Thanks! anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-05-18 16:43 +0000
Re: Looking for some help with this gforth program. Thanks! Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-05-16 10:38 -0500
Re: Looking for some help with this gforth program. Thanks! Paul Rubin <no.email@nospam.invalid> - 2016-05-16 10:10 -0700
Re: Looking for some help with this gforth program. Thanks! Cecil Bayona <cbayona@cbayona.com> - 2016-05-16 12:29 -0500
Re: Looking for some help with this gforth program. Thanks! Cecil Bayona <cbayona@cbayona.com> - 2016-05-16 12:34 -0500
Re: Looking for some help with this gforth program. Thanks! Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-05-16 13:27 -0500
Re: Looking for some help with this gforth program. Thanks! Paul Rubin <no.email@nospam.invalid> - 2016-05-17 16:11 -0700
Re: Looking for some help with this gforth program. Thanks! Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-05-18 04:31 -0500
Re: Looking for some help with this gforth program. Thanks! Albert van der Horst <albert@cherry.spenarnc.xs4all.nl> - 2016-05-16 18:46 +0000
Re: Looking for some help with this gforth program. Thanks! murphy.darin@gmail.com - 2016-05-14 00:07 -0700
Re: Looking for some help with this gforth program. Thanks! murphy.darin@gmail.com - 2016-05-14 00:20 -0700
Re: Looking for some help with this gforth program. Thanks! Paul Rubin <no.email@nospam.invalid> - 2016-05-14 01:23 -0700
Re: Looking for some help with this gforth program. Thanks! rickman <gnuarm@gmail.com> - 2016-05-15 00:13 -0400
Re: Looking for some help with this gforth program. Thanks! Paul Rubin <no.email@nospam.invalid> - 2016-05-14 21:55 -0700
Re: Looking for some help with this gforth program. Thanks! Paul Rubin <no.email@nospam.invalid> - 2016-05-11 17:08 -0700
Re: Looking for some help with this gforth program. Thanks! murphy.darin@gmail.com - 2016-05-11 17:40 -0700
Re: Looking for some help with this gforth program. Thanks! murphy.darin@gmail.com - 2016-05-11 18:54 -0700
Re: Looking for some help with this gforth program. Thanks! Doug Hoffman <glidedog@gmail.com> - 2016-05-13 06:55 -0400
Re: Looking for some help with this gforth program. Thanks! murphy.darin@gmail.com - 2016-05-13 11:07 -0700
Re: Looking for some help with this gforth program. Thanks! hughaguilar96@gmail.com - 2016-05-13 20:42 -0700
Re: Looking for some help with this gforth program. Thanks! murphy.darin@gmail.com - 2016-05-13 20:57 -0700
Re: Looking for some help with this gforth program. Thanks! Doug Hoffman <glidedog@gmail.com> - 2016-05-14 05:54 -0400
Re: Looking for some help with this gforth program. Thanks! hughaguilar96@gmail.com - 2016-05-14 15:20 -0700
Re: Looking for some help with this gforth program. Thanks! Doug Hoffman <glidedog@gmail.com> - 2016-05-15 05:45 -0400
Re: Looking for some help with this gforth program. Thanks! hughaguilar96@gmail.com - 2016-05-15 11:21 -0700
Re: Looking for some help with this gforth program. Thanks! hughaguilar96@gmail.com - 2016-05-15 11:39 -0700
Re: Looking for some help with this gforth program. Thanks! hughaguilar96@gmail.com - 2016-05-11 20:45 -0700
Re: Looking for some help with this gforth program. Thanks! hughaguilar96@gmail.com - 2016-05-11 23:05 -0700
Re: Looking for some help with this gforth program. Thanks! murphy.darin@gmail.com - 2016-05-11 23:15 -0700
Re: Looking for some help with this gforth program. Thanks! rickman <gnuarm@gmail.com> - 2016-05-12 22:34 -0400
Re: Looking for some help with this gforth program. Thanks! murphy.darin@gmail.com - 2016-05-11 23:11 -0700
Re: Looking for some help with this gforth program. Thanks! november.nihal@gmail.com - 2016-05-11 19:00 -0700
Re: Looking for some help with this gforth program. Thanks! murphy.darin@gmail.com - 2016-05-11 19:14 -0700
Re: Looking for some help with this gforth program. Thanks! humptydumpty <ouatubi@gmail.com> - 2016-05-12 01:48 -0700
Re: Looking for some help with this gforth program. Thanks! Doug Hoffman <glidedog@gmail.com> - 2016-05-12 07:43 -0400
Re: Looking for some help with this gforth program. Thanks! humptydumpty <ouatubi@gmail.com> - 2016-05-12 10:21 -0700
Re: Looking for some help with this gforth program. Thanks! murphy.darin@gmail.com - 2016-05-12 12:11 -0700
Re: Looking for some help with this gforth program. Thanks! "Ala'a" <amalawi@gmail.com> - 2016-05-12 14:34 -0700
Re: Looking for some help with this gforth program. Thanks! murphy.darin@gmail.com - 2016-05-12 16:20 -0700
Re: Looking for some help with this gforth program. Thanks! Marcos Cruz <use_the_contact_page@programandala.net> - 2016-05-14 12:27 +0000
Re: Looking for some help with this gforth program. Thanks! "WJ" <w_a_x_man@yahoo.com> - 2016-05-16 05:35 +0000
Page 4 of 5 — ← Prev page 1 2 3 [4] 5 Next page →
| From | murphy.darin@gmail.com |
|---|---|
| Date | 2016-05-14 00:20 -0700 |
| Message-ID | <9621ce4b-2b0d-459d-8622-a34e6c1ebd4e@googlegroups.com> |
| In reply to | #47113 |
Also I haven't ruled out using an arduino either. They are more basic and not very powerful, but that could be a good place to be since they are extremely well documented and I'm still super newbie with forth. I'm also not in a rush for either and can still learn as I go with my raspberri Pi and my tablet. Anyway I'm not looking for the impossible, just learning and researching as I go until something clicks. Take care now. :)
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2016-05-14 01:23 -0700 |
| Message-ID | <87h9e1oxnx.fsf@jester.gateway.pace.com> |
| In reply to | #47115 |
murphy.darin@gmail.com writes: > Also I haven't ruled out using an arduino either. They are more basic > and not very powerful, but that could be a good place to be since they > are extremely well documented It's not just documentation--they're orders of magnitude simpler than something like an rpi. If you want an ARM you could consider something like Mecrisp on a Stellaris launchpad or the like. That would be more complicated than an Arduino but still way simpler than a Pi. Mecrisp runs on the Stellaris (and similar) bare metal directly.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-05-15 00:13 -0400 |
| Message-ID | <nh8sqb$83l$3@dont-email.me> |
| In reply to | #47117 |
On 5/14/2016 4:23 AM, Paul Rubin wrote: > murphy.darin@gmail.com writes: >> Also I haven't ruled out using an arduino either. They are more basic >> and not very powerful, but that could be a good place to be since they >> are extremely well documented > > It's not just documentation--they're orders of magnitude simpler than > something like an rpi. If you want an ARM you could consider something > like Mecrisp on a Stellaris launchpad or the like. That would be more > complicated than an Arduino but still way simpler than a Pi. Mecrisp > runs on the Stellaris (and similar) bare metal directly. I am using Mecrisp, but if you want to poke or at minimum learn under the hood, Mecrisp has a lot of German documentation which can impede that somewhat. I have yet to find a good translation site for technical lingo in German. I tried asking a native German speaker I know and still didn't get much traction on a few things. One of my longer term goals is to fully translate the German comments from a version of Mecrisp, but it will be further down the road a bit. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2016-05-14 21:55 -0700 |
| Message-ID | <874m9zq5si.fsf@jester.gateway.pace.com> |
| In reply to | #47133 |
rickman <gnuarm@gmail.com> writes: > I am using Mecrisp, but if you want to poke or at minimum learn under > the hood, Mecrisp has a lot of German documentation which can impede > that somewhat. I don't remember noticing that, but Mecrisp itself is written mostly in assembly language, which I think makes it less attractive as a study target than a traditional Forth-in-Forth implementation. It's also quite advanced, generating subroutine-threaded code with a significant amount of optimization. From a user perspective that's all great, but from a "here's how Forth is implemented" perspective, eforth is a lot easier to understand. > I have yet to find a good translation site for technical lingo in > German. Google Translate didn't help? > One of my longer term goals is to fully translate the German comments > from a version of Mecrisp, but it will be further down the road a bit. That will be nice.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2016-05-11 17:08 -0700 |
| Message-ID | <87y47g5ea6.fsf@jester.gateway.pace.com> |
| In reply to | #47022 |
murphy.darin@gmail.com writes: > other times I get garbage and a "stack underflow" error. Wolfgang made good suggestions. Another gforth-specific tip: the word "~~" (two tilde characters) prints the stack contents along with a diagnostic saying where in the program the message came from. That is good for debugging: you put ~~ into places in your program where you want to trace what is going on. At a higher level, I see a lot of duplicated code between those (penny, nickel, etc.) The idea of "factoring" is to put the duplicated stuff into subroutines that are defined just once, which you can then call from multiple places.
[toc] | [prev] | [next] | [standalone]
| From | murphy.darin@gmail.com |
|---|---|
| Date | 2016-05-11 17:40 -0700 |
| Message-ID | <66aa756c-27b3-4269-9615-01f607f01702@googlegroups.com> |
| In reply to | #47024 |
Thank you both Paul and Wolfram. I really appreciate the useful information. I know what I've done is way more complicated than it should be and that's why it's not working I'm sure. I've decided to rewrite the whole thing taking the information and suggestions you both of given. I'm sure the second one will be a lot better than the first. LOL! Anyway I really appreciate the help! Take care now.
[toc] | [prev] | [next] | [standalone]
| From | murphy.darin@gmail.com |
|---|---|
| Date | 2016-05-11 18:54 -0700 |
| Message-ID | <3072d36e-cc05-4a58-b2e9-b31d735adea1@googlegroups.com> |
| In reply to | #47025 |
Whew I finally got it pretty much working correctly. Here's my code: : comma ( -- ) ." , " ; : penny ( n -- ) ?dup 1 > if . ." pennies" else . ." penny" then ; : nickel ( n -- possibly n ) 5 /mod ?dup 0= if penny else . ." nickel" ?dup 0 > if comma penny then then ; : dime ( n -- possibly n ) . ." dime" ?dup 0 > if comma nickel then ; : dimes ( n -- possibly n ) . ." dimes" ?dup 0 > if comma nickel then ; : 10-cent ( n -- possibly n ) 10 /mod ?dup 0= if nickel else dup 1 > if dimes else dime then then ; : quarter ( n -- possibly n ) . ." quarter" ?dup 0 > if comma 10-cent then ; : quarters ( n -- possibly n ) . ." quarters" ?dup 0 > if comma 10-cent then ; : 25-cent ( n -- possibly n ) 25 /mod ?dup 0= if 10-cent else dup 1 > if quarters else quarter then then ; : dollar ( n -- possibly n ) . ." dollar" ?dup 0 > if comma 25-cent then ; : dollars ( n -- possibly n ) . ." dollars" ?dup 0 > if comma 25-cent then ; : 100-cent ( n -- possibly n ) 100 /mod ?dup 0= if 25-cent else dup 1 > if dollars else dollar then then ; : five ( n -- possibly n ) . ." five" ?dup 0 > if comma 100-cent then ; : fives ( n -- possibly n ) . ." fives" ?dup 0 > if comma 100-cent then ; : 500-cent ( n -- possibly n ) 500 /mod ?dup 0= if 100-cent else dup 1 > if fives else five then then ; : ten ( n -- possibly n ) . ." ten" ?dup 0 > if comma 500-cent then ; : tens ( n -- possibly n ) . ." tens" ?dup 0 > if comma 500-cent then ; : 1000-cent ( n -- possibly n ) 1000 /mod ?dup 0= if 500-cent else dup 1 > if tens else ten then then ; : twenty ( n -- possibly n ) . ." twenty" ?dup 0 > if comma 1000-cent then ; : twenties ( n -- possibly n ) . ." twenties" ?dup 0 > if comma 1000-cent then ; : 2000-cent ( n -- possibly n ) 2000 /mod ?dup 0= if 1000-cent else dup 1 > if twenties else twenty then then ; : fifty ( n -- possibly n ) . ." fifty" ?dup 0 > if comma 2000-cent then ; : fifties ( n -- possibly n ) . ." fifties" ?dup 0 > if comma 2000-cent then ; : 5000-cent ( n -- possibly n ) 5000 /mod ?dup 0= if 2000-cent else dup 1 > if fifties else fifty then then ; : hundred ( n -- possibly n ) . ." hundred" ?dup 0 > if comma 5000-cent then ; : hundreds ( n -- possibly n ) . ." hundreds" ?dup 0 > if comma 5000-cent then ; : 10000-cent ( n -- possibly n ) 10000 /mod ?dup 0= if 5000-cent else dup 1 > if hundreds else hundred then then ; : pennies-exchange ( n -- ) ?dup 0 = if ." ERROR - Must enter a number greater than 0!" 10000-cent then ; I think it looks a lot clearer, although I'm sure it still needs fix for the -1 issue with the ifs and also a lot more refactoring. It's the first forth program I've ever created and as my experience and knowledge of forth increases I'll be go back and reworking it so I can see my own progress. Thanks again Paul and Wolfgang for all of your guidance and wiliness to help a newbie. Take care now.
[toc] | [prev] | [next] | [standalone]
| From | Doug Hoffman <glidedog@gmail.com> |
|---|---|
| Date | 2016-05-13 06:55 -0400 |
| Message-ID | <5735b29f$0$292$14726298@news.sunsite.dk> |
| In reply to | #47026 |
On 5/11/16 9:54 PM, murphy.darin@gmail.com wrote:
> Whew I finally got it pretty much working correctly. Here's my code:
>
> : comma ( -- ) ." , " ;
>
> : penny ( n -- ) ?dup 1 > if . ." pennies" else . ." penny" then ;
>
> : nickel ( n -- possibly n ) 5 /mod ?dup 0= if penny else . ." nickel" ?dup 0 > if comma penny then then ;
>
> : dime ( n -- possibly n ) . ." dime" ?dup 0 > if comma nickel then ;
> : dimes ( n -- possibly n ) . ." dimes" ?dup 0 > if comma nickel then ;
> : 10-cent ( n -- possibly n ) 10 /mod ?dup 0= if nickel else dup 1 > if dimes else dime then then ;
>
> : quarter ( n -- possibly n ) . ." quarter" ?dup 0 > if comma 10-cent then ;
> : quarters ( n -- possibly n ) . ." quarters" ?dup 0 > if comma 10-cent then ;
> : 25-cent ( n -- possibly n ) 25 /mod ?dup 0= if 10-cent else dup 1 > if quarters else quarter then then ;
>
> : dollar ( n -- possibly n ) . ." dollar" ?dup 0 > if comma 25-cent then ;
> : dollars ( n -- possibly n ) . ." dollars" ?dup 0 > if comma 25-cent then ;
> : 100-cent ( n -- possibly n ) 100 /mod ?dup 0= if 25-cent else dup 1 > if dollars else dollar then then ;
>
> : five ( n -- possibly n ) . ." five" ?dup 0 > if comma 100-cent then ;
> : fives ( n -- possibly n ) . ." fives" ?dup 0 > if comma 100-cent then ;
> : 500-cent ( n -- possibly n ) 500 /mod ?dup 0= if 100-cent else dup 1 > if fives else five then then ;
>
> : ten ( n -- possibly n ) . ." ten" ?dup 0 > if comma 500-cent then ;
> : tens ( n -- possibly n ) . ." tens" ?dup 0 > if comma 500-cent then ;
> : 1000-cent ( n -- possibly n ) 1000 /mod ?dup 0= if 500-cent else dup 1 > if tens else ten then then ;
>
> : twenty ( n -- possibly n ) . ." twenty" ?dup 0 > if comma 1000-cent then ;
> : twenties ( n -- possibly n ) . ." twenties" ?dup 0 > if comma 1000-cent then ;
> : 2000-cent ( n -- possibly n ) 2000 /mod ?dup 0= if 1000-cent else dup 1 > if twenties else twenty then then ;
>
> : fifty ( n -- possibly n ) . ." fifty" ?dup 0 > if comma 2000-cent then ;
> : fifties ( n -- possibly n ) . ." fifties" ?dup 0 > if comma 2000-cent then ;
> : 5000-cent ( n -- possibly n ) 5000 /mod ?dup 0= if 2000-cent else dup 1 > if fifties else fifty then then ;
>
> : hundred ( n -- possibly n ) . ." hundred" ?dup 0 > if comma 5000-cent then ;
> : hundreds ( n -- possibly n ) . ." hundreds" ?dup 0 > if comma 5000-cent then ;
> : 10000-cent ( n -- possibly n ) 10000 /mod ?dup 0= if 5000-cent else dup 1 > if hundreds else hundred then then ;
>
> : pennies-exchange ( n -- ) ?dup 0 = if ." ERROR - Must enter a number greater than 0!" 10000-cent then ;
Looking at the above it is clear that the same calculation is used
repeatedly, only with different parameters. So how to (easily) convert
the above to a solution with the approach of defining each calculation
just once, and then varying only the data used?
Objects are one way. I see nine "money" objects that perform the same
calculations but just use different data, some of those data are other
money objects:
100-dollar
50-dollar
20-dollar
10-dollar
5-dollar
dollar
quarter
dime
nickel
Instance variables:
divisor \ 25 for quarter
smaller-money-object \ dime for quarter
singular-name \ e.g. twenty
plural-name \ e.g. twenties
The nickel object would behave slightly differently, so only two classes
of money objects are required.
A penny object is not needed, so it would remain a function call as above.
It isn't the shortest solution. But it retains all of your
calculations with no repetition and with factoring.
Should be easy to maintain.
The supporting oop extension is just 33 loc yet has more
features than needed here (inheritance, super, heap based
objects etc). Standard code, will run on any ANS Forth.
On speed tests it ran the same as Humpty's code, so the screen output
is the bottleneck.
You say you will be programming in Python. Might be a good idea to get
used to programming with objects and messages.
-Doug
\ Needs the microFMS extension located here:
\ http://soton.mpeforth.com/flag/fms/microFMS.f
create string <super object
8 bytes text
cell bytes len
:m !: ( addr len -- ) dup len ! text swap move ;m
:m p: ( -- ) text len @ type ;m
set-order
: comma ( -- ) ." , " ;
sel compute
create money <super object
cell bytes divisor
cell bytes smaller-money
cell bytes plural-name
cell bytes single-name
:m init: ( divisor smaller-money-obj paddr plen saddr slen -- )
string >dict dup >r plural-name ! string >dict dup single-name !
!: r> !: smaller-money ! divisor ! ;m
: poss ( possibly -- )
?dup 0 > if comma smaller-money @ compute then ;
:m single ( n -- possibly n ) . single-name @ p: poss ;m
:m plural ( n -- possibly n ) . plural-name @ p: poss ;m
:m compute ( n -- possibly n ) divisor @ /mod ?dup 0=
if smaller-money @ compute else dup 1 >
if self plural else self single then then ;m
set-order
: penny ( n -- )
dup 1 > if . ." pennies" else dup 0 > if . ." penny" then then ;
create nickel-class <super object
:m compute ( n -- possibly n )
5 /mod ?dup 0= if penny else . ." nickel"
?dup 0 > if comma penny then then ;m
set-order
: :: >dict constant ;
\ create the objects, each with its own data
nickel-class :: nickel
10 nickel s" dimes" s" dime" money :: dime
25 dime s" quarters" s" quarter" money :: quarter
100 quarter s" dollars" s" dollar" money :: dollar
500 dollar s" five" 2dup money :: 5-dollar
1000 5-dollar s" ten" 2dup money :: 10-dollar
2000 10-dollar s" twenties" s" twenty" money :: 20-dollar
5000 20-dollar s" fifty" 2dup money :: 50-dollar
10000 50-dollar s" hundreds" s" hundred" money :: 100-dollar
: pennies-exchange ( n -- )
dup 1 < if ." ERROR - Must enter a number greater than 0!" drop
else 100-dollar compute then ;
[toc] | [prev] | [next] | [standalone]
| From | murphy.darin@gmail.com |
|---|---|
| Date | 2016-05-13 11:07 -0700 |
| Message-ID | <b22ff1e4-3e83-421f-bed7-3a08cdb3fbb4@googlegroups.com> |
| In reply to | #47080 |
Thank you Doug for showing the OOP version of "pennies-exchange". I'll be sure the add your's to the collection too! This way I have a good idea about the many faces forth can take to get the problem resolved. My classes at UOPeople will be using Python and Java exclusively I think, so I'm going to be spending a lot of time with OOP. It's interesting to see how flexible forth is that it can change in so many ways. I think I've read that it can also be changeed into a purely functional too! Forth is truly an amazing language and I'm looking forward to seeing where it can take me. Take care now.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-05-13 20:42 -0700 |
| Message-ID | <f657e5c7-c22b-4e69-8732-e60e2a2e447f@googlegroups.com> |
| In reply to | #47080 |
On Friday, May 13, 2016 at 3:55:30 AM UTC-7, Doug Hoffman wrote: > Looking at the above it is clear that the same calculation is used > repeatedly, only with different parameters. So how to (easily) convert > the above to a solution with the approach of defining each calculation > just once, and then varying only the data used? > > Objects are one way. I don't think OOP is a good idea in Forth. I don't use OOP in Forth, and I certainly don't recommend it to novices. > You say you will be programming in Python. Might be a good idea to get > used to programming with objects and messages. There are plenty of OOP languages, and Python is one of them --- if you want OOP, then use an OOP language.
[toc] | [prev] | [next] | [standalone]
| From | murphy.darin@gmail.com |
|---|---|
| Date | 2016-05-13 20:57 -0700 |
| Message-ID | <d5085403-751c-4b9d-af1d-f0798ff2ef9e@googlegroups.com> |
| In reply to | #47104 |
Hughag I agree with you. I think learning the fundamentals of forth is quite enough and mixing paradigms will only make things more confusing for me. I do not know enough about forth yet to understand if OOP adds anything useful to make up for the added complexity. I am trying to focus on keeping things as simple and easy to digest as possible. Thank you for your advice. Take care now.
[toc] | [prev] | [next] | [standalone]
| From | Doug Hoffman <glidedog@gmail.com> |
|---|---|
| Date | 2016-05-14 05:54 -0400 |
| Message-ID | <5736f5f1$0$300$14726298@news.sunsite.dk> |
| In reply to | #47104 |
On 5/13/16 11:42 PM, hughaguilar96@gmail.com wrote: > On Friday, May 13, 2016 at 3:55:30 AM UTC-7, Doug Hoffman wrote: >> Looking at the above it is clear that the same calculation is used >> repeatedly, only with different parameters. So how to (easily) convert >> the above to a solution with the approach of defining each calculation >> just once, and then varying only the data used? >> >> Objects are one way. > > I don't think OOP is a good idea in Forth. Why, unless perhaps doing embedded work? > ... and I certainly don't recommend it to novices. Novices to *programming* I will agree. I didn't know he was a programming novice. Novices to Forth, but experienced in programming, I will disagree. >> You say you will be programming in Python. Might be a good idea to get >> used to programming with objects and messages. > > There are plenty of OOP languages, and Python is one of them --- if > you want OOP, then use an OOP language. In Forth we extend the language to have the needed capability to solve the problem at hand. We don't as a rule just switch to another language that has the missing capability already there. With that mind set not many Forth programs would be written. -Doug
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-05-14 15:20 -0700 |
| Message-ID | <ae806af3-0662-4e48-b276-a988d948a7cf@googlegroups.com> |
| In reply to | #47119 |
On Saturday, May 14, 2016 at 2:54:59 AM UTC-7, Doug Hoffman wrote: > On 5/13/16 11:42 PM, hughaguilar96@gmail.com wrote: > > On Friday, May 13, 2016 at 3:55:30 AM UTC-7, Doug Hoffman wrote: > >> Looking at the above it is clear that the same calculation is used > >> repeatedly, only with different parameters. So how to (easily) convert > >> the above to a solution with the approach of defining each calculation > >> just once, and then varying only the data used? > >> > >> Objects are one way. > > > > I don't think OOP is a good idea in Forth. > > Why, unless perhaps doing embedded work? OOP in Forth is inefficient and over-complicated. Your code, for example, is significantly more complicated than mine. I would never write code like that!
[toc] | [prev] | [next] | [standalone]
| From | Doug Hoffman <glidedog@gmail.com> |
|---|---|
| Date | 2016-05-15 05:45 -0400 |
| Message-ID | <57384537$0$304$14726298@news.sunsite.dk> |
| In reply to | #47127 |
On 5/14/16 6:20 PM, hughaguilar96@gmail.com wrote: > On Saturday, May 14, 2016 at 2:54:59 AM UTC-7, Doug Hoffman wrote: >> On 5/13/16 11:42 PM, hughaguilar96@gmail.com wrote: >>> On Friday, May 13, 2016 at 3:55:30 AM UTC-7, Doug Hoffman wrote: >>>> Looking at the above it is clear that the same calculation is used >>>> repeatedly, only with different parameters. So how to (easily) convert >>>> the above to a solution with the approach of defining each calculation >>>> just once, and then varying only the data used? >>>> >>>> Objects are one way. >>> >>> I don't think OOP is a good idea in Forth. >> >> Why, unless perhaps doing embedded work? > > OOP in Forth is inefficient and over-complicated. Your code, for > example, is significantly more complicated than mine. I hadn't noticed your solution until just now. I like it and agree that it's better than my objects solution. You reworked the computations of the op, I kept them as he wrote them. Efficiency: the objects solution runs 16% faster than your solution (I believe this problem is bottlenecked by screen display, not computation). The objects solution needs additional support, 33 loc in this case. But when that support is always there, as it is for me, I don't count that. Regardless of this one example, I think it's a mistake to dismiss objects in Forth. For certain kinds of problems they can be the best way to go. -Doug
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-05-15 11:21 -0700 |
| Message-ID | <4a44a4aa-8500-43d0-8ed0-2e28dbb86d83@googlegroups.com> |
| In reply to | #47138 |
On Sunday, May 15, 2016 at 2:52:59 AM UTC-7, Doug Hoffman wrote:
> Regardless of this one example, I think it's a mistake to dismiss
> objects in Forth. For certain kinds of problems they can be the
> best way to go.
I use OOP heavily in my novice package. For example, in LIST.4TH I have this:
0
w field .fore
constant list
SwiftForth? [if]
icode init-list ( node -- node )
zero(eax)
eax 0 [ebx] mov
ret
end-code
[else]
macro: init-list ( node -- node )
nil over .fore ! ;
[then]
All list classes use LIST as their parent. For example:
list
w field .line
constant seq
: init-seq ( str node -- node )
init-list >r
hstr r@ .line !
r> ;
: new-seq ( str -- node )
seq alloc
init-seq ;
: <kill-seq> ( node -- )
dup .line @ dealloc
dealloc ;
: kill-seq ( head -- )
each[ <kill-seq> ]each ;
: <clone-seq> ( node -- new-node )
clone-node
dup .line @ hstr over .line ! ;
: clone-seq ( head -- new-head )
nil
swap each[ <clone-seq> link ]each ;
Every class should have an INIT-xxx and a NEW-xxx function associated with it. The NEW-xxx is used to make a new object of that class. The INIT-xxx is used in the INIT-yyy of any child class. For example:
seq
w field .head \ a SEQ of the .LINE string split on comma deliminators
constant decomma
: init-decomma ( str node -- node )
init-seq >r
r@ .line @ count split r@ .head !
r> ;
: new-decomma ( str -- node )
decomma alloc
init-decomma ;
: <kill-decomma> ( node -- )
dup .head @ kill-seq
<kill-seq> ;
: kill-decomma ( head -- )
each[ <kill-decomma> ]each ;
: <clone-decomma> ( head node -- new-head )
<clone-seq>
dup .head @ clone-seq over .head ! ;
: clone-decomma ( head -- new-head )
nil
swap each[ <clone-decomma> link ]each ;
All general-purpose data-structures depend heavily on OOP --- the novice-package is all about providing general-purpose data-structures, so the novice-package uses OOP extensively.
I don't have any OOP package however --- I don't even know what OOP package your example code relies on --- I've never examined any OOP package for Forth, as I have no interest in OOP packages for Forth.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-05-15 11:39 -0700 |
| Message-ID | <4e3761dd-dd28-41d3-a17d-c0c3344b52fc@googlegroups.com> |
| In reply to | #47154 |
On Sunday, May 15, 2016 at 11:21:35 AM UTC-7, hughag...@gmail.com wrote: > 0 > w field .fore > constant list > > SwiftForth? [if] > > icode init-list ( node -- node ) > zero(eax) > eax 0 [ebx] mov > ret > end-code > > [else] > > macro: init-list ( node -- node ) > nil over .fore ! ; > > [then] The reason why I had to resort to assembly-language in SwiftForth is because SwiftForth compilation is too inefficient to be practical. : init-list ( node -- node ) nil over .fore ! ; init-list isn't unique. ok see init-list 4911CF 4 # EBP SUB 83ED04 4911D2 EBX 0 [EBP] MOV 895D00 4911D5 0 # EBX MOV BB00000000 4911DA 4 # EBP SUB 83ED04 4911DD EBX 0 [EBP] MOV 895D00 4911E0 4 [EBP] EBX MOV 8B5D04 4911E3 0 [EBP] EAX MOV 8B4500 4911E6 EAX 0 [EBX] MOV 8903 4911E8 4 [EBP] EBX MOV 8B5D04 4911EB 8 # EBP ADD 83C508 4911EE RET C3 ok I actually wrote quite a lot of SwiftForth-specific assembly-language in the novice package to work around the lack of optimization in SwiftForth compilation of Forth code. I have a switch SwiftForth? that I can turn on for SwiftForth or off for generic ANS-Forth. A program such as SLIDE-RULE.4TH compiled with SwiftForth? on to get all the assembly-language, is significantly faster than it is compiled as ANS-Forth. I don't recall the exact figures, but it is about twice as fast. Even still though, it is less than half the speed of VFX without any assembly-language support. SwiftForth code is so slow as to be unusable --- the speed can be improved with heavy recourse on assembly-language --- the speed is still less than half of VFX though (for the most part, VFX can't be improved with assembly-language because it is already generating the same code that you would write by hand).
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-05-11 20:45 -0700 |
| Message-ID | <7a3b8beb-092f-428f-94c6-4e3eeaad68bc@googlegroups.com> |
| In reply to | #47024 |
On Wednesday, May 11, 2016 at 5:08:19 PM UTC-7, Paul Rubin wrote:
> At a higher level, I see a lot of duplicated code between those (penny,
> nickel, etc.) The idea of "factoring" is to put the duplicated stuff
> into subroutines that are defined just once, which you can then call
> from multiple places.
Here is a version of the program that factors all the duplicated code out:
: ctype ( str -- )
count type ;
: <pennies-break> ( pennies unit plural-str singular-str --- remainder )
>r >r /mod \ -- remainder quotient
dup 1 > if cr . r> ctype r> drop exit then
dup 1 = if cr . r> drop r> ctype exit then
dup 0 = if drop r> r> 2drop exit then
true abort" *** <PENNIES-BREAK> given a negative value *** " ;
: pennies-break ( pennies -- )
dup if 10000 c" hondos" c" hondo" <pennies-break> then
dup if 2000 c" twenties" c" twenty" <pennies-break> then
dup if 1000 c" tens" c" ten" <pennies-break> then
dup if 500 c" fins" c" fin" <pennies-break> then
dup if 100 c" singles" c" single" <pennies-break> then
dup if 25 c" quarters" c" quarter" <pennies-break> then
dup if 10 c" dimes" c" dime" <pennies-break> then
dup if 5 c" nickles" c" nickle" <pennies-break> then
dup if 1 c" pennies" c" penny" <pennies-break> then
drop ;
Note that readability is improved a lot if you line up the code in columns. Google totally screws up the alignment because it displays variable-width characters. If you copy this code and put it in a text-editor however, you will see how it all lines up neatly.
I said previously that functions should be 7 lines or fewer. My PENNIES-BREAK is 10 lines long though. This is okay because all the lines are the same, just with different parameters, so the reader doesn't have more than 7 concepts in his head at once.
I said previously
(https://groups.google.com/forum/#!topic/comp.lang.forth/CYR7FhjYMkg)
that Forth should allow commas within numbers, and only assume that the number is double-precision if the first char is a comma. I provided code to convert strings into numbers like this. If this were how Forth number literals were defined, then my PENNIES-BREAK could be much more readable:
: pennies-break ( pennies -- )
dup if 100,00 c" hondos" c" hondo" <pennies-break> then
dup if 20,00 c" twenties" c" twenty" <pennies-break> then
dup if 10,00 c" tens" c" ten" <pennies-break> then
dup if 5,00 c" fins" c" fin" <pennies-break> then
dup if 1,00 c" singles" c" single" <pennies-break> then
dup if 25 c" quarters" c" quarter" <pennies-break> then
dup if 10 c" dimes" c" dime" <pennies-break> then
dup if 5 c" nickles" c" nickle" <pennies-break> then
dup if 1 c" pennies" c" penny" <pennies-break> then
drop ;
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-05-11 23:05 -0700 |
| Message-ID | <b254b7c4-57eb-42ce-84a3-ee0377ad8d11@googlegroups.com> |
| In reply to | #47031 |
On Wednesday, May 11, 2016 at 8:45:22 PM UTC-7, hughag...@gmail.com wrote: > On Wednesday, May 11, 2016 at 5:08:19 PM UTC-7, Paul Rubin wrote: > > At a higher level, I see a lot of duplicated code between those (penny, > > nickel, etc.) The idea of "factoring" is to put the duplicated stuff > > into subroutines that are defined just once, which you can then call > > from multiple places. > > Here is a version of the program that factors all the duplicated code out: > > : ctype ( str -- ) > count type ; > > : <pennies-break> ( pennies unit plural-str singular-str --- remainder ) > >r >r /mod \ -- remainder quotient > dup 1 > if cr . r> ctype r> drop exit then > dup 1 = if cr . r> drop r> ctype exit then > dup 0 = if drop r> r> 2drop exit then > true abort" *** <PENNIES-BREAK> given a negative value *** " ; > > : pennies-break ( pennies -- ) > dup if 10000 c" hondos" c" hondo" <pennies-break> then > dup if 2000 c" twenties" c" twenty" <pennies-break> then > dup if 1000 c" tens" c" ten" <pennies-break> then > dup if 500 c" fins" c" fin" <pennies-break> then > dup if 100 c" singles" c" single" <pennies-break> then > dup if 25 c" quarters" c" quarter" <pennies-break> then > dup if 10 c" dimes" c" dime" <pennies-break> then > dup if 5 c" nickles" c" nickle" <pennies-break> then > dup if 1 c" pennies" c" penny" <pennies-break> then > drop ; > > Note that readability is improved a lot if you line up the code in columns. Google totally screws up the alignment because it displays variable-width characters. If you copy this code and put it in a text-editor however, you will see how it all lines up neatly. > > I said previously that functions should be 7 lines or fewer. My PENNIES-BREAK is 10 lines long though. This is okay because all the lines are the same, just with different parameters, so the reader doesn't have more than 7 concepts in his head at once. > > I said previously > (https://groups.google.com/forum/#!topic/comp.lang.forth/CYR7FhjYMkg) > that Forth should allow commas within numbers, and only assume that the number is double-precision if the first char is a comma. I provided code to convert strings into numbers like this. If this were how Forth number literals were defined, then my PENNIES-BREAK could be much more readable: > > : pennies-break ( pennies -- ) > dup if 100,00 c" hondos" c" hondo" <pennies-break> then > dup if 20,00 c" twenties" c" twenty" <pennies-break> then > dup if 10,00 c" tens" c" ten" <pennies-break> then > dup if 5,00 c" fins" c" fin" <pennies-break> then > dup if 1,00 c" singles" c" single" <pennies-break> then > dup if 25 c" quarters" c" quarter" <pennies-break> then > dup if 10 c" dimes" c" dime" <pennies-break> then > dup if 5 c" nickles" c" nickle" <pennies-break> then > dup if 1 c" pennies" c" penny" <pennies-break> then > drop ; I forgot the $50 bill, the $2 bill and the 50-cent coin --- those aren't used very much --- the 50-cent coin was originally introduced so it could be used in slot-machines, but now the slot-machines hold your money for you and then print out a receipt that you take up to the cage-cashier to cash out (I used to work as a cage-cashier at a casino). On a related note, I think that we have too many different coins and different bills in use --- we could do without the dime because it is too close to the nickle in value, and it is also too small physically (it is slightly smaller than the penny; it would make more sense to have the coins get progressively larger with greater value, so you could count your coins in the dark by sense of touch) --- we could do without the $50 because it is too close to the $100 in value, and with inflation $100 today is worth about $50 of 20 years ago, so it would make sense to drop the $50 bill and introduce a $500 bill for use in large cash purchases. Now that we have had the massive housing-bubble bail-out, inflation is likely --- the fast-food employees will be making $15/hour, but the burgers will cost $20.
[toc] | [prev] | [next] | [standalone]
| From | murphy.darin@gmail.com |
|---|---|
| Date | 2016-05-11 23:15 -0700 |
| Message-ID | <f4a430fe-271b-4969-a37a-c6b58cca6197@googlegroups.com> |
| In reply to | #47032 |
LOL!!! I agree about everything save for the $50, even though I ratherly use paper/cloth money and really detest change since it's rather hard to keep from loosing some. Just the price we live in a homophobic country where men aren't allowed to carry purses. LOL.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-05-12 22:34 -0400 |
| Message-ID | <nh3e9q$vmr$1@dont-email.me> |
| In reply to | #47034 |
On 5/12/2016 2:15 AM, murphy.darin@gmail.com wrote: > LOL!!! I agree about everything save for the $50, even though I > ratherly use paper/cloth money and really detest change since it's > rather hard to keep from loosing some. I feel the $50 should stay and the $100 should be replaced by a $200. Currently the $100 is the largest bill we have. When gas was $4 a gallon it took nearly $100 to fill my tank. I don't leave a bank without $200 in my pocket. The $100 bill is used often these days and is just not large enough to serve as anything other than pocket change. -- Rick C
[toc] | [prev] | [next] | [standalone]
Page 4 of 5 — ← Prev page 1 2 3 [4] 5 Next page →
Back to top | Article view | comp.lang.forth
csiph-web