Action! on Rosetta Code

[amarok]

Rosetta Code (http://www.rosettacode.org/wiki/Rosetta_Code) is a unique website that provides solutions to a wide variety of programming problems in most known programming languages.

 

Some time ago I realized that there are also 3 problems solved in Action! for 8-bit Atari.
It's great that Action! appeared on the Rosetta Code, but honestly speaking the number of solutions is not too impressive.
Especially when we compare it with other 8-bit languages (state on November 8th, 2021):

• Locomotive Basic (71 tasks),
• Sinclair ZX81 BASIC (76 tasks),
• Commodore BASIC (127 tasks),
• ZX Spectrum Basic (215 tasks)

 

I thought that it would be a great idea to increase the number of tasks on the Rosetta Code for Action!. Besides, since 30 years I always wanted to learn this language.

Since several months I've been solving more and more tasks from the Rosetta Code and I think that it is a good time to upload my solutions into the Rosetta Code database.
But before that happens I'd like to ask you for a code review of my source codes, because I would like to avoid publishing incomplete or wrong solutions.

 

All the source codes prepared by me are available on my gitlab: https://gitlab.com/amarok8bit/action-rosetta-code/-/tree/master

I hope that you could support me in this initiative. Thank you in advance for your comments and suggestions.

 

Here are also some useful links:
Task lists: http://www.rosettacode.org/wiki/Category:Programming_Tasks and http://www.rosettacode.org/wiki/Category:Draft_Programming_Tasks
Rank of programming languages in terms of the number of solved tasks: http://www.rosettacode.org/wiki/RC_POP.OUT

[zbyti]

Impressive work! Nice formatted code, easy to read :]

 

---- EDIT ---

 

I forgot how fast Action! is

brownian_tree.xex

Edited November 9, 2021 by zbyti

[+MrFish]

19 hours ago, zbyti said:

I forgot how fast Action! is

brownian_tree.xex 3.01 kB · 6 downloads

 

I let this run for a while and ended up with a white rectangle on the left. What's that all about?

 

 

[zbyti]

I don't know, I didn't spend much time growing this tree 

 

I used this runtime https://github.com/zbyti/a8-action-playground/blob/master/src/VARIOUS/RUNTIME1.ACT to make XEX. 

 

Oh... And set:

 

SET $495=8 SET $E=$2000 SET $491=$2000

 

Edited November 9, 2021 by zbyti

[danwinslow]

2 hours ago, MrFish said:

 

I let this run for a while and ended up with a white rectangle on the left. What's that all about?

 

 

Some  kind of numeric over/under flow I would guess.

[amarok]

@zbyti, thanks a lot for your comments and providing the executable file which became helpful for detecting the problem.

 

@MrFish, thank you very much for reporting the problem. You have a lot of patience since you've been waiting for the result for so long. In fact there are two issues.

 

The first one is related to algorithm itself which tries to attach new pixels to the tree all the time. It means that finally it fills the whole screen. It might be solved by just stopping the growth of the tree when some condition is met. For example when a pixel touches the edge of the screen or the amount of pixels of the tree exceeds a certain value. I think that I would not fix the first problem for now.

 

The second problem is related to function Rand which in Action! is defined for BYTE only. In this program x position is calculated as random value based on the width of expanding area. When the width is less than 256 there is no issue at all, but otherwise the LSB from CARD variable is taken as an argument for Rand function. For example Rand(320) is run as Rand(64) - therefore you can see a bright area of 63 pixels width.

 

I can see two solution of the second problem. The first one is just to limit the width of the tree to 255 pixels. The second one is to provide implementation of Rand function which accepts CARD argument. I think that the second solution would impact the calculation time, so maybe the limitation of the width might be better solution. What do you think?

 

 

[dmsc]

Hi!

 

Nice drawing, I had forgotten this "diffusion-aggregation" drawings.

 

2 hours ago, amarok said:

The first one is related to algorithm itself which tries to attach new pixels to the tree all the time. It means that finally it fills the whole screen. It might be solved by just stopping the growth of the tree when some condition is met. For example when a pixel touches the edge of the screen or the amount of pixels of the tree exceeds a certain value. I think that I would not fix the first problem for now.

IMHO, best would be to select only points that are "far" from the center, this will stop growing the three from the middle.

 

Here is a "port" of the algorithm to FastBasic, it is really slow, but manly because the LOCATE function in the OS is slow...

 

' Diffusion-Aggregation Three

DATA DX() = 1, 1, 1, 0, 0,-1,-1,-1
DATA DY() = 1, 0,-1, 1,-1, 1, 0,-1

PROC DrawTree

  l=160
  r=160
  t=96
  b=96
  x=160
  y=96
  c=1

  REPEAT
    IF c
      ' Put new particle
      Plot x, y
      @CalcBox
    ENDIF

    ' Select new particle outside
    REPEAT
      x=RAND(r-l+1)+l
      y=RAND(b-t+1)+t
      locate x, y, c
    UNTIL not c

    ' Move particle until it collides
    REPEAT
      @CheckNeighbors
      if c then exit
      d = RAND(8)
      X = x + DX(d)
      y = y + DY(d)
    UNTIL x < l OR x > r OR y < t OR y > b

    Poke 77,0  ' turn off the attract mode
  UNTIL KEY()
ENDPROC

PROC CalcBox
  if x - 16 < l then l = x - 16
  if x + 16 > r then r = x + 16
  if y - 16 < t then t = y - 16
  if y + 16 > b then b = y + 16
ENDPROC

PROC CheckNeighbors
  locate x-1, y-1, c : if c then exit
  locate x  , y-1, c : if c then exit
  locate x+1, y-1, c : if c then exit
  locate x-1, y  , c : if c then exit
  locate x+1, y  , c : if c then exit
  locate x-1, y+1, c : if c then exit
  locate x  , y+1, c : if c then exit
  locate x+1, y+1, c : if c then exit
ENDPROC


Graphics 8+16
Color 1

@DrawTree

 

2 hours ago, amarok said:

I can see two solution of the second problem. The first one is just to limit the width of the tree to 255 pixels. The second one is to provide implementation of Rand function which accepts CARD argument. I think that the second solution would impact the calculation time, so maybe the limitation of the width might be better solution. What do you think?

 

This is FastBasic code for the RAND function, on input registers A/X hold the 16 bit "max value", on output A/X holds the random integer, it is fairly fast:

.proc   EXE_RAND        ; AX= RANDOM from 0 to AX-1

        ldy     #0
        stx     tmp1+1

get_l:  iny
        cpy     #$10
        rol
        rol     tmp1+1
        bpl     get_l
        sta     tmp1

        ; Now, get a number in the range
retry:  ldx     RANDOM
        cpx     tmp1
        lda     RANDOM
        sta     tmp2
        sbc     tmp1+1
        bcs     retry

        ; And scale back
        txa
scale:  lsr     tmp2
        ror
        dey
        bne     scale
        ldx     tmp2
        rts
.endproc

 

Have Fun!

 

[bocianu]

@amarok what a great work has been done here!

half of a year of coding - i am really impressed.

 

good job mate!

[amarok]

I have introduced first 28 of my 500 solutions into the database of RosettaCode, so there are only 472 entries to be entered...

 

Currently Action! is on the 276th place of the most popular languanges on the website:

http://rosettacode.org/wiki/Rosetta_Code/Rank_languages_by_popularity/Full_list

 

@dmsc, thank you for your proposal, I will check its performance. The source code for 16-bit random generator is also very useful. For now I just limited the width of the tree to 255 pixels and use single byte random number generator to avoid the problem on the left side of the screen.

[Gury]

Fantastic work, amarok. I went through the list and you provided massive selection of Action! code.

Lots of material to check. Thank you!

 

[Tigerofdarkness]

Hi Amarok,

 

great work! Good to see a large body of Action! code.

 

Looking at the Abundant, Defficient and Perfect number classification task, instead of sieving the Primes, you could sieve the proper divisor sums, which would simplify the code and boost performance, as in the Algol 68 sample - e.g.:

PROC Main()
  DEFINE MAXNUM="20000"
  BYTE ARRAY pds(MAXNUM+1)                              ;;; propper divisor sums array
  CARD def,perf,abud,i,j,sum,sum2                       ;;; add j
  BYTE CRSINH=$02F0 ;Controls visibility of cursor
 
  CRSINH=1 ;hide cursor
  Put(125) PutE() ;clear the screen
  PrintE("  Numbers: ")
  PrintE("Deficient: 0")
  PrintE("  Perfect: 0")
  PrintE("  Abudant: 0")

  ;;; construct a table of the proper divisor sums
  pds(1) = 0;
  FOR i = 2 TO MAXNUM DO pds(i) := 1 OD
  FOR i = 2 TO MAXNUM DO
    FOR j = i + i TO MAXNUM STEP i DO pds(j) ==+ i OD
  OD
 
  def=1 perf=0 abud=0
  FOR i=2 TO MAXNUM
  DO
    Position(13,1)
    PrintI(i)
    sum=pds(i)                                          ;;; use te proper divisor sums
    IF sum<i THEN
      def==+1
      Position(13,2)
      PrintI(def)
    ELSEIF sum=i THEN
      perf==+1
      Position(13,3)
      PrintI(perf)
    ELSE
      abud==+1
      Position(13,4)
      PrintI(abud)
    FI
  OD
RETURN

I've marked the changes with ;;;

 

NB, I don't have access to Action! to test this with, so I hope It is OK...

 

 

[amarok]

@Tigerofdarkness, thank you very much for your proposal for optimization.

 

In fact it was my initial approach when I started to solve the problem.

But I discovered a technical limitation related to storing the sum of the proper divisor which should be an array of CARD or INT.

The amount of memory for the array would be 40000 bytes which obviously is too big to be managed within non-extended memory.

Therefore I decided to use less optimized method in terms of calculations, but I use prime number to speed up it a little.

 

Anyway, I would be grateful if you could share some other ideas for improvements.

[Tigerofdarkness]

@amarok, oops - you are right of course. Obviously, I'm too used to having a lot of memory...

 

...if I come up with anything I'll let you know.

[amarok]

In this week I have uploaded 91 programs into RosettaCode database and there are only 381 to be published.

 

Currently Action! is on the 140th place of the most popular languanges and has better rank than Locomotive Basic, Sinclair ZX81 BASIC, TI-89 BASIC, 8080 Assembly, 6502 Assembly, 8086 Assembly and Visual Basic: http://rosettacode.org/wiki/Rosetta_Code/Rank_languages_by_popularity/Full_list

 

I am sharing an image containing some of the screenshots from Action! programs which can be found on the RosettaCode website.

 

Edited November 21, 2021 by amarok

[Tigerofdarkness]

Hi Amarok,

 

I had a couple of thoughts:

 

With the Abundant, Perfect and Deficient classification task, a CARD array of 10 000 elements would cover half the numbers required for the task, and you could then use the function to cover the second half (possibly re-using the space as a BYTE array for a prime sieve for 20 000 elements to use your prime optimisation for the second half). This gave quite a performance boost in some tests I made, though I didn't print every number as it was classified - not sure how much effect that has.

 

And:

With Rosetta Code, some languages have syntax highlighting defined - although it doesn't seem to be possible to add a new language, you could possibly use the Algol 68 highlighting, as Action! shares many keywords with Algol 68.

If you specify <lang algol68> instead of <lang Action!> you will get Algol 68 highlighting.

 

Not sure how good it would be, the main problems would be:

    # is a comment delimiter in Algol 68

    ; isn't a comment delimiter in Algol 68

    the syntax highlighter gets confused by Action!-style character literals as it wants a closing ' for every '

    Not all Action! keywords are Algol 68 keywords, DEFINE, RETURN, ELSEIF, BYTE, CARD for example/

 

This: is what part of the Langston's Ant sample would look like (I haven't changed it on RC).

 

Just a thought, what do you think ?

 

You are building an impressive collection of Action! programs and I see that another RC user has added a few as well.

 

[amarok]

@Tigerofdarkness, thank you very much for your comments.

 

I combined your ideas from posts #11 and #15 to speed up the calculation in "Abundant, deficient and perfect number classifications" task.

You can see the source code here: https://gitlab.com/amarok8bit/action-rosetta-code/-/blob/5cc739fce4463a054c8229fa7fa702159697df79/source/Abundant,_deficient_and_perfect_number_classifications_v2.act

Because of the memory limitation the array containing Proper Divisor Sums is generated and used twice for the first and the second half of numbers separately.

The new solution is over 23 times faster than the original one and takes 5min 22sec where the original takes 2h 5min 40sec.

I can see some further optimizations but they may reduce readability of the source code which I would like to avoid.

 

Concerning syntax highlighting of Action! on RosettaCode, your idea is quite interesting and tempting - thanks.

Honestly speaking, if I have to choose between imprecise workaround (using another language syntax) and not coloring the code I prefer the second approach.

I hope that some day it will be possible to introduce the syntax highligting of Action! language on the website.

 

Additional note:

I've just checked calculation time of "Abundant, deficient and perfect number classifications" when printing of the progress is turned off and it takes only 34 seconds!

It means that 4min 48sec is "wasted" just for printing the current result. It was valuable for the original implementation but for the optimized not.

The source codes are available here: https://gitlab.com/amarok8bit/action-rosetta-code/-/blob/3f8b63d6fcd951f9134940cf981d99d644935215/source/Abundant,_deficient_and_perfect_number_classifications_v2.act

 

Edited November 27, 2021 by amarok
Additional note

[amarok]

Last week I uploaded 150 solutions of tasks on RosettaCode website. Also some improvements have been introduced.

 

Currently Action! has 284 entries and is on the 83rd place in the rank of the most popular languanges which is better result than Commodore BASIC, Applesoft BASIC, IS-BASIC, ZX Spectrum Basic and Algol W: http://rosettacode.org/wiki/Rosetta_Code/Rank_languages_by_popularity/Full_list

 

I am uploading screenshots from tasks which I added into the website recently.

 

Edited November 29, 2021 by amarok

[amarok]

Finally, I uploaded all of 217 remaining programs into RosettaCode database.

Currently Action! with 505 entries is on the 55th place in the rank of the most popular languages overtaking COBOL, MATLAB, VBA, Prolog and PHP.

 

In the meantime I plan to solve some additional tasks and introduce them on the website.

I really wish that also some of you will continue the mission to make Action! stronger and stronger .

 

I am attaching an image with programs I published on the RosettaCode last week.

 

[zbyti]

@amarok please provide binary file for every solution :]

[zbyti]

1 hour ago, amarok said:

I really wish that also some of you will continue the mission to make Action! stronger and stronger .

 

[zbyti]

Of course I understand why you are writing this in Action! but it's a bit of an unused amount of work.

 

If you chose Mad Pascal, Millfork or KickC, you would be helping the developer with the ongoing development, by writing 500 examples you would probably find many bugs in compiler or place to improve...
 
No one will develop Action! based on your work.

Edited December 7, 2021 by zbyti

[ilmenit]

27 minutes ago, zbyti said:

If you chose Mad Pascal, Millfork or KickC, you would be helping the developer with the ongoing development, by writing 500 examples you would probably find many bugs in compiler or place to improve...
 
No one will develop Action! based on your work.

Can be a great test set for Effectus

[zbyti]

That's true, but we must have Effectus first.

 

I know Effectus a bit and it seems to me that @Gury has to rewrite the lexer and parser from scratch or use dedicated tools.

[danwinslow]

4 hours ago, zbyti said:

Of course I understand why you are writing this in Action! but it's a bit of an unused amount of work.

 

If you chose Mad Pascal, Millfork or KickC, you would be helping the developer with the ongoing development, by writing 500 examples you would probably find many bugs in compiler or place to improve...
 
No one will develop Action! based on your work.

Well, no one besides us (who would do it anyway) would develop in MPascal, MIllfork, or KickC based on a bunch of stuff in rosetta code, which is hardly a 'go to' resource for most developers. I think you might be missing his point.

Edited December 7, 2021 by danwinslow

[zbyti]

So little people programming in anything other than ASM on 8-bit at all that almost every time you start typing, you find a compiler/parser flaw or chance to improvement.

 

I been there done that.