Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #54071 > unrolled thread

Rosetta Code: Accumulator factory

Back to article view | Back to comp.lang.forth

Contents

  Rosetta Code: Accumulator factory "Robert L." <No_spamming@noWhere_7073.org> - 2017-01-17 09:00 +0000
    Re: Rosetta Code: Accumulator factory Paul Rubin <no.email@nospam.invalid> - 2017-01-17 01:38 -0800
      Re: Rosetta Code: Accumulator factory anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-17 13:54 +0000
        Re: Rosetta Code: Accumulator factory Paul Rubin <no.email@nospam.invalid> - 2017-01-17 13:10 -0800
          Re: Rosetta Code: Accumulator factory Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-01-18 03:15 -0600
          Re: Rosetta Code: Accumulator factory anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-18 13:43 +0000
            Re: Rosetta Code: Accumulator factory Paul Rubin <no.email@nospam.invalid> - 2017-01-18 13:20 -0800
              Re: Rosetta Code: Accumulator factory albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-01-19 02:40 +0100
              Re: Rosetta Code: Accumulator factory anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-19 16:27 +0000

#54071 — Rosetta Code: Accumulator factory

A problem posed by Paul Graham is that of creating a function
that takes a single (numeric) argument and which returns
another function that is an accumulator. The returned
accumulator function in turn also takes a single numeric
argument, and returns the sum of all the numeric values passed
in so far to that accumulator (including the initial value
passed when the accumulator was created).

Takes a number n and returns a function (lets call it g), that
takes a number i, and returns n incremented by the
accumulation of i from every call of function g(i).

Works for any numeric type-- i.e. can take both ints and
floats and returns functions that can take both ints and
floats. (It is not enough simply to convert all input to
floats. An accumulator that has only seen integers must return
integers.)

Generates functions that return the sum of every number ever
passed to them, not just the most recent. (This requires a
piece of state to hold the accumulated value, which in turn
means that pure functional languages can't be used for this
task.)

Ruby:

def factory(n)
  proc{|i| n += i}
end

f20 = factory(20)
f500 = factory(500)
p f500.call(3) ; p f500[3.0] ; p f500.(3)
 ===>
503
506.0
509.0

p f20[2] ;  p f20[2]
 ===>
22
24

In Forth?


-- 

[A] young British journalism student ... ventured to the 'refugee' camp at
Calais to report sympathetically on their 'plight.' She was given a crash
course in race realism when the poor downtrodden victims of Western oppression
subjected her to a gang-rape described by police as being of "a particularly
brutal nature."
theoccidentalobserver.net/2015/08/thoughts-on-the-german-dispossession/

[toc] | [next] | [standalone]

#54073

"Robert L." <No_spamming@noWhere_7073.org> writes:
> f20 = factory(20)
> f500 = factory(500)
> p f500.call(3) ; p f500[3.0] ; p f500.(3)

: acc ( n -- ) CREATE , DOES> ( n a -- n ) tuck @ + over ! @ ;

20 acc f20  ok
500 acc f500  ok

3 f500 . 503  ok
2 f20 . 22  ok
2 f20 . 24  ok
5 f500 . 508  ok
3 f20 . 27  ok

[toc] | [prev] | [next] | [standalone]

#54076

Paul Rubin <no.email@nospam.invalid> writes:
>"Robert L." <No_spamming@noWhere_7073.org> writes:
>> f20 = factory(20)
>> f500 = factory(500)
>> p f500.call(3) ; p f500[3.0] ; p f500.(3)
>
>: acc ( n -- ) CREATE , DOES> ( n a -- n ) tuck @ + over ! @ ;

Looking at the Rosettacode page
<https://rosettacode.org/wiki/Accumulator_factory#Forth>, Ian Osgood
has partially solved this in 2010 (in a similar way).  Requirement 2
does not fit Forth at all, but I have now added an FP version and
explained the idiomatic Forth way to deal with the requirement 2.

What this example shows is that CREATE should really FALIGN its body,
otherwise we get cumbersome and inefficient use of FALIGN and
FALIGNED, like this:

: faccumulator ( r "name" -- )
  create falign f,
does> ( r1 -- r2 )
  faligned dup f@ f+ fdup f! ;

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2016: http://www.euroforth.org/ef16/

[toc] | [prev] | [next] | [standalone]

#54085

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
> What this example shows is that CREATE should really FALIGN its body,

For small systems like Amforth, maybe it would be better to have FCREATE
and FDOES if you want float alignment.  Otherwise you waste memory.

[toc] | [prev] | [next] | [standalone]

#54109

Paul Rubin <no.email@nospam.invalid> wrote:
> anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>> What this example shows is that CREATE should really FALIGN its body,
> 
> For small systems like Amforth, maybe it would be better to have FCREATE
> and FDOES if you want float alignment.  Otherwise you waste memory.

I don't think it'll be a huge waste, and IMO the convenience is worth
it for the standard language.  It makes more sense to have a specific
(nonstandard) unaligned CREATE for small systems.  There is an obvious
analogy with ALLOCATE, which must be maximally aligned.

Andrew.

[toc] | [prev] | [next] | [standalone]

#54119

Paul Rubin <no.email@nospam.invalid> writes:
>anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>> What this example shows is that CREATE should really FALIGN its body,
>
>For small systems like Amforth, maybe it would be better to have FCREATE
>and FDOES if you want float alignment.  Otherwise you waste memory.

Do such small systems support FP at all?  AmForth does not, judging by
its reference card.  My guess is that the intersection of systems that
have FP with >cell alignment requirements and that have so little
memory that the padding required these alignment requirements is
significant is empty or at least close to empty.  In these few cases
following Andrew Haley's suggestion and having special CREATE variants
with lower alignment requirements (possibly even one for character
alignment) may be appropriate (of course, one had to balance the
savings against the cost of actually including such words).

- 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]

#54133

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
> Do such small systems support FP at all?  AmForth does not, judging by
> its reference card.

I thought the whole motivation for recognizers was that AmForth had
optional floating point and Matthias wanted a way to cleanly make
parsing of FP numbers optional too.

[toc] | [prev] | [next] | [standalone]

#54137

In article <877f5s3w0e.fsf@nightsong.com>,
Paul Rubin  <no.email@nospam.invalid> wrote:
>anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>> Do such small systems support FP at all?  AmForth does not, judging by
>> its reference card.
>
>I thought the whole motivation for recognizers was that AmForth had
>optional floating point and Matthias wanted a way to clerly make
>parsing of FP numbers optional too.

The original motivation was that ciforth had no $ numbers and I didn't want
that garbage in my kernel.

Groetjes Albert

P.S. Okay, sometimes I use them too.
-- 
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]

#54172

Paul Rubin <no.email@nospam.invalid> writes:
>anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>> Do such small systems support FP at all?  AmForth does not, judging by
>> its reference card.
>
>I thought the whole motivation for recognizers was that AmForth had
>optional floating point and Matthias wanted a way to cleanly make
>parsing of FP numbers optional too.

That may be the case, but MSP430 and AVR8 (the two targets of AmForth)
seem to have no FP hardware, so no change in alignment requirements.

- 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] | [standalone]

Back to top | Article view | comp.lang.forth

csiph-web