I'm trying to construct an two dimensional array on an arduino uno which uses an atmega328. I want an array of booleans with the size of 256 * 18. This is to big for the 2KB RAM so i wanted to save it to the PROGMEM(avr). how can i do this and how can i acces the variables? i found some tutotials about doing th same with chars or strings but there is no data type for booleans. what is the best way zo save and extract booleans in/from chars.
As you have likely read about using program space (aka flash). It is necassary to use special macro's that work on the pointers, as detailed at avr-libc/user-manual.
That said, see my example of a 2D matrix in program space example of storing the 2D array along with the example of calling the data from the 2D array
It should work for larger scale.
Where you sneak a second question at the end, about booleans. Note booleans while treated as 0 or 1 really consume a full byte.
You may want to consider #include and using the vector< bool > type as this will consume only a single bit per unit. As each element occupies a single bit.
Related
I have found the usual answer for determining the size on an array - 'variable = sizeof buffer/sizeof *buffer;' or similar which gives the declared size
Other than passing a counter variable around when an array is 'filled', is there a way (a command or function - something similar to the above 1 liner) to find the used number of elements in a given array?
And I don't mean searching for an end of line character or implementing a circular buffer. I only expect between 5 and 25 Bytes in any given transaction.
Edit:- for omissions in original post (as requested)
Language C (via Atmel Studio)
8bit Bytes (non characters)
I don't know the meaning of 'strong-typed' and 'associative', but eventually it will be semi random bytes from a device and not fixed numbers like in a string
Fixed size declared array (ultimately volatile)
Thanks
The C standard generally does not provide any way for tracking or determining which or how many elements of an array are used.
This is probably a simple question. However I am simply wondering how to I create a string or array in ruby so that I know that it is 1MB large. Or any size for that matter.
This is not possible. The Ruby Language Specification only specifies the behavior of strings, not how they are stored. It is perfectly legal, for example, for an implementation to compress strings (in which case the size of the string in memory will be smaller than you think), to de-duplicate them (in which case the size will be 0). Rubinius, for example, stores strings as ropes, as far as I know, which means that parts of strings may be shared with parts of other strings, so the notion of "size" isn't even well-defined in that case.
To create a million-character string:
"a" * 10**6
If you want it to read well and are using Rails or don't mind requiring active_support/core_ext then you can do the following:
"a" * 1.megabyte
"a" * 10.megabytes
This uses the traditional definition of megabyte (power of 2 instead of 10).
Note that this is assuming you're sending ASCII characters to a service, not trying to estimate how Ruby stores them.
You can set the size of the internal String buffer these days with the capacity: keyword argument. It's great if you know the size of a String up front, since you'll then not need reallocs as you shovel on repeatedly.
String.new(capacity: 10**6)
Is there an effective way to declare a very big matrix (let's say 40.000.000x10) of integers in Matlab?
If I do it like this:
var=uint8(zeros(40000000,10));
It works very well in command window.
But the same code works much worse in function! If I do this somewhere in the function, it firstly creates a 40.000.000x10 matrix of doubles and then converts it to 8-bit integers matrix. I would prefer if it was created as integer matrix from the very begin, as in commands window. I have to work with even bigger matrices and I ran out of RAM when it initializes such matrix of doubles (although there would be enough memory if it initialized the matrix as integers). And I don't really need doubles here, all numbers are in range 0:100.
Hope you understood the problem :D
From: MATLAB: uint8
var = zeroes(40000000,10, 'uint8')
Maybe you should use this, which is more efficient.
var = zeros(40000000, 10, 'uint8');
If you want to be a bit tricky and save a small amount of time, you can allocate your array of uint8 zeros this way:
var(40000000,10) = uint8(0);
See here for some details on this type of preallocation. Be careful with this scheme. If you allocate var as one size and then allocate it again without clearing it as a smaller size array using this method, the size won't actually change and the data won't be zeroed out. Essentially, this scheme is only good if the array (var here) doesn't exist yet.
I'm working in ANSI C with lots of fixed length arrays. Rather than setting an array length variable for every array, it seems easier just to add a "NULL" terminator at the end of the array, similar to character strings. Fot my current app I'm using "999999" which would never occur in the actual arrays. I can execute loops and determine array lengths just by looking for the terminator. Is this a common approach? What are the issues with it? Thanks.
This approach is technically used by your main arguments, where the last value is a terminal NULL, but it's also accompanied by an argc that tells you the size.
Using just terminals sounds like it's more prone to mistakes in the future. What's wrong with storing the size along with an array?
Something like:
struct fixed_array {
unsigned long len;
int arr[];
};
This will also be more efficient and less error-prone.
The main problem I can think of is that keeping track of the length can be useful because there are built in functions in C that take length as a parameter, and you need it to know the length to know where to add the next element too.
In reality it depends on the size of your array, if it is a huge array than you should keep track of the length. Otherwise looping through it to determine the length every time you want to add an element to the end would be very expensive. O(n) instead of the O(1) time you normally get with arrays
The main problem with this approach is that you can't know the length in advance without looping to the end of the array - and that can affect the performance quite negatively if you only want to determine the length.
Why don't you just
Initialize it with a const int that you can use later in the code to check the size, or
Use int len = sizeof(my_array) / sizeof(the_type).
Since you're using 2-dimensional arrays to hold a ragged array, you could just use a ragged array: type *my_array[];. Or you could put the length in element 0 of each row and treat the rows as 1-indexed arrays. With some evil trickery you could even put the lengths at element -1 of each row![1]
Left as exercise ;)
In other languages like C++, you have to keep track of the array length yourself - how does Delphi know the length of my array? Is there an internal, hidden integer?
Is it better, for performance-critical parts, to not use Length() but a direct integer managed by me?
There are three kinds of arrays, and Length works differently for each:
Dynamic arrays: These are implemented as pointers. The pointer points to the first array element, but "behind" that element (at a negative offset from the start of the array) are two extra integer values that represent the array's length and reference count. Length reads that value. This is the same as for the string type.
Static arrays: The compiler knows the length of the array, so Length is a compile-time constant.
Open arrays: The length of an open array parameter is passed as a separate parameter. The compiler knows where to find that parameter, so it replaces Length with that a read of that parameter's value.
Don't forget that the layout of dynamic arrays and the like would change in a 64-bit version of Delphi, so any code that relies on finding the length at a particular offset would break.
I advise just using Length(). If you're working with it in a loop, you might want to cache it, but don't forget that a for loop already caches the terminating bounds of the loop.
Yes, there are in fact two additional fields with dynamic arrays. First is the number of elements in the array at -4 bytes offset to the first element, and at -8 bytes offset there's the reference count. See Rudy's article for a detailed explanation.
For the second question, you'd have to use SetLength for sizing dynamic arrays, so the internal 'length' field would be available anyway. I don't see much use for additional size tracking.
Since Rob Kennedy gave such a good answer to the first part of your question, I'll just address the second one:
Is it better, for performance-critical parts, to not use Length() but a direct integer managed by me?
Absolutely not. First, as Rob mentioned, the compiler does it's thing to access the information extremely quickly, either by reading a fixed offset before the start of the array in the case of dynamic ones, using a compile-time constant in the case of static ones, and passing a hidden parameter in the case of open arrays, you're not going to gain any improvement in performance.
Secondly, the direct integer managed by you wouldn't be any faster, but would actually use more memory (an additional integer allocated along with the one Delphi already provides for dynamic and open arrays, and an extra integer entirely in the case of static arrays).
Even if you directly read the value Delphi stores already for dynamic arrays, you wouldn't gain any performance over Length(), and would risk your code breaking if the internal representation of that hidden header for arrays changes in the future.
Is there an internal, hidden integer
Yes.
to not use Length() but a direct integer managed by me?
Doesn't matter.
See Dynamic arrays item in Addressing pointers article by Rudy Velthuis.
P.S. You can also hit F1 button.