Three-dimensional array - Printable Version +- QB64 Phoenix Edition (https://staging.qb64phoenix.com) +-- Forum: QB64 Rising (https://staging.qb64phoenix.com/forumdisplay.php?fid=1) +--- Forum: Code and Stuff (https://staging.qb64phoenix.com/forumdisplay.php?fid=3) +---- Forum: Programs (https://staging.qb64phoenix.com/forumdisplay.php?fid=7) +---- Thread: Three-dimensional array (/showthread.php?tid=1363) |
RE: Three-dimensional array - TerryRitchie - 01-04-2023 (01-04-2023, 10:12 PM)Kernelpanic Wrote: Well, I can't think of a practical application right now. Maybe something for mathematicians who can store three-dimensional functions in it. It would be impractical for a "normal" database. I would take two or three records that access each other. For example: https://www.qb64tutorial.com/lesson8 Everything you ever wanted to know about 1D, 2D, 3D, and 4D arrays, with examples. RE: Three-dimensional array - TempodiBasic - 01-05-2023 one tip: _PRESERVE works only with monodimensional array... moreover it is the exact duplicate of _PRESERVE of QB7.1 / QB PDS run this code to catch the issue Code: (Select All) '$dynamic This lets suppose that array is a stack and not a set of cell of memory ordered by pointers. RE: Three-dimensional array - TerryRitchie - 01-05-2023 "_PRESERVE works only with monodimensional array... " Yeah, I believe there was a whole discussion on this at a previous forum. If I remember correctly _PRESERVE only works on one of the dimensions of a multidimensional array which makes for very confusing situations. This is why I have always stuck with using single dimension arrays paired with a TYPE definition to get 2D structure but still able to use _PRESERVE. Array usage in QB64 is more than adequate for most tasks but I would welcome more features. Many other languages, such as Python, are extremely flexible with their array usage (which are called lists and tuples in Python). RE: Three-dimensional array - mnrvovrfc - 01-05-2023 (01-05-2023, 09:07 PM)TempodiBasic Wrote: one tip: This is for sanity reasons. Otherwise a programmer "for hobby" is going to want to change the extent of one of the dimensions as well which is a nightmare to maintain on the developer's side. On BASIC PDS v7.1 the helper keyword did not carry an underscore, it was imported as if it were an original QB64 keyword. Of course there is a way to get around the limitation, but have to get away from the convenience of declaring and using arrays. Must create a _MEM buffer, extend it as necessary and do the dimensional calculations to access bits of data. Not pretty but doable. Terry answered before I could finish LOL. RE: Three-dimensional array - Kernelpanic - 01-06-2023 (01-04-2023, 11:41 PM)TerryRitchie Wrote: https://www.qb64tutorial.com/lesson8 Your example does not show a real three-dimensional array, but three two-dimensional ones. I don't know now how I for example, a three-dimensional array "Sales" should represent 12 months, 30 days, 52 weeks. This is a real three-dimensional field: Code: (Select All) $Console:Only When displaying months, days, weeks, etc., one could do something like this; just an idea, not tested. Code: (Select All) $Console:Only PS: Something just went wrong: No access to the server. RE: Three-dimensional array - SpriggsySpriggs - 01-06-2023 Pretty sure PRESERVE works with multiple dimension arrays. I think my SQL stuff that depends on a two-dimensional array wouldn't work if PRESERVE only handled one dimension arrays. RE: Three-dimensional array - SMcNeill - 01-07-2023 (01-06-2023, 03:48 PM)Spriggsy Wrote: Pretty sure PRESERVE works with multiple dimension arrays. I think my SQL stuff that depends on a two-dimensional array wouldn't work if PRESERVE only handled one dimension arrays. It works, but only on one dimension. REDIM x(10,10) REDIM x(10,20) <-- this is fine. REDIM x(20,10) <-- this will corrupt your index. The reason is real simple -- redim just copies the existing mem block and moves it to a new memblock, and data is stored in memory as a 1d block of memory. For example: 12 34 56 78 The above is a 2 x 4 array of single digits. In memory, it's stored simply as "12345678". Left to right, top to bottom. Now, redim and add a column, you get: 123 456 780 000 Corrupted data! Sure, you added 4 bytes to the whole array, but when you moved that "12345678" over with those 4 new "0000" that you just created, they map to the index in the manner above. So, why can you create a new row with no problems?? 12 34 56 78 00 See where your "12345678" copied over and remained in the same index positions? Those two new "0" characters are at the end of the data, but the structure of the data itself hasn't changed. We still read it left-to-right, top-to-bottom. Multi-dimensional arrays are only redim _preserve-able with the last element. Anything else, you need to move manually into a new array yourself. RE: Three-dimensional array - James D Jarvis - 01-07-2023 Code: (Select All) 'visual representation of a 3-dimensional array RE: Three-dimensional array - mnrvovrfc - 01-07-2023 I was going to share a program that indicated the shock with Lotus123 starting to support "three-dimensional" spreadsheets, I think in v3. After long enough from "A1" to "IV8192" with a single sheet which was the whole document. RE: Three-dimensional array - TempodiBasic - 01-07-2023 As Steve suggests the handmade movement of value from old to new array is the solution. In the time of discussion about this feature I wrote a tip Function to populate the new array Preserving the previously contents of the array without loosing the previous index. It has 3 parameters the old array multidimensional , the new array multidimensional and the number of dimensions. I'll search in my old Toshiba notebook. It could be useful or as input for a better code to make a general purpouse Function Preserving the stored data. Thanks for talking about this feature. |