 Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me. |
Forum Index : Microcontroller and PC projects : MM+ function request
| Author | Message | ||||
kiiid Guru  Joined: 11/05/2013 Location: United KingdomPosts: 671 |
Geoff, I know this is not hard so it only a matter of suitability of inclusion. I would like to request two functions added to the MMBasic. The first one is (I have mentioned it before) the equivalent of ~ in C. Currently the NOT function returns only 1 or 0, which is exactly what it is supposed to be doing, but that is not enough for effective bit operations. The second one exists in Pascal and other languages. It is direct assignment of an array to another one. Of course this can be done from within the MMBasic itself, but anyone who works intensively with arrays would agree that this functionality is heavily missed in BASIC in comparison to other languages. I have seen this made even the smart way where when assigning arrays with different dimensions, only the elements from the lowest dimension are actually copied. How about these? Thanks http://rittle.org -------------- |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 3683 |
You can do ~ using XOR with all ones. How about a Cfunction for array copying? Such copying can easily get very slow so a CFunction might help keep this feature to only those who know what they're doing and understand the potential consequences. John |
||||
Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3169 |
I have done some thinking on this. Firstly, the bitwise NOT can be done using XOR as John pointed out. The second "feature" would be handy in some cases but the syntax would be a special case. A simple assignment would be OK (eg, a() = b()) but something like a() = b() + c() would be illegal. Not very logical. Just saying "only good for assignment" seems a bit lame to me. I believe that a programming language should not be littered with special cases (although they are hard to avoid). Geoff Geoff Graham - http://geoffg.net |
||||
| kiiid Guru Joined: 11/05/2013 Location: United KingdomPosts: 671 |
You can make a separate assignment operator for arrays. Why not a() (=) b() Then it won't be confused with the standard = This is not a 'special case'. Work with arrays is a very important and integral part of any language, and generally the most time-consuming too, so why not optimise it a bit, especially in an interpreted language? http://rittle.org -------------- |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2302 |
it strikes me that a very simple/compact custom fuction could be written to do a block move: MOVE (destination, source, numbytes) where the function itself would perform no range checking - it would be up to the user to make sure that the number of bytes moved didn't overrun the size of destination. further custom functions could be written for performing other array or matrix operations as required. for instance: MADD (destination, source, m, n) MSUB (destination, source, m, n) where destination and source are both matrixes of m by n floats MMUL (destination, multiplier, m, n) MPROD (destination, source1, source2, m1, n2) etc... these are all examples of where custom functions could perform complicated operations that have quite specific applications for a small number of users. although, i can see MOVE() having some quite generic uses. cheers, rob :-) |
||||
| erbp Senior Member  Joined: 03/05/2016 Location: AustraliaPosts: 186 |
This suggestion is very sensible and actually matches the ARRAY.COPY method supported in the .NET framework (at least the most basic of the variations of the COPY method). I don't know if MOVE or COPY is the best verb to use. MOVE does carry the connotation that the data is no longer present in the source after the action has been performed, so unless that is the function being implemented, maybe COPY would be the better alternative. Regards, Phil. |
||||
 Print this page |
