Deep Learning C library ported to RISC OS

Hi everyone,
if anyone is interested about this type of coding and application development, I have ported a simple and fully functional Deep Learning / Artificial Neural Network library to RISC OS written in C.

Info
The library works and compiles with both ROOL DDE and GCC for RISC OS. It is quite fast (even if it is not yet using any HW acceleration).

The library (compiled) is about 6KB in size, so very small and so very versatile (could be used also in a PICO for example). It also comes with a lot of code examples (which you can run straight away without need to recompile them) and the source itself. It comes with all the building scripts and everything.

License is ZLib license so another form of open source license.

I also ported the documentation and adapted it to the specific cases for RISC OS use.

It also comes with a full testing tool and perf testing too.

The library is pre-compiled for multiple architectures, from the old ARMv2 running on RISC OS 3.x, to the latest and greatest 32bit (ARMv5, v6 and v7).

The library can be trained using IRIS datasets as well which makes it useful for image recognition or to create “intelligent” effects/plugins for graphic applications etc.

This is the first of a set of Deep Learning libraries I am porting to RISC OS for fun, hope someone will find it useful.

Status
I am still working to improve documentation and examples as well as adding more GCC optimised compilation procedures, however all the tests and examples works so I guess it’s almost done :)

Repository
At the moment the library is on my github only, but I am planning to package it with RiscPkg and as well for the Pling store (depending on the interest).

Since it’s on github only you’ll need a browser slightly more capable than NetSurf to browse it via web.

Repo link here: https://github.com/ZFPSystems/genann

Documentation
The sources comes already with documentation and examples.

I also started to write a series of introductory articles with a lot of information here: https://paolozaino.wordpress.com/2020/09/05/risc-os-artificial-intelligence-and-machine-learning-part-1/

Gosh!

Is it that bad John? :D

Is it that bad John? :D

No – it’s a “Hey, amazing!”. A bit like a US “Wow!”.

And how could I use this myself? The opportunities are difficult to even envisage! Let’s see what others think!

No – it’s a “Hey, amazing!”. A bit like a US “Wow!”.

Thanks.

And how could I use this myself? The opportunities are difficult to even envisage!

Understood. So for the practical usage I added a lot of examples with source code.

For the “usefulness” in your own code this type of libraries can provide “decisional” support in certain scenarios that would be otherwise way more complex to code.

Some practical examples of use of NN are:
Graphics
- Face recognition (so if you are the author of a graphic software like PhotoDesk for example, you could use it to add such a feature to it).
- Train it to identify buildings in a picture to generate better maps out of it.
- Detect cars in a video, to count them for ex. (for a parking system for example)
Audio
- Train it to identify certain sounds in a stream
- Train it to detect notes out of a song to help people learning how to play that song

Hope this helps a bit…

I’m immediately thinking face recognition entry, or better still fingerprint, using a pico!

Keys are so 20th century!

lol :)

No – it’s a “Hey, amazing!”.

Quick note for non-Brits: Brits are masters of understatement. An example from the Korean War – a British force was almost completely wiped out (~500 captured, 59 MIA, 39 escaped) because the Americans failed to understand that describing the situation as “a bit sticky” was an entirely appropriate British reaction to 600 British troops vs 30,000 Chinese.

Another popular Brit phrase. “A spot of bother”. Covers everything from “my compiler just failed to build this code” to “my house is burning down as a result of a direct meteor strike”.

I’m immediately thinking face recognition entry,

One of these days we might be able to plug a camera into the Pi’s camera port and use it under RISC OS…?

Quick note for non-Brits: Brits are masters of understatement.

Thanks for the explanation.

One of these days we might be able to plug a camera into the Pi’s camera port and use it under RISC OS…?

Yup that would be an interesting challenge under RISC OS. Isn’t the whole ISP stuff closed source? (Or do I remember wrong?)

Very nice work.
Great to see potentially very useful libraries ported to RISC OS. Will download tomorrow and do a thorough investigation.

Keep on coding :-)

Thanks a lot! :)

If you find any performance issue or obviously bugs please let me know and if you want to fix them yourself please feel free, it should allow you to commit your fixes (if not please let me know and I’ll fix that).

For everyone interested,
last night I fixed few issues in the repo that were caused by accessing it directly with a VirtualAcorn instance to try older releases of DDE compiler.

I also re-compiled everything with the very latest release of ROOL DDE they released yesterday.

If you just want to play with the examples and the performance test library you can play with it without the need to recompile them.

Enjoy!

This makes me extremely happy.

While this is the main reason I own a Jetson Nano, and a couple of K210 boards for running some of the networks, I have been really wanting something on RISC OS. I’m looking forward to trying it out.

Some may find the application !Nocomma, to be found here useful for changing filetypes and names in GenannExamples and GennanTests.

Some may find the application !Nocomma, to be found here useful

Is there a routine for doing the opposite?

If so, and the two were bundled with the same library, a modifier key could be used to choose which process was required.

Or the script could toggle between the two automagically depending on what it found.

And it would be fun!

Tristan:

This makes me extremely happy.

Thanks a lot for your feedback, and actually I like the Jetson Nano a lot too, I wish I had more spare time to work on this type of things more.

Also your type of feedback is what I am really looking forward, for both understand if there is interest is such type of effort on RISC OS or not, however the number of cloners of the repo already showed there seems to be quite some interest from the community to this type of applications/libraries, which is cool!

Thanks everyone who cloned/downloaded the repo!

GavinWraith:

Thanks a lot for the !Nocomma :)

Since we do not yet have a fully working git, I also recommend to git clone the repo on a linux machine (RPi with Raspbian is cheap and works very well) and then share it via Samba Server with RISC OS. OmiClient for RISC OS 5 works very well and you can also compile code on a shared omiclient directory or run code from it.

Obviously I’m looking forward for the full git client for RISC OS :)

Is there a routine for doing the opposite?

There is now. No point in having a common library as they are both tiny; the extra machinery for switching between the two makes it not worth the effort. I mistrust automagic. A box of small simple tools is usually easier to use than some shiny hypercallifragilismus.

No point in having a common library as they are both tiny;

Point taken!

It was elegance that I was after!

I enjoy whipping up small utilities like !Comma and !Nocomma. That is partly because they do not require anything too demanding that would tax my concentration, and partly because RiscLua is ideally suited for this sort of thing: scanning a directory, renaming and retyping. Any version of RiscLua from the last decade would do equally well.

Lua has been a good candidate for bare metal implementation. I have often entertained the thought that it would be nice to have RiscLua built in to RISC OS at a much lower level, so that Obey files would be replaced by RiscLua programs. The taskmanager would use Lua’s garbage-collecting memory allocator rather than flex. The Lua table would replace consecutive arrays of bytes. Applications would call on the underlying layer of Lua for memory management, thread control, IO, string handling, and database services. I realise that memory allocation and garbage collection are very complicated and much-studied topics, crucial for the behaviour of an operating system. OK, it would be too radical a step to call it RISC OS anymore. Just dreaming.

I tried the GenannTests and GnARMv6Tests on my pi zero. Both passed.

Gavin. That sounds extremely complex. I too agree that it would be essentially a new OS. For now, I’m happy to be able to run Lua scripts. Although possessing a fatal flaw regarding running an external program, and now being obsolete, I don’t know if you noticed that when I was working on the H3 RO port I had a Lua script that would work out what modules I wanted, and fetched the missing ones from the SVN server.
RiscLua does get used.

Back on topic. I’m looking forward to having a play with this genann port.

Tristan:

I tried the GenannTests and GnARMv6Tests on my pi zero. Both passed.

Awesome! Thanks a lot for let me know, I’ll add the Pi Zero to the list of Tested Systems in the ReadMe!

Back on topic. I’m looking forward to having a play with this genann port.

Very cool! Genann is very simple, so also very easy to use, I wanted to start with something everyone with a bit of C programming knowledge can use.

Time permitting I’ll try to port more complex and powerful libraries. I think I’ll stick to C at the beginning because without HW acceleration support the risk is that the libs may run too slow (in interpreted languages), especially with the type of ARM chips used for RISC OS at the moment.

Also don’t forget Gennan is thread safe, so it should work fine in old cooperative multi-threading libs like !Vista or could be a perfect candidate to test the new Multi-core support that is being introduced in RISC OS.

Since Lua seems to be having quite some followers, I may be able to either write some wrappers in Lua or something if people would like to try that. Maybe it’s an option. Maybe Gavin would like to help me with that? :-)

I have to confess that the whole topic of neural nets is new to me. I read Shannon and Macarthy on Automata way back, but statistics and applied mathematics have been antipodal on planet Math from where I have been. To judge from the Gennan documentation and where it leads, it is a huge subject. I look forward to learning more. Until I do, I am probably of not much use. Maybe I can pose some questions, probably naive, and others can tell me whether they are relevant. I note that the first example is about training an ann to recognize the XOR function. What about Heron’s formula for the area of a triangle with sides a,b,c? The area is 1/4 times the square root of the product (a+b+c)(a+b-c)(a-b+c)(-a+b+c) [Hint: the triangle collapses if any of the factors is zero]. It has to be this for reasons of symmetry, once you know that the square of the area is a polynomial expression in a,b and c. But this is algebra, of course, and miles away from real numbers and neural nets. Nevertheless, how do you train a neural net to know how to calculate areas of triangles?

I too agree that it would be essentially a new OS.

Yes, but the idea to have something else then Obey files for !Boot !Run, etc. is really great (is it possible?). And the idea to have more than one interpreter in ROM, or in standard Boot, is great too. Some would like Bash or Basic. I would love Rexx!

David: (Off topic answer, in hope we’ll try to stay on topic)

Yes, but the idea to have something else then Obey files for !Boot !Run, etc. is really great (is it possible?).

Of course is already possible (and since the early days of RISC OS if I remember well). Have you tried to actually use different languages for !Boot and !Run? For instance a different FileType, let’s say BASIC and see it if works? If you try you’ll see that it works and RISC OS will be perfectly happy with a !Run written in BASIC.

About Rexx, to use Rexx instead of BASIC or Obey, first of all port a Rexx interpreter to RISC OS (’cause as far as I know no one ported it yet), you can use Regina or BRexx (up to your preference). Then define a FileType for Rexx scripts for your Rexx interpreter, make sure that your chosen FileType is not being used by other applications, register it with ROOL and create Run Aliases in your Rexx Interpreter !Boot file to tell RIC OS that to run FileType_XXX it needs to use your interpreter.

Set File$Type_XXX DavidRexx
Set Alias$@RunType_XXX Run <DavidRexx$Dir>.rexx %%*0

Final touch put your interpreter !App directory in the RISC OS UniBoot sequence and/or make it visible from the boot sequence and voila’ you can now write your scripts in Rexx :)

Same for Lua or any other interpreter you want.

About replacing Obey with an heavy interpreter, that is a different story and not so sure it’s worth pursuing as the only difference would be to be able to replace the Obeys in the boot sequence compared to what you can do already now and without the problems of such a replacement would bring.

I used this approach many times in the 80s/90s when I wrote some scripting language for the Archimedes to help me to solve certain problems. So it works since back in the Archimedes days.

Hope this helps and also hope we can stay a bit more on topic if that’s ok for everyone :)