I know I can do it, but sometimes you have to add or remove line, (maybe you defined the wrong sizes in beginning, or you are experimenting and you wnt to slightly modify your matrix) and is very upsetting for me spending minutes to create another array, merging them (maybe you want to add a line in middle, so you have to use submatrix, submatrix, stack.. ) while in 2011 you expect to open a contextual menu insert line/ cols as every piece of (decent) software have.
Is like the "select line" function, now present in M'. You theoretically don't need it while you have select column, and with transpose you can select a line.. but it is USEFUL since you don't need to think/do transpose, select, transpose back, that is also an error prone procedure (maybe you worked for hours and you mistacke the order, and do transpose transpose select instead transpose select transpose and you waste hours of work to find the bug.
Ah. Sigh. Those big ugly looking lines of nested submatrix, stack and augment functions are so nostalgic. They make me think of the days when I would spend 30 minutes just figuring out what one horrible looking lne of FORTRAN was supposed to be doing
I wrote the Strip function in the attached. At least, I tihnk I did. It was a long time ago. I think Stuart wrote the others
Mike revived this thread and I jumped on the bus without noticing thats an old one.
Nevertheless, for the archives and in case sombody is still interested, here is an alternate strip() routine attached to Richards file - for whatever it may be worth 😉
So your alternative approach allows a multiple column, single row matrix to be passed to the function?
Main reason for beginning to work on an alternative was a desire to get rid of some if's, break and flag.
Then I thought it might be nice if the vector of indices to strip could be a row vector, too and I added the second line which would transpose the row to a column.
But now I realize that this is not necessary at all and this line could be deleted. Using match in combination with onerror would also allow providing the indices in a 2-dimensional matrix (while I couldn't think of a reason for doing so).
The task is again an example that we would need something like a data type "set" with some kind of boolean "memberof()" function, so we would not have to resort to programming loops or misuse of match/onerror.
Thanks, that old thread transforms slowly into a contest
Some comments:
Using IsScalar sure is better as it avoids a negation.
The endpoint of the for-loop has to be ORIGIN+cols(M)-1
Using a local variable O instead of ORIGIN seems to be a matter of taste. I am used to it from longer programs as I find the O (reminds me of a zero) makes the lines shorter and provides better readability compared to the lenghty ORIGIN. Very often I don't bother making my routines ORIGIN-aware as I never change ORIGIN in my sheets.
I don't agree with the omission of the initialisation of the local variable OUT. I feel thats it a bug of Mathcad that its doesn't throw an error if the variable is used (cols(OUT)) without any initialisation. you may also run into troubles if there exists a worksheet variable OUT which is already a vector. Mathcad allows the usage of OUT w/o initialisation because OUT is assigned in a for-loop. I commented on this behaviour about a week ago - http://communities.ptc.com/message/233148#233148
I don't agree with the omission of the initialisation of the local variable OUT. I feel thats it a bug of Mathcad that its doesn't throw an error if the variable is used (cols(OUT)) without any initialisation.
Bug or otherwise, an uninitialized variable leads to different behavior in different versions of Mathcad. Here's what we get in MC13:
you may also run into troubles if there exists a worksheet variable OUT which is already a vector.
Agreed. Robustness is key for a general purpose function.
BTW Mike, you have an error in your worksheet: your expression says Strip2(M,3), not Strip3(M,2).
Bug or otherwise, an uninitialized variable leads to different behavior in different versions of Mathcad. Here's what we get in MC13:
According to that screenshot, OUT seems to be automatically initialized as 2x1 vector (0,0) in MC13 and not as scalar 0 as in MC14. So we learn to always initialize variables which we intend to use at a later stage in the routine.
Thanks, that old thread transforms slowly into a contest
Not a contest I was just bored.
Using a local variable O instead of ORIGIN seems to be a matter of taste. I am used to it from longer programs as I find the O (reminds me of a zero) makes the lines shorter and provides better readability compared to the lenghty ORIGIN. Very often I don't bother making my routines ORIGIN-aware as I never change ORIGIN in my sheets.
It does look neater I give you that. I just don't like it defined at the start of every program.
I don't agree with the omission of the initialisation of the local variable OUT. I feel thats it a bug of Mathcad that its doesn't throw an error if the variable is used (cols(OUT)) without any initialisation. you may also run into troubles if there exists a worksheet variable OUT which is already a vector. Mathcad allows the usage of OUT w/o initialisation because OUT is assigned in a for-loop. I commented on this behaviour about a week ago - http://communities.ptc.com/message/233148#233148
Valid point. I have seem this cause problems in the past - sorry just being lazy.
Sorry, I'm not buying those. I also looked at something similar to strip5, but I disagree that it's more compact. It has one less line, but it's much wider. It's also much harder to understand, The same goes for the others. IMO Strip4 is still the winner.
We are archiving your idea as part of a general review. This action is based on the age of your idea and the total number of votes received, as per this announcement.
You can always post a new idea with all the details required in the form.
Thank you for your participation.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
