hi and sorry about this rather basic question:
does vb adhere to a strict ordering of memory adresses for multi-
dimensional arrays?
i did not find any hints in the obvious places.
crude timing suggests it uses first-index-runs-fastest (column-major)
layout (as in
fortran). am i correct? if so, is this true for dynamical arrays as
well?
thanks for your time,
markus

VB uses safe arrays. In MSDN, check "SAFEARRAY Data Type", and the functions
used, such as SafeArrayRedim(). Also search MSKB for "safearray visual
basic", and VarPtrArray() in particular.

The answer might be found at Microsoft KB-199824 with a little
testing, I dont care how it works, as long as it does.... IMO I cant
change it without making the program (maybe)
harder to understand. A guess is dynamical array leads to linked lists
but that is only a guess.
Ahh, dont want to google for 2 seks? here:http://support.microsoft.com/
kb/199824

//CY
On 10 Juni, 16:34, MarkusU <mossy.bould***@gmail.com> wrote:
Show quoteHide quote

MarkusU wrote:
....
Yes...

I had thought I had seen it explicitly stated somewhere in the Books
Online documentation but a quick search didn't find it.

The most direct hint is in the operation of the ReDim statement

Yes and yes.

You can demonstrate it by looking at the results of writing an array w/
Put in array notation and comparing values w/ a subsequent read.

I have done a great deal of mixed-language programming w/ VB and Fortran
placing heavy computing algorithms in DLLs; one of the key features of
VB as a handy interface language for the purpose is that the native
array order is consistent between the two so that optimized routines
(such as BLAS, say) from GAMS or other sources are directly callable w/o
performance overhead either in rearranging the data order before calling
them or processing them in non-optimum order for cache miss (typically
the biggest cause of excessive slowdown when non-contiguous array
indices are referenced consequentially).  Of course, some algorithms
can't be implemented purely in a sequential order, but paying attention
to native storage order is still wise for any application of any size.

thanx to all repliers!

MarkusU wrote:
It's pretty easy to test.  Given this code:

   Public Sub Main()
      Dim a() As Long, i As Long, j As Long
      ReDim a(0 To 2, 0 To 2) As Long
      For i = 0 To 2
         For j = 0 To 2
            Debug.Print i; j; VarPtr(a(i, j))
         Next j
      Next i
   End Sub

I see these results:

   0  0  2235280
   0  1  2235292
   0  2  2235304
   1  0  2235284
   1  1  2235296
   1  2  2235308
   2  0  2235288
   2  1  2235300
   2  2  2235312

Flop the order of the indices:

            Debug.Print j; i; VarPtr(a(j, i))

And I get this:

   0  0  2369064
   1  0  2369068
   2  0  2369072
   0  1  2369076
   1  1  2369080
   2  1  2369084
   0  2  2369088
   1  2  2369092
   2  2  2369096

I always get the terms column- or row-major mixed up, like large-scale and
small-scale in mapping.  Anyway, I think the above illustration gets to the heart of
your question, right?

Karl E. Peterson wrote:
....VarPtr() example elided for brevity...

Even better than Get/Put for directness, Karl.  I forgot about VarPtr().

Row/Column association addressed in another response...as extension, 3D
arrays are often considered as "planes" of matrices (at various
simulation timesteps, etc.)...

dpb wrote:
Show quoteHide quoteYeah, that's the only way I can remember these things -- *look* directly at them.

Yep.

I suppose it depends how you look at it. Personally I always get confused
when talking about rows and columns with respect to array dimensions. The
best way would be to explain with an example. If you have a dynamic array of
Bytes for example and you do:

    ReDim data(1 To 5000, 1 To 1000)

.. . . then the memory is arranged as a block of 5000 bytes repeated 1000
times. So if for example you have:

    ReDim data(1 To wide, 1 To high)

.. . . then generally the fastest way to access it is as follows because it
results in far more cache hits than would otherwise be the case:

    For y = 1 To high
        For x = 1 To wide
            data(x, y) = 99
        Next x
    Next y

Exactly how much faster it runs than the alternative of having Y in the
inner loop depends of course on the size of the array dimensions and the
kind of work you are doing with it, but generally it is faster. You can
easily check the arrangement by creating a two or more dimension array and
populating it with data and then using CopyMemory (aka rtlMoveMemory) to
copy the data block to a suitably sized single dimension array, or by
performing a suitable timing test. The other clue which leads to the same
conclusion is that if you use the Preserve keyword with the VB Redim
statement then you are allowed to resize only the last array dimension, no
matter how many dimensions it has.

Mike

Michael Williams wrote:
Show quoteHide quoteRows is rows, columns is columns... :)

The correlation or rows/columns is consistent w/ normal arithmetic
matrix notation where the first index in a 2D array corresponds to a
column vector and the second to a row vector.

This definition made the initial FORmulaTRANslation implementation
appear closer to the normal practice in writing linear equations, etc.,
than the opposite ordering would have done.  AFAIK, this correspondence
played at least a major factor in choosing it over the other way 'round.
  I don't know, but I always presumed BASIC chose to mimic FORTRAN
deliberately and VB followed that lead, of course.

Yes, I suppose they are. But does the first dimension refer to a row or to a
column ;-)

Right, so it's a column then. Anyway, despite my stated confusion regarding
the nomenclature of rows and columns I got the actual arrangement in memory
correct in my descriptive example :-)

Mike

Michael Williams wrote:
I've had that discussion before.  Oh, have I! <g>  One of our modellers was all hung
up on transposing matrices.  I asked, why not just flip the i/j's?  Man, that one
truly *boggled* the recipient!

See, I think of it the other way.  The first index being a row, and the second a
column.  I think "normal" in this case only applies to those who grew up on Fortran.
<g>  (Not that there's anything wrong with that!  I had that opportunity, as well,
but always preferred BASIC.)

I never used Fortran, and saw the relationship as it related to the ReDim command.
You'd normally have a fixed number of columns and an advancing number of rows.
Since ReDim allows only the last dimension to be changed, they must be the rows.

That also relates well with the layout of pixels on a screen where the normal notation
is X, Y.  X being the horizontal extent (columns) and Y being the vertical extent (rows).

LFS

Larry Serflaten wrote:
....
I was already a few years along into uni before Dartmouth even started
the BASIC project...so it wasn't ever a choice.  I don't think any
machine at work until VAXen had a BASIC interpreter, nearly 20 years
later at any place I had access to one.  Until that employer switch was
100% CDC shop (after the switch fairly early on from the Philco 2000s,
that is.  Now that _IS_ dating oneself, eh??? :) ).

See other response on how the column major order correlates w/ linear
algebra.

dpb wrote:
Sorry for the mistaken credits, Larry--I was thinking the "never used
FORTRAN" was in your response to Karl rather than in his when I answered...

Anyway, just a sidelight musing on the consonance between FORTRAN and BASIC:

I always wondered why Dartmouth chose to build a totally new syntax for
BASIC instead of simply implementing a FORTRAN interpreter w/ extensions.

We've already seen they chose the memory layout of arrays to be the
same.  The key syntax elements of "=" being assignment, no line
terminator character, functions and subroutines, etc., are so similar as
to be indistinguishable.

Add to that that the only real difference between a loop between the two
is that "DO" is spelled "FOR" and NEXT replaced the label in early
FORTRAN and INPUT instead of READ the overall similarities are far more
prevalent than the differences.

The enhancements seem that could have simply been extensions.

Just a thought.  By that time there were FORTRANs for every major
platform so couldn't be that it was a problem w/ IBM...

dpb wrote:
Perhaps because K&K thought of it as a teaching language, not a
production language. You were meant to move on to Fortran eventually.

Jim Mack wrote:
I don't know, that makes even less sense to me.  If you're teaching to
go to Fortran but want it interactive, why not just build a Fortran
interpreter?

I wasn't there; I don't know but it seemed strange to me to design a new
language that was essentially identical to an existing one except for
changing the spelling of certain key words or in some case abbreviating
them.

'Tis a puzzle... :)

dpb wrote:
Show quoteHide quoteOf course, in Fortran there really aren't keywords--maybe for an
interpreter that was the key (so to speak :) )...

Karl E. Peterson wrote:
Show quoteHide quoteBut that (row vector first) doesn't adhere to the standard conventions
for linear algebra wherein a vector a
      _  _
     -   -

is a column and correspondingly a' = [ a1 a2 a3 ... an] is the row
vector, the transpose of a.

That is a basic convention in linear algebra and so by using
column-major storage order a 1D array is strictly conformant w/ the
mathematics it is representing.

Since such representation was the express purpose for the developers of
FORTRAN, it is not at all surprising it was chosen to correspond in that
way.

And, of course, since for matrix and vector operations dimensions have
to be conformant by the mathematical rules for their manipulation, in
expressions like Ax = b it is more concise to write out longhand if x
and b are columns rather than rows.  Linear algebra "works" if the
association is reversed, of course, as you pointed out by reversing
indices being the same as "real" transpose, but if one's developing code
from theory, it's simpler to keep stuff closer to the original form,
particularly when the coder mostly like in those days was more likely
more familiar w/ the problem than the coding.

All simply a sidebar and musings of an (increasingly more so daily :J) )
old geezer who began before FORTRAN IV, even... :)

Michael Williams wrote:
Show quoteHide quoteYes.  Being old Fortran guy, it's one of those things that is so deeply
ingrained I can't imagine it not being natively inherent to
any/everybody... :)

If speed is important, you could turn off array bound checks. Another thing
is that you can embed assembly code in VB using this free tool.

http://www.freewebs.com/hardcorevb/tvb.html

Re: Multithreading
Multithreading
Vista SP2 Being "offered"
dhRichClient3 Thread Classes Issues
VB6 on Vista Home Premium problem
Excel Execution from VB Fails on 2nd Attempt
Use an Addin to automatically add date/time stamp to each edited line of VB6 code?
Sub .... or Private Sub....
Moving .exe somtimes works
In High Density Mode - Looking for previous control counting post