Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsFree MagazinesWhite PapersSubmit Content
Discussion GroupsASP.NETWindows FormsLanguages.NET FrameworkVisual Studio.NET
Articles.NET FrameworkASP.NETToolsWindows Forms
.NET DirectoryOpen Source ProjectsUser GroupsWeb Resources
Related Topics
Visual Basic 6SQL ServerMS AccessOther DB ProductsMS Server ProductsMore Topics ...

.NET Forum / Languages / C# / February 2008

Tip: Looking for answers? Try searching our database.

Should i use Array, double[][] or double[,]?

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
K Viltersten - 18 Feb 2008 02:05 GMT
I'm designing a class that will base its
functionality on one (or more) arrays of
doubles. Each array will be of the same
length pairwise but their number may
vary from a single one up to several.

The usual way i'd use in C++ would be to
declare the following.
   double[][] *data;

In C# i have two more options. Given
that the number of arrays might vary as
the program goes on (as in: i'd like to
remove and add arrays on the fly), i
wonder if there's a gain in deploying
Array class directly.

Also, which would be more prefered in
C# - the jagged or the multidimensional
array?

--
Regards
Konrad Viltersten
--------------------------------
sleep    - a substitute for coffee for the poor
ambition - lack of sense to be lazy
Peter Duniho - 18 Feb 2008 02:22 GMT
> I'm designing a class that will base its
> functionality on one (or more) arrays of
> doubles. Each array will be of the same
> length pairwise but their number may vary from a single one up to  
> several.

What does "will be of the same length pairwise" mean?  Pairwise to what?  
Each other?  Something else?  Do you just mean that every double[] will be  
exactly the same length?

> The usual way i'd use in C++ would be to
> declare the following.
>     double[][] *data;

Granted, it's been awhile since I've done a lot of C++ coding.  It seems  
that every year that goes by, I forget at least one other important part  
of the language.

But my recollection is that a declaration like that is quite a bit  
different from what you've described so far (the above describes a  
two-dimensional array of pointers to doubles, not just to doubles), and  
isn't allowed unless you provide the exact dimensions of the array in the  
declaration (either in the variable declaration itself or an initializer).

> In C# i have two more options. Given that the number of arrays might  
> vary as
[quoted text clipped - 5 lines]
> C# - the jagged or the multidimensional
> array?

From your description, possibly neither.

In particular, you wrote: "i'd like to remove and add arrays on the fly".  
If by this you mean that you'd add or remove single-dimensional arrays  
from the array of arrays, then it seems that using a dynamic collection of  
arrays would be better.  For example, List<double[]>.

If you simply mean that you'd add and remove these  
jagged/multi-dimensional arrays dynamically to and from some other  
collection, then it really just comes down to what represents the data the  
best.  The multi-dimensional array works best for situations when you  
really are using all of the elements.  A jagged array works best if the  
second dimension referenced by the first can vary in size according to the  
second.  Which shouldn't be surprising, since those statements are not far  
from describing precisely what the multi-dimensional array and jagged  
array are.  :)

Pete
K Viltersten - 18 Feb 2008 18:17 GMT
>> I'm designing a class that will base its functionality
>> on one (or more) arrays of doubles. Each array will
[quoted text clipped - 3 lines]
> What does "will be of the same length pairwise" mean?
> Pairwise to what? Each other?

Yes. As in - for any pair of the elements you pick, the
length will be equal. I thought it was a common
expression... Too much math, i guess...

>> The usual way i'd use in C++ would be to
>> declare the following.
>>     double[][] *data;
>
> But my recollection is that a declaration like that is quite
> a bit  different from what you've described so far...

It might. The message got through and that's good enough
for me at this point.

> In particular, you wrote: "i'd like to remove and add arrays
> on the fly". ...[it] seems that using a dynamic collection of  
> arrays would be better.  For example, List<double[]>.

Thanks, that's what i was looking for!

--
Regards
Konrad Viltersten
--------------------------------
sleep    - a substitute for coffee for the poor
ambition - lack of sense to be lazy
Nicholas Paldino [.NET/C# MVP] - 18 Feb 2008 02:48 GMT
Konrad,

   Personally, I would use a List<double[]>.  You could treat it as a
multi-dimensional array or a jagged array (since every element in the list
doesn't have to be the same length), and you don't have to worry about
re-copying the array as the number of arrays grows.

Signature

         - Nicholas Paldino [.NET/C# MVP]
         - mvp@spam.guard.caspershouse.com

> I'm designing a class that will base its
> functionality on one (or more) arrays of
[quoted text clipped - 21 lines]
> sleep    - a substitute for coffee for the poor
> ambition - lack of sense to be lazy
Michael C - 18 Feb 2008 04:43 GMT
> Konrad,
>
>    Personally, I would use a List<double[]>.  You could treat it as a
> multi-dimensional array or a jagged array (since every element in the list
> doesn't have to be the same length), and you don't have to worry about
> re-copying the array as the number of arrays grows.

The other option is List<List<double>>

Michael
K Viltersten - 18 Feb 2008 18:17 GMT
>> Personally, I would use a List<double[]>.
>
> The other option is List<List<double>>

Acutally, in my case, the first way is most
appropriate because the lengths of the
inner arrays will never change, only their
number (if that!).

Thanks anyway.

--
Regards
Konrad Viltersten
--------------------------------
sleep    - a substitute for coffee for the poor
ambition - lack of sense to be lazy
Michael C - 18 Feb 2008 23:28 GMT
> Acutally, in my case, the first way is most
> appropriate because the lengths of the inner arrays will never change,
> only their
> number (if that!).

Yep, this method is only useful if the arrays can change in size.

> Thanks anyway.
>
[quoted text clipped - 4 lines]
> sleep    - a substitute for coffee for the poor
> ambition - lack of sense to be lazy
K Viltersten - 18 Feb 2008 18:17 GMT
>> I'm designing a class that will base its
>> functionality on one (or more) arrays of
[quoted text clipped - 9 lines]
> worry about re-copying the array as the
> number of arrays grows.

Yes, that's along the other replies as well
so i see no problem using it. (I'm sure
Peter D. will gladly point out at least one
ust to create a pathological example. The
occasion is on me!)

--
Regards
Konrad Viltersten
--------------------------------
sleep    - a substitute for coffee for the poor
ambition - lack of sense to be lazy
Arne Vajhøj - 18 Feb 2008 02:53 GMT
> The usual way i'd use in C++ would be to
> declare the following.
>    double[][] *data;

I don't think so. It is not valid C++ syntax.

> In C# i have two more options. Given that the number of arrays might
> vary as
> the program goes on (as in: i'd like to
> remove and add arrays on the fly), i wonder if there's a gain in
> deploying Array class directly.

The Array class is the base class for arrays - it is not a different
type of arrays.

> Also, which would be more prefered in
> C# - the jagged or the multidimensional
> array?

square data => multi dim

non square data => jagged

Arne
K Viltersten - 18 Feb 2008 18:23 GMT
>> The usual way i'd use in C++ would be to
>> declare the following.
>>    double[][] *data;
>
> I don't think so. It is not valid C++ syntax.

Allright, already, so i made an a.s by
giving "sort-of" code. Big deal! It's
not like a compiler would misunderstand
ones intentions! Oh, wait. It would...   :)

--
Regards
Konrad Viltersten
--------------------------------
sleep    - a substitute for coffee for the poor
ambition - lack of sense to be lazy
Arne Vajhøj - 19 Feb 2008 03:47 GMT
>>> The usual way i'd use in C++ would be to
>>> declare the following.
[quoted text clipped - 5 lines]
> giving "sort-of" code. Big deal! It's not like a compiler would
> misunderstand ones intentions! Oh, wait. It would...   :)

Compilers are known to be rather picky.

:-)

I still remember the Fortran compiler 25 years ago
that would not compile a program because it had an
empty line at the bottom ....

Arne
Michael C - 19 Feb 2008 03:59 GMT
> I still remember the Fortran compiler 25 years ago
> that would not compile a program because it had an
> empty line at the bottom ....

I still use an 8051 compiler than won't compile unless you have an empty
line.

Michael
Ben Voigt [C++ MVP] - 19 Feb 2008 14:34 GMT
>> I still remember the Fortran compiler 25 years ago
>> that would not compile a program because it had an
>> empty line at the bottom ....
>
> I still use an 8051 compiler than won't compile unless you have an
> empty line.

Assuming you mean C here --

preprocessor directives are required to end in a newline, not end of file

So if the last line is #endif, then yes that's expected.

If the last line was for example }, then I believe that's a nonconformant
compiler

> Michael
Michael C - 19 Feb 2008 22:27 GMT
> Assuming you mean C here --
>
[quoted text clipped - 4 lines]
> If the last line was for example }, then I believe that's a nonconformant
> compiler

This is a free assembly language compiler. I can't remember the name of it
or who wrote it as it's been a few months since I've used it.

Michael

Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.