bugchannelflow: a spectral fluid-flow simulator - Bugs: bug #13349, typedef std::vector<double>...

 
 

bug #13349: typedef std::vector<double> Vector;

Submitted by:  None
Submitted on:  Thu 09 Jun 2005 04:58:21 PM UTC  
 
Category: NoneSeverity: 3 - Normal
Item Group: NoneStatus: None
Privacy: PublicAssigned to: John F. Gibson <gibson17>
Open/Closed: Open

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

Wed 15 Jun 2005 05:21:38 PM UTC, comment #1:

I agree that replacing my homegrown Array<T> with its STL equivalent is a good idea. I wrote the Array<T> class because the STL wasn't reliable on Linux in 1998, when I started channelflow. There are still a few considerations I want to address before switching over, though.

(1) I would prefer to use one access method (preferably [i]) throughout the code and switch range-checking on/off through a debug flags in one place. Simply replacing data_[i] with .at(i) inside all ChebyCoeff methods mean every access is range-checked, whether debugging or running optimized! If a [i] operator that switches between checking and not checking can be implemented through a wrapper class, without a performance penalty, it's a good idea (maybe (wrapper_vector)[i] is an inline that switches between vector::operator[i] and .at(i) according to an #ifdef).

(2) I'd prefer a vector class with mathematical vector methods in addition to array methods. (STL designers should have called their vector class "array".)

(3) My Vector and Array are used elsewhere than ChebyCoeff. Need to check that the substitution would work throughout.

Porting to FFTW3 is great! Thanks! But portnig the FlowField class, which uses strided 2d Fourier transforms, will take more scrutiny. Have you looked at this?

John
John

John F. Gibson <gibson17>
Project AdministratorIn charge of this item.
Thu 09 Jun 2005 04:58:21 PM UTC, original submission:

I do not agree with the design choice of writing from scratch a Vector class.
The reasons are:
1) why bother rewriting resize and alloc code which exists ?
2) why not using at() with STL checking turned on during debug ?
I attach a sample code where I have defined the Vector simply as:

typedef std::vector<double> Vector;

After some happy converting N_ to size() and data_[...] to at(...) the real ChebyCoeff seems works well.
I have also ported to FFTW 3.
I have also written a Matrix Multiplication Trasform, just an exercise to check the theory...

Hope this helps,

Paolo

paolo.greppi at nospam.tiscali.it
(remove nospam.)

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

Attached Files
file #3070:  paolo.zip added by None (27KiB - application/x-zip-compressed)

 

Depends on the following items: None found

Items that depend on this one: None found

 

CC list is empty

 

Do you think this task is very important?
If so, you can click here to add your encouragement to it.
This task has 0 encouragements so far.

Only logged-in users can vote.

 

Please enter the title of George Orwell's famous dystopian book (it's a date):

 

 

Follow 2 latest changes.

Date Changed By Updated Field Previous Value => Replaced By
Wed 15 Jun 2005 05:40:38 PM UTCgibson17Assigned toNone=>gibson17
Thu 09 Jun 2005 04:58:21 PM UTCNoneAttached File-=>Added paolo.zip, #2586

Back to the top


Powered by Savane 3.1-cleanup1