User avatar
Paeryn
Posts: 2562
Joined: Wed Nov 23, 2011 1:10 am
Location: Sheffield, England

Re: Why Avoid BASIC on RPi?

Sat Dec 08, 2018 12:11 pm

jahboater wrote:
Sat Dec 08, 2018 7:43 am
Paeryn wrote:
Sat Dec 08, 2018 1:38 am
No, it is a combined Unsigned DIV and MOD on Double-Integers (long long, typically 64-bit). It takes two 64-bit integers and a pointer to a 64-bit integer. It returns the quotient, the remainder is stored at the address pointed to by the third parameter (if not NULL).
What are the two 64-bit integers it takes as input? I presumed they were the 128-bit dividend.
I guess that is 64-bit division, in the same way that a 64-bit multiply returns a 128-bit result.
It takes the dividend and divisor.

Code: Select all

unsigned long long x = 10, y = 3, quot, rem;
quot = __udivmoddi4(x, y, &rem);
// The above divides 10 by 3 giving us quot = 3, rem = 1
If the pointer is NULL then the remainder is thrown away.
Earlier versions of the divmod functions had the last paramerer as an int whereby passing 0 meant it returned the quotient and 1 returned the remainder.
She who travels light — forgot something.

User avatar
DavidS
Posts: 4197
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: Why Avoid BASIC on RPi?

Sat Dec 08, 2018 2:13 pm

ejolson wrote: What happens if you set nmax to 250 and try to compute F(11) instead?
Same error, same line.

if I am following the flow corectly the first time that PROCbigmul is called it should be multiplying 0 by 1 which is 0. So I do not see how it could be to big. As said I probably made an obvious error that I am not seeing yet.
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

User avatar
Paeryn
Posts: 2562
Joined: Wed Nov 23, 2011 1:10 am
Location: Sheffield, England

Re: Why Avoid BASIC on RPi?

Sat Dec 08, 2018 2:35 pm

DavidS wrote:
Sat Dec 08, 2018 6:11 am
I was just running it to find out if I missed a variable name or some such the first error that comes up is a "number too big" error in the procedure PROCbigmul.

I am posting the conversion thus far not working as I am having trouble concentrating at the moment.

Code: Select all

    FOR i%=0 TO !xn%<<2 STEP 4
        FOR j%=1 TO !yn%<<2 STEP 4
            c% = 0
            t% = zd%!(i%+j%-4) + xd%!i% * yd%!j%
Note that i am using indirected memory blocks instead of arrays, hence the scaling of acceses to by 4 times (integers are 4 bytes each, indirection in ARM basic is always to the byte address).

FYI the line where the error is reported is in bigmul and is th line:
t% = zd%!(i%+j%-4) + xd%!i% * yd%!j%
Not sure how BASIC works with indirection but I think you might be forgetting to scale the initial value for j. As you have it the first iteration
i% = 0, j% = 1
zd%!(i%+j%-4) == zd%!(-3)
Which looks wrong. Since both i% and j% are incremented by 4 shouldn't j% start at 4 rather than 1?
She who travels light — forgot something.

User avatar
DavidS
Posts: 4197
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: Why Avoid BASIC on RPi?

Sat Dec 08, 2018 3:08 pm

Paeryn wrote:
Sat Dec 08, 2018 2:35 pm
DavidS wrote:
Sat Dec 08, 2018 6:11 am
I was just running it to find out if I missed a variable name or some such the first error that comes up is a "number too big" error in the procedure PROCbigmul.

I am posting the conversion thus far not working as I am having trouble concentrating at the moment.

Code: Select all

    FOR i%=0 TO !xn%<<2 STEP 4
        FOR j%=1 TO !yn%<<2 STEP 4
            c% = 0
            t% = zd%!(i%+j%-4) + xd%!i% * yd%!j%
Note that i am using indirected memory blocks instead of arrays, hence the scaling of acceses to by 4 times (integers are 4 bytes each, indirection in ARM basic is always to the byte address).

FYI the line where the error is reported is in bigmul and is th line:
t% = zd%!(i%+j%-4) + xd%!i% * yd%!j%
Not sure how BASIC works with indirection but I think you might be forgetting to scale the initial value for j. As you have it the first iteration
i% = 0, j% = 1
zd%!(i%+j%-4) == zd%!(-3)
Which looks wrong. Since both i% and j% are incremented by 4 shouldn't j% start at 4 rather than 1?
Face-Palm:
Thank you, actually it needs to be zero, he was using 1 based arrays I am using 0 based indirection.

I knew there had to be something simple and obvious I was missing.
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

User avatar
Paeryn
Posts: 2562
Joined: Wed Nov 23, 2011 1:10 am
Location: Sheffield, England

Re: Why Avoid BASIC on RPi?

Sat Dec 08, 2018 3:17 pm

DavidS wrote:
Sat Dec 08, 2018 3:08 pm
I knew there had to be something simple and obvious I was missing.
It usually is the case. Much easier for somebody who's not seen the code before to see what is written rather than the author who tends to read what they meant to write. I doubt there's a programmer out there that's never had an issue like this. After 30+ years I still do it from time to time.
She who travels light — forgot something.

User avatar
DavidS
Posts: 4197
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: Why Avoid BASIC on RPi?

Sat Dec 08, 2018 3:21 pm

Paeryn wrote:
Sat Dec 08, 2018 2:35 pm
DavidS wrote:
Sat Dec 08, 2018 6:11 am
I was just running it to find out if I missed a variable name or some such the first error that comes up is a "number too big" error in the procedure PROCbigmul.

I am posting the conversion thus far not working as I am having trouble concentrating at the moment.

Code: Select all

    FOR i%=0 TO !xn%<<2 STEP 4
        FOR j%=1 TO !yn%<<2 STEP 4
            c% = 0
            t% = zd%!(i%+j%-4) + xd%!i% * yd%!j%
Note that i am using indirected memory blocks instead of arrays, hence the scaling of acceses to by 4 times (integers are 4 bytes each, indirection in ARM basic is always to the byte address).

FYI the line where the error is reported is in bigmul and is th line:
t% = zd%!(i%+j%-4) + xd%!i% * yd%!j%
Not sure how BASIC works with indirection but I think you might be forgetting to scale the initial value for j. As you have it the first iteration
i% = 0, j% = 1
zd%!(i%+j%-4) == zd%!(-3)
Which looks wrong. Since both i% and j% are incremented by 4 shouldn't j% start at 4 rather than 1?
While I thank you for that correction, stil the same error.

I thank you again, I am begining to get a bit frustrated with this issue as it is making no sense at all to me. I am still sure it is a silly mistake that my mind is floating over, especailly as this is a conversion from FreeBASIC to ARM BASIC.

BTW:
ARM BASIC indirection is really simple, an integer variable (as indicated by the '%' postfix) contains the base address. For integers stored in the region you use the operatore '!' to access the elements, if the operator is at the begining of the variable name it accesses the first element (element 0) if it is after the '%' then the integer after the ! is used as a byte index into the region of memory.

'!' is for integers stored by indirection,
'|' does the same for reals,
'?' is the same for bytes,
'$' is the same for strings (used with an integer base).

In each case used with an integer as the base value, usually a variable. Integer variables always end in '%' and have a seperate namespace from other variable types.

Thus:

Code: Select all

pt%!100 : REM Is the 32-bit integer that starts 100 bytes into block at the address in pt%.
pt%!cnt%  : REM Is the integer at cnt% bytes past the address in pt%.
!pt%       : REM Is 32-bit integer at the address in pt%.
$(pt%+70) : REM is the string starting 70 bytes after the address in pt%.
etc, I think that gives a basic overview. And integer variables can be used for the indexes.
It is just a simple implementation of pointers.
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

jahboater
Posts: 4428
Joined: Wed Feb 04, 2015 6:38 pm

Re: Why Avoid BASIC on RPi?

Sat Dec 08, 2018 3:26 pm

Heater wrote:
Sat Dec 08, 2018 10:21 am
Of course the next language after "C" should rightfully be "D". Clearly C++ is is only a prototype, an experiment, a detour on the road between between C and D. (Up a blind alley as it happens).
:)

Actually we had B then C, loosely derived from BCPL. In the early days of C++ (C with classes) they couldn't choose between D and P, so they chose C++.

User avatar
DavidS
Posts: 4197
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: Why Avoid BASIC on RPi?

Sat Dec 08, 2018 3:36 pm

I have began working on a conversion using arrays instead of indirectedblocks. We will see how that goes.

I did look up how FB handles asignments when both sides are a structured datatype, and it copys the content value not the address, which would have lead to an issue when the code can get further.

As the FB version is assuming 1 based indexing I am going to be using element 0 of the arrays for the d element of the FB datatype, as we do not have structured datatypes in ARM BASIC (one of the very few shortcomings of ARM BASIC, we have always used indirection to get around this issue).
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

User avatar
Paeryn
Posts: 2562
Joined: Wed Nov 23, 2011 1:10 am
Location: Sheffield, England

Re: Why Avoid BASIC on RPi?

Sat Dec 08, 2018 3:43 pm

DavidS, since the original had

Code: Select all

FOR i% = 1  TO !xn%
shouldn't your's be

Code: Select all

FOR  i% = 0 TO (!xn% - 1) << 2 STEP 4
And the same for j%. You might be reading large values from the word after the array which is causing the overflow.

Thanks for the clarification on indirection, I haven't used BBC Basic since school, I remembered about using ! before a variable and guessed that after was adding an offset.
She who travels light — forgot something.

User avatar
DavidS
Posts: 4197
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: Why Avoid BASIC on RPi?

Sat Dec 08, 2018 4:29 pm

Paeryn wrote:
Sat Dec 08, 2018 3:43 pm
DavidS, since the original had

Code: Select all

FOR i% = 1  TO !xn%
shouldn't your's be

Code: Select all

FOR  i% = 0 TO (!xn% - 1) << 2 STEP 4
And the same for j%. You might be reading large values from the word after the array which is causing the overflow.

Thanks for the clarification on indirection, I haven't used BBC Basic since school, I remembered about using ! before a variable and guessed that after was adding an offset.
You may be exactly correct. Especially how the zeroing is done.

I will be giving that a try a bit later, playing with getting the version using arrays going at the moment.

Thank you for that.
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

Heater
Posts: 12634
Joined: Tue Jul 17, 2012 3:02 pm

Re: Why Avoid BASIC on RPi?

Sat Dec 08, 2018 4:38 pm

DavidS,
BTW:
ARM BASIC indirection is really simple, an integer variable (as indicated by the '%' postfix) contains the base address. For integers stored in the region you use the operatore '!' to access the elements, if the operator is at the begining of the variable name it accesses the first element (element 0) if it is after the '%' then the integer after the ! is used as a byte index into the region of memory.

'!' is for integers stored by indirection,
'|' does the same for reals,
'?' is the same for bytes,
'$' is the same for strings (used with an integer base).
...
Thus:

Code: Select all

pt%!100    : REM Is the 32-bit integer that starts 100 bytes into block at the address in pt%.
pt%!cnt%   : REM Is the integer at cnt% bytes past the address in pt%.
!pt%       : REM Is 32-bit integer at the address in pt%.
$(pt%+70)  : REM is the string starting 70 bytes after the address in pt%.
Thank you. Finally someone answers the question, "Why Avoid BASIC on RPi?", in concrete detail.
:) :) :)
Last edited by Heater on Sat Dec 08, 2018 4:54 pm, edited 1 time in total.

jahboater
Posts: 4428
Joined: Wed Feb 04, 2015 6:38 pm

Re: Why Avoid BASIC on RPi?

Sat Dec 08, 2018 4:42 pm

Its true that this looks like APL - unreadable and archaic with all the %'s

t% = zd%!(i%+j%-4) + xd%!i% * yd%!j%

FreeBasic seems much better.

User avatar
DavidS
Posts: 4197
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: Why Avoid BASIC on RPi?

Sat Dec 08, 2018 5:39 pm

I think I got it working. I have not yet run it to completion, though interpreted at least it is running, and I can not quickly see any errors in this conversion.

Though I will later test with some smaller values for n so that it can be completely verified to work.

Code: Select all

ON ERROR PRINT "LINE : " + STR$(ERL) + " ERROR : " + REPORT$ : E

 REM fibo.bas -- Compute the nth Fibonacci Number
 REM Written December 6, 2018 by Eric Olson
 REM Translated to ARM BASIC by David Cagle, 8th December 2016
 REM
 REM This program demonstrates the expressiveness of FreeBASIC a
 REM measured by explicitly coding big-number arithmetic and the
 REM using the doubling formulas
 REM
 REM     F(2k) = F(k)[2F(k+1)-F(k)]
 REM   F(2k+1) = F(k+1)^2+F(k)^2
 REM   F(2k+2) = F(k+1)[2F(k)+F(k+1)]
 REM
 REM to compute the nth Fibonacci number.  For simplicity this c
e
 REM does not use Karatsuba multiplication but instead relies on
 REM the O(n^2) algorithm in all cases.  When computing F(478496
 REM this results in significantly more computational work.

 nmax% = 250100
 radix% = 10000
 rexp% = 4
 REM type bignum
 REM    dim as integer n
 REM    dim as integer d(1 to nmax)
 REM end type
 REM To replace the type, we are using the variable array name
 REM in place of the bignum variable name, and element 0 as the
 REM n member of the bignum.
    DIM a%(nmax%), b%(nmax%)
    DIM t1%(nmax%), t2%(nmax%), t3%(nmax%)

 PROCstart
 END


DEF PROCbigprint(x%())
    LOCAL i%, t%, c%, s$
    IF x%(0)=0 THEN
        PRINT 0
    ELSE
        FOR i%=x%(0) TO 1 STEP -1
            s$=STR$x%(i%)
            IF i%<x%(0) THEN
                s%=MID$("0000000000",1,rexp%-len(s$))+s$
            ENDIF
            PRINT s$;
        NEXT
        PRINT
    ENDIF
 ENDPROC


DEF PROCbigmul(z%(),x%(),y%())
    LOCAL i%, j%, t%, c%
    FOR i%=1 TO x%(0)+y%(0)
        z%(i%)=0
    NEXT
    FOR i%=1 TO x%(0)
        FOR j%=1 TO y%(0)
            c%=0
            t%=z%(i%+j%-1)+x%(i%)*y%(j%)
            IF t%>=radix% THEN
                c%=t% DIV radix%
                t%=t% MOD radix%
            ENDIF
            z%(i%+j%-1)=t%
            z%(i%+j%)=z%(i%+j%)+c%
        NEXT
    NEXT
    z%(0)=x%(0)+y%(0)
    WHILE z%(z%(0))=0 AND z%(0)>1
        z%(0)=z%(0)-1
    ENDWHILE
 ENDPROC


DEF PROCbigadd(z%(),x%(),y%())
    LOCAL i%, t%, c%
    IF y%(0)>x%(0) THEN
        max%=y%(0)
    ELSE
        max%=x%(0)
    ENDIF
    FOR i%=1 TO max%+1
        z%(i%)=0
        ENDIF
    FOR i%=1 TO max%
        c%=0
        IF i%<=x%(0) THEN
            t%=z%(i%)+x%(i%)
            IF i%<=y%(0) THEN
                t%=t%+y%(i%)
            ENDIF
        ELSE
            t%=z%(i%)+y%(i%)
        ENDIF
        IF t%>=radix% THEN
            c%=1
            t%=t%-radix%
        ENDIF
        z%(i%)=t%
        z%(i%+1)=z%(i%+1)+c%
    NEXT
    z%(0)=max%+1
    WHILE z%(z%(0))=0 AND z%(0)>1
        z%(0)=z%(0)-1
    ENDWHILE
 ENDPROC


DEF PROCbigsub(z%(),x%(),y%())
    LOCAL i%, t%, c%
    FOR i%=1 TO x%(0)
        z%(i%)=0
    NEXT
    FOR i%=1 TO y%(0)
        c%=0
        t%=z%(i%)+x%(i%)-y%(i%)
        IF t%<0 THEN
            t%=t%+radix%
            c%=-1
        ENDIF
        z%(i%)=t%
        z%(i%+1)=z%(i%+1)+c%
    NEXT
    FOR i%=y%(0)+1 TO x%(0)
        c%=0
        t%=z%(i%)+x%(i%)
        IF t%<0 THEN
            t%=t%+radix%
            c%=-1
        ENDIF
        z%(i%)=t%
        z%(i%+1)=z%(i%+1)+c%
    NEXT
    z%(0)=x%(0)
    WHILE z%(z%(0))=0 AND z%(0)>1
        z%(0)=z%(0)-1
    ENDWHILE
 ENDPROC


DEF PROCfibo(n%,a%(),b%())
    IF n% THEN
    PROCfibo(n% DIV 2,a%(),b%())
    REMstatic as bignum t1,t2,t3
    PROCbigmul(t1%(),a%(),a%()):PROCbigmul(t2%(),b%(),b%())
                PROCbigadd(t3%(),t1%(),t2%())
      IF n% MOD 2=0 THEN
        REM [a,b]=[a*(b*2-a),a*a+b*b]
        PROCbigadd(t1%(),b%(),b%()):PROCbigsub(t2%(),t1%(),a%())
                PROCbigmul(t1%(),a%(),t2%())
        a%()=t1%():b%()=t3%()
      ELSE
        REM [a,b]=[a*a+b*b,b*(2*a+b)]
        PROCbigadd(t1%(),a%(),a%()):PROCbigadd(t2%(),t1%(),b%())
                PROCbigmul(t1%(),b%(),t2%())
        a%()=t3%():b%()=t1%()
      ENDIF
    ELSE
        a%(0)=0:b%(0)=1:b%(1)=1
    ENDIF
 ENDPROC


 DEFPROCstart
  REM main routine
  n%=4784969
  IF n%<2 THEN
    PRINT n%
  ELSE
    PROCfibo(n%-1,a%(),b%())
    PROCbigprint(b%())
  ENDIF
 ENDPROC
If you notice any errors please let me know.

Now I am off to compile this beast. The compiler may catch something the interpreter missed so far.
Last edited by DavidS on Sat Dec 08, 2018 5:50 pm, edited 1 time in total.
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

User avatar
DavidS
Posts: 4197
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: Why Avoid BASIC on RPi?

Sat Dec 08, 2018 5:41 pm

jahboater wrote:
Sat Dec 08, 2018 4:42 pm
Its true that this looks like APL - unreadable and archaic with all the %'s

t% = zd%!(i%+j%-4) + xd%!i% * yd%!j%

FreeBasic seems much better.
While I agree that this case is not so readable, it could be a lot more readable if it were written in ARM BASIC from the start instead of translating from FreeBASI.

I can do a lot less readable in FreeBASIC or C as the result of translation.

Though this is part of why I decided to redo it using arrays instead of indirection for the translation.

I would have chosen more readable variable names if I created the original.

And in ARM BASIC we can instantly see the variable type without having to find where it was declared.
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

User avatar
DavidS
Posts: 4197
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: Why Avoid BASIC on RPi?

Sat Dec 08, 2018 5:59 pm

As this is about the expresiveness of the language, and that version is a direct translation of the FreeBASIC version, would it be alright to call this a sufficient example of the expresiveness of that particular implementation in ARM BASIC?

I really do not feel like veryfying every bit of that for complete correctness at this time. And it will not compile (though the version using indirection would), because the compiler does not support passing arrays as parameters, which surprises me because in the interpreter arrays are specified to be passed by reference.
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

ejolson
Posts: 3039
Joined: Tue Mar 18, 2014 11:47 am

Re: Why Avoid BASIC on RPi?

Sat Dec 08, 2018 6:16 pm

jahboater wrote:
Sat Dec 08, 2018 4:42 pm
Its true that this looks like APL - unreadable and archaic with all the %'s
APL is a language whose time is yet to come, though we're getting closer with Unicode.

The D programming language was engineered by the same person (Walter Bright) who wrote the game Empire for the PDP-10, which later appeared on one of the DECUS tapes for the VAX. Empire was translated to the PC and finally released as the commercial title Empire Wargame of the Century with a graphical interface by Electronic Arts. There is, of course, also a GNU rewrite of empire with added features that takes much more memory.

Maybe rewriting Empire in BASIC should be the next project.

User avatar
DavidS
Posts: 4197
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: Why Avoid BASIC on RPi?

Sat Dec 08, 2018 6:30 pm

Now for the Counter challenge (just a quick one):

As the goal is to show the expresiveness of the languages in respect to there usability I think that a more real world example is in order.

The example I would like to propose is a simple minimal Recursive Decent compiler implemented in the target language without using external tools for an integer only limited subset of C.

For this I propose only these atomic datatypes:
  • int
  • long
  • short
  • char
  • void
Where int, long, and short are all 32-bit integers, and char is an 8 bit unsigned only integer.

I would only include the unsigned modifier for the atomic datatypes.

Also include support for structured datatypes of the form:

Code: Select all

struct structname {
   //structure members.
} varlist;
And arrays.

As for binary operators include support only for '+', '-', '*', '/', ',', '&', '|', '&&', '||', '=', '==', '+=', "-=', and '*='. This will simplify the recursive decent parser.

For unary operators we only should have '!', '*', '~', '-', '[]', and '()'

Support keywords should include only the above mentioned type releated and:

Code: Select all

sizeof     for      while     do         if         else
We should of course have support for function declaration and definition in the standard way.

For this quick example I would recomend only supporting the preprocessor directive include, we do not need the others for a quick and minimal integer only subset C.

Follow the APCS convention for all calls.

And as this is for the Raspberry Pi output should be in ARM assembly using the syntax of ObjASM/asasm. Asasm is easilly installed on Linux, and is a standard part of the gcc distribution for RISC OS.

If everyone agrees that this is a reasonable comparison then we can possibly each get started in our language of choice for comparison.

I pick ARM BASIC.
I would like to ask Heater to do a ground up implementation in C.
And someone to do one in FreeBASIC.
Then we will need someone to do one in Python (rounding out the list).

This is a real world kind of application that is simple enough to implement for a challenge of this nature, and is not going to require anyone to do just a translation. I would also encorouge the implementation of others in the same languages so we can see how much a difference the choices of the implementor make on the expressivness of the program even given the same language.
Last edited by DavidS on Sat Dec 08, 2018 6:49 pm, edited 2 times in total.
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

ejolson
Posts: 3039
Joined: Tue Mar 18, 2014 11:47 am

Re: Why Avoid BASIC on RPi?

Sat Dec 08, 2018 6:35 pm

DavidS wrote:
Sat Dec 08, 2018 5:59 pm
As this is about the expresiveness of the language, and that version is a direct translation of the FreeBASIC version, would it be alright to call this a sufficient example of the expresiveness of that particular implementation in ARM BASIC?

I really do not feel like veryfying every bit of that for complete correctness at this time. And it will not compile (though the version using indirection would), because the compiler does not support passing arrays as parameters, which surprises me because in the interpreter arrays are specified to be passed by reference.
It does seem a difficult limitation to not allow passing of arrays as arguments. The largeint subroutine library written by Jean Debord dodges this problem by allocating a large global array to hold the digits of all big numbers and then a second array to hold the indices where each big number starts in the large global array. Big numbers are then referred to by integer handles, which are indices into the second array.

User avatar
DavidS
Posts: 4197
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: Why Avoid BASIC on RPi?

Sat Dec 08, 2018 6:46 pm

Yes there are ways around it. I have been staring at that BASIC code to long.

And I am going to change my vote for implementation language for my challenge, I am going to pick two languages to implement the described recursive decent compiler, C and ARM assembly. I will leave the BASIC one to others as I think that others will do better for readability and I do not want to explain any more of how ARM BASIC works as part of an example challenge (I am already writing a series of tutorials for my web site, that should be enough once done).

And I need a break from BASIC as I am doing a lot of stuff in ARM BASIC as of late.

That is I will do one implementation purely in ANSI C (trying to be careful that it is able to self compile provided a standard library to link to) and another in Assembly language.
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

ejolson
Posts: 3039
Joined: Tue Mar 18, 2014 11:47 am

Re: Why Avoid BASIC on RPi?

Sat Dec 08, 2018 7:01 pm

DavidS wrote:
Sat Dec 08, 2018 6:30 pm
Now for the Counter challenge
It does seem like the original challenge was made in this post and a counter challenge would only be fair. At the same time, I'm still waiting for how the C++ Fibonacci program turns out, because it would be very nice to see something built with object-oriented overloaded-operators that actually works.

As for the counter challenge, I would prefer something like a modern implemention of the multiplayer game Star Trader as described in the last two listings TRADE and TRADER of this document except with graphics, a mouse interface and network play capability. The third challenge could then be a tournament to play the game and win.

User avatar
DavidS
Posts: 4197
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: Why Avoid BASIC on RPi?

Sat Dec 08, 2018 7:17 pm

ejolson wrote:
Sat Dec 08, 2018 7:01 pm
DavidS wrote:
Sat Dec 08, 2018 6:30 pm
Now for the Counter challenge
It does seem like the original challenge was made in this post and a counter challenge would only be fair. At the same time, I'm still waiting for how the C++ Fibonacci program turns out, because it would be very nice to see something built with object-oriented overloaded-operators that actually works.

As for the counter challenge, I would prefer something like a modern implemention of the multiplayer game Star Trader as described in the last two listings TRADE and TRADER of this document except with graphics, a mouse interface and network play capability. The third challenge could then be a tournament to play the game and win.
While that sounds like a good challenge, you are not going to get most languages in on that without going beyond there standard libraries (networking, mouse, windowing system, possible graphics).

Though that could double to present the differences of using differing OS's and toolkits for different implementations.

EDIT:Wording originally incorrect to meaning.
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

ejolson
Posts: 3039
Joined: Tue Mar 18, 2014 11:47 am

Re: Why Avoid BASIC on RPi?

Sat Dec 08, 2018 7:58 pm

DavidS wrote:
Sat Dec 08, 2018 7:17 pm
Though that could double to present the differences of using differing OS's and toolkits for different implementations.
Agreed, though even a single well-written updated version of Star Trader could demonstrate that BASIC need not be avoided on Raspberry Pi.

ejolson
Posts: 3039
Joined: Tue Mar 18, 2014 11:47 am

Re: Why Avoid BASIC on RPi?

Sat Dec 08, 2018 8:14 pm

Heater wrote:
Sat Dec 08, 2018 9:27 am
Then I get an assertion failure as the calculation of (z1 - z2 - z0) goes negative. I have no support for negative numbers and had assumed that would not happen.
Karatsuba multiplication works for me without negative numbers. Algebraically

Code: Select all

    bint z0 = low1 * low2;
    bint z2 = high1 * high2;
    bint s1 = low1 + high1;
    bint s2 = low2 + high2;
    bint z1 = s1 * s2;
    bint t1 = z1 - z2 - z0;
implies that

Code: Select all

    t1 == low1 * high2 + low2 * high1
which is positive. Have you tried reducing the base by a factor of ten to see if the problem goes away?

Heater
Posts: 12634
Joined: Tue Jul 17, 2012 3:02 pm

Re: Why Avoid BASIC on RPi?

Sat Dec 08, 2018 8:49 pm

ejolson,
Karatsuba multiplication works for me without negative numbers.
Ok. Thanks. That puts me on more solid ground.

It suggests I have a silly mistake somewhere. Or my that my current scheme of keeping all the numbers a power of two in length is messing things up some how.
Have you tried reducing the base by a factor of ten to see if the problem goes away?
Yes. I actually started out with base 10 and cranked it up from there.

When I find time I'll get back to it.
I'm still waiting for how the C++ Fibonacci program turns out, because it would be very nice to see something built with object-oriented overloaded-operators that actually works.
Ha!

Sadly I'm not in a good position to sing the praises of operator overloading here.

It also has a regular method API, x.sum(y), x.sub(y), x.mul(y) is one prefers.

ejolson
Posts: 3039
Joined: Tue Mar 18, 2014 11:47 am

Re: Why Avoid BASIC on RPi?

Sat Dec 08, 2018 8:55 pm

Heater wrote:
Sat Dec 08, 2018 8:49 pm
ejolson,
Karatsuba multiplication works for me without negative numbers.
Ok. Thanks. That puts me on more solid ground.

It suggests I have a silly mistake somewhere. Or my that my current scheme of keeping all the numbers a power of two in length is messing things up some how.
Have you tried reducing the base by a factor of ten to see if the problem goes away?
Yes. I actually started out with base 10 and cranked it up from there.

When I find time I'll get back to it.
I'm still waiting for how the C++ Fibonacci program turns out, because it would be very nice to see something built with object-oriented overloaded-operators that actually works.
Ha!

Sadly I'm not in a good position to sing the praises of operator overloading here.

It also has a regular method API, x.sum(y), x.sub(y), x.mul(y) is one prefers.
If you are looking for silly mistakes, maybe

Code: Select all

        int64_t product = value[0] * a.value[0];
should be changed to

Code: Select all

        uint64_t product = value[0] * a.value[0];
Still, the base might be ten times too big or more to handle all corner cases.

Return to “Off topic discussion”