Native sum

[MobsyaBot]

Issue by motib Monday May 11, 2015 at 07:55 GMT Originally opened as https://github.com/aseba-community/aseba/issues/380

---

I would like a native function to sum the elements of an array, instead of writing an explicit loop. Since the following code works, it should be possible to implement without changing the firmware.

var a[8] = [...]
var ones[8]
call math.fill(ones, 1)
call math.dot(sum, a, ones, 0)

[MobsyaBot]

Comment by stephanemagnenat Monday May 11, 2015 at 08:00 GMT

---

The problem is that native functions are dynamically enumerated. So in theory some targets might not have all math. functions for instance. We could implement "macros" that check for prerequisites and are available or not depending on which native functions are available, assuming that the name of the native functions provide similar semantics on all targets, which is the case currently with math. functions.

This is somewhat dependant on issue #278. But if we want to add new features to the Aseba language, we should think whether creating a consistent and Pythonish syntax would not be a better investment of time, as anyway adding proper macro support implies to revisit the whole compiler source code.

[MobsyaBot]

Comment by motib Monday May 11, 2015 at 08:23 GMT

---

I wasn't suggesting something as drastic as modifications to the language or the addition of new features to AESL!

What do you mean by "dynamically enumerated"? If all that means is that it is not guaranteed that all targets support the same set of native functions, then that is true today. Whatever happens (...what would happen?...) if "math.dot" isn't implemented will also happen when a new "math.sum" is called. A caveat to the user of all native functions would be sufficient.

[MobsyaBot]

Comment by stephanemagnenat Monday May 11, 2015 at 08:31 GMT

---

I wasn't suggesting something as drastic as modifications to the language or the addition of new features to AESL!

Then I do not understand how you would see math.sum implemented?

If all that means is that it is not guaranteed that all targets support the same set of native functions, then that is true today.

Indeed it is. By convention all currently-deployed targets link to the Aseba native library, but a third-party might decide not to do so. The reason might be that the micro-controller has not enough memory. I think it was the case in one of the micro-controller of the research robots using Aseba, but I am not sure any more.

A caveat to the user of all native functions would be sufficient.

I agree.

[MobsyaBot]

Comment by motib Monday May 11, 2015 at 08:43 GMT

---

Then I do not understand how you would see math.sum implemented?

I'm assuming (correct me if I am wrong) that the Studio compiler compiles AESL to bytecode that is interpreted by the Thymio microcontroller. I imagined that "math.sum" could be compiled into: allocate memory call fill call dot deallocate memory

This is such a minor issue that I'm willing to withdraw it if you think it raises major problem!

[MobsyaBot]

Comment by stephanemagnenat Monday May 11, 2015 at 08:46 GMT

---

This is such a minor issue that I'm willing to withdraw it if you think it raises major problem!

Your suggested implementation is correct, but it implies modifying the parser of the aesl grammar, so it is not trivial, as one first have to re-discover how the parser works ;-)

But I think that it is good to keep this issue here, as it is a wish to have, and this discussion we have now as some value. I still hope that at some point we can have a Pythonish syntax, and while defining this syntax all the wishes should be considered.