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

Re: Why Avoid BASIC on RPi?

Sun May 05, 2019 8:22 am

ejolson,
The standard way in Unix to run interpreted languages as commands is using #! at the beginning of a text file...
I was not concerned with the shell script part. After all we can do this:

Code: Select all

$ cat fibo.max
print(fib(4784969))$

$ time maxima --very-quiet -b=fibo.max  | head     -c 64

batch("fibo.max")

read and interpret file: #p/mnt/c/Users/heatInappropriate ioctl for device

real    0m0.645s
user    0m0.047s
sys     0m0.375s
$ time maxima --very-quiet -b=fibo.max  | tail     -c 64
699706378405156269
                                   fibo.max

real    0m2.888s
user    0m0.750s
sys     0m2.125s
$
Again with the pipe into head problem.

I'm inclined to say this does qualify for the fibo(4784969) chalenge.

Mathematica gets the job done. But being a closed source solution is not going in the repo.
F(n)=(phi^n-(-phi)^(-n))/sqrt 5
That's just what I was thinking.

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

Re: Why Avoid BASIC on RPi?

Sun May 05, 2019 10:21 am

Heater wrote:
Sun May 05, 2019 8:22 am
Mathematica gets the job done. But being a closed source solution is not going in the repo.
That's fair enough, though I don't remember using open-source tools as one of the original requirements.

Isn't being open source just another implementation detail? It seems similar to whether GMP is used behind the scenes and (to repeat what had been said previously) unrelated to the expressiveness of the language itself. Was that old Algol 60 compiler for the Elliott 803 open source? What about Java?

From what I understand Java is so closed that the API is patented and to the astonishment of many, legally impossible to reimplement using cleanroom techniques.

Note that the tool chain used to develop the Visual Basic Fibonacci code was fully open source. More information is available here. In my opinion, the version of Karatsuba multiplication coded in Visual Basic is also easy to read. I will be quite happy if the Fibonacci code written in open-source Visual Basic could be included in the repository.

User avatar
PeterO
Posts: 4538
Joined: Sun Jul 22, 2012 4:14 pm

Re: Why Avoid BASIC on RPi?

Sun May 05, 2019 1:02 pm

ejolson wrote:
Sun May 05, 2019 10:21 am
Was that old Algol 60 compiler for the Elliott 803 open source?
Different times ! The source to the compiler was circulated (in printed form) at some point but I've never found it.
Elliotts provided detailed manuals that contained enough information for you to build your own 803 :-)
Image
PeterO
Discoverer of the PI2 XENON DEATH FLASH!
Interests: C,Python,PIC,Electronics,Ham Radio (G0DZB),1960s British Computers.
"The primary requirement (as we've always seen in your examples) is that the code is readable. " Dougie Lawson

User avatar
scruss
Posts: 2222
Joined: Sat Jun 09, 2012 12:25 pm
Location: Toronto, ON
Contact: Website

Re: Why Avoid BASIC on RPi?

Sun May 05, 2019 2:03 pm

ejolson wrote:
Sun May 05, 2019 10:21 am
Note that the tool chain used to develop the Visual Basic Fibonacci code was fully open source. …
I didn't know there was a Mono VB compiler for Linux. The source input format barely looks like any BASIC I remember - since when did we wrap stuff we needed to run in a main function?

Is there a proper IDE for this? The strength of BASIC for me is its approachability: though I may have grown out of doing this somewhat*, in a BASIC system I should be able to type

Code: Select all

PRINT "ALAN IS A WALLY!"
and see the result immediately somewhere.
I will be quite happy if the Fibonacci code written in open-source Visual Basic could be included in the repository.
You could always fork https://github.com/ZiCog/fibo_4784969 and add it through a pull request

--
*: None of the Alans that 12 year old me would have written that about are, in fact, wallies. One is a senior partner at a huge law firm in Glasgow, the other is head of Classics at a Scottish public school.
‘Remember the Golden Rule of Selling: “Do not resort to violence.”’ — McGlashan.

User avatar
ScriptBasic
Posts: 885
Joined: Wed Apr 03, 2019 5:53 pm
Location: Anacortes, WA USA
Contact: Website Twitter

Re: Why Avoid BASIC on RPi?

Sun May 05, 2019 2:18 pm

If I understand your explanation of how it works it actually silently looses precision when swapping from integers to floats behind the scenes.
It extends MAXINT with Double precision transparently to extend integer range.

User avatar
ScriptBasic
Posts: 885
Joined: Wed Apr 03, 2019 5:53 pm
Location: Anacortes, WA USA
Contact: Website Twitter

Re: Why Avoid BASIC on RPi?

Sun May 05, 2019 2:33 pm

I didn't know there was a Mono VB compiler for Linux. 
64 bit Linux. No support for 32 bit.

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

Re: Why Avoid BASIC on RPi?

Sun May 05, 2019 3:15 pm

ejolson,
I don't remember using open-source tools as one of the original requirements.
You remember correctly. I guess nobody thought about it at the time.
Isn't being open source just another implementation detail?
No.

If it were then one could say things like "I have implemented my new project in GPL" or "function X is implemented in the MIT license". Which I think you will agree is gibberish.
It seems similar to whether GMP is used behind the scenes and (to repeat what had been said previously) unrelated to the expressiveness of the language itself.
It's true that the licensing is orthogonal to the design/functionality. It's not similar to the restriction on using GMP or other non-standard libraries, that is about the entrants implementation not the licence the language they use is released under.
Was that old Algol 60 compiler for the Elliott 803 open source?
Probably. Not that people worried about such silly things back then.

ALGOL 60 has an internationally agreed standard. The are many implementations floating around, even quite new ones. For example here is the source of the first ALGOL 60 compiler by Dijkstra–Zonneveld: https://research.tue.nl/en/publications ... ologica-x1 Written in assembler by the way, all 4000 instructions of it! Plus a translation in Pascal.
What about Java?
Hmm... As far as I can tell the code Java code we have will run under the OpenJDK which is released under the GPL. Then there is GCJ.
..the tool chain used to develop the Visual Basic Fibonacci code was fully open source. More information is available here. In my opinion, the version of Karatsuba multiplication coded in Visual Basic is also easy to read. I will be quite happy if the Fibonacci code written in open-source Visual Basic could be included in the repository.
Sorry for the delay. I'll get right on it....

As for my stance on solutions dependent on proprietary languages, see my lengthy post here yesterday. To which I can add: I don't want to promote, endorse or advertise commercial products without remuneration. Might be open to offers though...:)

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

Re: Why Avoid BASIC on RPi?

Sun May 05, 2019 3:22 pm

PeterO wrote:
Sun May 05, 2019 1:02 pm
ejolson wrote:
Sun May 05, 2019 10:21 am
Was that old Algol 60 compiler for the Elliott 803 open source?
Different times ! The source to the compiler was circulated (in printed form) at some point but I've never found it.
Elliotts provided detailed manuals that contained enough information for you to build your own 803 :-)
Image
PeterO
That's a good reminder.

In the beginning there was a debate whether computer programs could even be copyrighted. Just as the Fibonacci doubling formula may not be possible to copyright, so many argued that a program may not be. Computer manufacturers made their money selling computers and software was freely provided to give the purchasers something to do with the hardware.

When MITS followed the same approach with Altair Basic, it resulted in Bill's famous letter. The consumer was easily convinced. Soon computer manufacturers were making large sums of money selling software. Even IBM put high prices on their software as part of an anti-trust settlement.

One of the holdouts was Sun Microsystems. However, Sun did not make enough money selling hardware to compete with the companies profiting from software, so a database company bought them, closed the hardware division and plausibly went to court to get the software money. In this alternative reality, the computer company with the foresight to create encrypted silicon-secured memory to protect against spectre-like side-channel attacks long before they were popular, was purchased only to monetise Java which had market share only because it had not previously been monetised. While opinions differ, at least this story makes better poetry than purchasing DEC for its direct market sales team and throwing the fastest CPU currently on the market out with the bath water.

Since there is not much difference between lost-source software and closed source, why avoid Basic?

User avatar
ScriptBasic
Posts: 885
Joined: Wed Apr 03, 2019 5:53 pm
Location: Anacortes, WA USA
Contact: Website Twitter

Re: Why Avoid BASIC on RPi?

Sun May 05, 2019 3:40 pm

why avoid Basic?
Didn't your hear that BASIC is dead and everyone has a snake as a pet.

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

Re: Why Avoid BASIC on RPi?

Sun May 05, 2019 3:42 pm

ScriptBasic wrote:
Sun May 05, 2019 2:33 pm
I didn't know there was a Mono VB compiler for Linux. 
64 bit Linux. No support for 32 bit.
The 32-bit version is in the Raspbian repositories if you'd like to try it.
Last edited by ejolson on Sun May 05, 2019 3:59 pm, edited 1 time in total.

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

Re: Why Avoid BASIC on RPi?

Sun May 05, 2019 3:47 pm

ejolson,

"lost-source software" I like the expression.

When I was working for Nokia networks back in the day we had to implement a protocol used for configuring/monitoring a new generation of base stations, micro-wave links etc. It had to be compatible with some handheld terminal device that was used for device configuration previously. They had lost the source code to that so it was a reverse engineering effort...

Nokia had a ton of lost documentation as well. Thousands and thousands of documents in some old version of Word that nobody could read with whatever new version of Word there was at the time. Luckily I found all that could be opened in Star Office (Now OpenOffice).

User avatar
ScriptBasic
Posts: 885
Joined: Wed Apr 03, 2019 5:53 pm
Location: Anacortes, WA USA
Contact: Website Twitter

Re: Why Avoid BASIC on RPi?

Sun May 05, 2019 3:57 pm

scegg wrote: .NET Core framework cannot be installed on Raspbian due to lacking of 32-bit system support.
Arm32 builds are available as community supported builds for .NET Core 2.0. There is no SDK that runs on ARM32 but you can publish an application that will run on a Raspberry Pi.
Half Baked!
Last edited by ScriptBasic on Sun May 05, 2019 4:45 pm, edited 1 time in total.

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

Re: Why Avoid BASIC on RPi?

Sun May 05, 2019 4:42 pm

Julia was my first girl friend. Now I find she can do this:

Code: Select all

$ cat fibo.julia
#!/usr/bin/julia

"""Returns the tuple (F(n), F(n+1))."""
function fibo(n::Int)
    if n == 0
        return (BigInt(0), BigInt(1))
    else
        a, b = fibo(div(n,2))
        c = a * (b * BigInt(2) - a)
        d = a * a + b * b
        if iseven(n)
            return (c, d)
        else
            return (d, c + d)
        end
    end
end

n = 4784969
f = fibo(n)[1]
try
    print(f)
catch
end

$ time ./fibo.julia | head -c 32
10727395641800477229364813596225
real    0m0.885s
user    0m0.688s
sys     0m0.703s
$ time ./fibo.julia | tail  -c 32
4856539211500699706378405156269
real    0m0.863s
user    0m0.641s
sys     0m0.641s
$

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

Re: Why Avoid BASIC on RPi?

Sun May 05, 2019 4:48 pm

Heater wrote:
Sun May 05, 2019 4:42 pm
Julia was my first girl friend. Now I find she can do this:

Code: Select all

$ cat fibo.julia
#!/usr/bin/julia

"""Returns the tuple (F(n), F(n+1))."""
function fibo(n::Int)
    if n == 0
        return (BigInt(0), BigInt(1))
    else
        a, b = fibo(div(n,2))
        c = a * (b * BigInt(2) - a)
        d = a * a + b * b
        if iseven(n)
            return (c, d)
        else
            return (d, c + d)
        end
    end
end

n = 4784969
f = fibo(n)[1]
try
    print(f)
catch
end

$ time ./fibo.julia | head -c 32
10727395641800477229364813596225
real    0m0.885s
user    0m0.688s
sys     0m0.703s
$ time ./fibo.julia | tail  -c 32
4856539211500699706378405156269
real    0m0.863s
user    0m0.641s
sys     0m0.641s
$
I've always found Julia quite attractive (as a programming language), though a bit immature.

Is try and catch used to handle the errors when stdout is unexpectedly closed?
Last edited by ejolson on Sun May 05, 2019 4:55 pm, edited 3 times in total.

User avatar
ScriptBasic
Posts: 885
Joined: Wed Apr 03, 2019 5:53 pm
Location: Anacortes, WA USA
Contact: Website Twitter

Re: Why Avoid BASIC on RPi?

Sun May 05, 2019 4:48 pm

Another example of BIGINT bias.

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

Re: Why Avoid BASIC on RPi?

Sun May 05, 2019 5:01 pm

We don't tolerate BIGINT bias around here. We have solutions using teeny weeny little ints in ALGOL, various BASICs, C, C++, Javascript.

It's not the size of your integers that counts. It's what you can do with them.

User avatar
ScriptBasic
Posts: 885
Joined: Wed Apr 03, 2019 5:53 pm
Location: Anacortes, WA USA
Contact: Website Twitter

Re: Why Avoid BASIC on RPi?

Sun May 05, 2019 5:10 pm

It's not the size of your integers that counts. It's what you can do with them.
Great that non-BIGINT languages can build a million digit string. Where do you go from there?

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

Re: Why Avoid BASIC on RPi?

Sun May 05, 2019 5:31 pm

ScriptBasic,
Great that non-BIGINT languages can build a million digit string
I'm not sure what you mean.

The solution I mentioned don't use strings for their big integers. They use arrays of normal integers.
Where do you go from there?
Then you show how elegantly your language can express the algorithms required to get the result. For example the Javascript entry:
https://github.com/ZiCog/fibo_4784969/b ... ratsuba.js

It's just a bit more code to write than if you had big ints built in.

User avatar
ScriptBasic
Posts: 885
Joined: Wed Apr 03, 2019 5:53 pm
Location: Anacortes, WA USA
Contact: Website Twitter

Re: Why Avoid BASIC on RPi?

Sun May 05, 2019 5:38 pm

The solution I mentioned don't use strings for their big integers. They use arrays of normal integers.
Cute. Does that mean the language must support undefined dynamic arrays?

How could I use the fibo results stored in an integer dynamic arrary in further math calculations?
Last edited by ScriptBasic on Sun May 05, 2019 5:48 pm, edited 1 time in total.

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

Re: Why Avoid BASIC on RPi?

Sun May 05, 2019 5:47 pm

I'm taking a liking to Julia. She knew what I wanted to do pretty quickly with me having to explain it.

Julia is hot. When she is warmed up she can do 10 of our fibo's in 2.5 seconds.

Code: Select all

$ cat fibo.julia
...
...
n = 4784969
for i = 0:10
    f = fibo(n + i)[1]
    try
        println(f)
    catch
    end
end

$ time ./fibo.julia | head -c 32
10727395641800477229364813596225
real    0m2.478s
user    0m2.328s
sys     0m0.656s
Seems Julia dynamically compiles everything to native code. So there is a lot of start up overhead.
Last edited by Heater on Sun May 05, 2019 6:00 pm, edited 1 time in total.

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

Re: Why Avoid BASIC on RPi?

Sun May 05, 2019 5:50 pm

ScriptBasic wrote:
Sun May 05, 2019 5:38 pm
The solution I mentioned don't use strings for their big integers. They use arrays of normal integers.
Cute. Does that mean the language must support undefined dynamic arrays?
You mean arbitrary sized dynamically allocated arrays?
Yes, but then most practical languages can of course.

User avatar
ScriptBasic
Posts: 885
Joined: Wed Apr 03, 2019 5:53 pm
Location: Anacortes, WA USA
Contact: Website Twitter

Re: Why Avoid BASIC on RPi?

Sun May 05, 2019 5:53 pm

Julia is a great fractal language I used in the past to produce some amazing output.

Animated Julia
Last edited by ScriptBasic on Sun May 05, 2019 6:04 pm, edited 1 time in total.

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

Re: Why Avoid BASIC on RPi?

Sun May 05, 2019 5:58 pm

ScriptBasic,
Does that mean the language must support undefined dynamic arrays?
No. Why should it?

One can always statically define arrays or whatever of the size(s) one needs up front and manage things ones self. Like one might do in ALGOL or C (if not using malloc) or BASIC etc. That's what we used to do in the old days.

See examples in the challenge repository: https://github.com/ZiCog/fibo_4784969

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

Re: Why Avoid BASIC on RPi?

Sun May 05, 2019 6:11 pm

Heater wrote:
Sun May 05, 2019 5:58 pm
ScriptBasic,
Does that mean the language must support undefined dynamic arrays?
No. Why should it?
I suppose its fixed at 4784969 !

Otherwise fibo(n), where n is unknown in advance ...

User avatar
ScriptBasic
Posts: 885
Joined: Wed Apr 03, 2019 5:53 pm
Location: Anacortes, WA USA
Contact: Website Twitter

Re: Why Avoid BASIC on RPi?

Sun May 05, 2019 6:17 pm

Heater,

If this challenge would result in something useful in ScriptBasic, I would put forward the effort to try to stay within the rules of the challenge. It took me 15 minutes to create a Fibonacci extension module producing the correct result and in the top 10 of the performance category.

BASIC is about minimizing the number of steps to produce a result. My example follows that rule.
Last edited by ScriptBasic on Sun May 05, 2019 6:32 pm, edited 1 time in total.

Return to “Off topic discussion”