Simple Program Not Working

[pdorvel]

Attachments describe my issue.  Goal of program is to extract all relevant rows from a larger matrix

CabDataCu for further analysis. The program is set to test for "0" in column 1 of CabDataCu and if

not "0" extracts the row.   Programs works properly to ignore matrix rows below 5 and extracts 1-5.

The problem that befuddles me now is that it misses, i.e. does not ignore or jump over matrix Row

4 with a "0" in the first column.  I have tried several variants of the program statements and all have

ended up with same result.  Any ideas?

[MJG]

You're using the same variable, i, for the row index of both the source and result matrices.  When the program gets to the 5th row and sees relevant data, it stores that data in the 5th row of the result matrix.  If you want the 5th row of the source matrix to be stored in the 4th row of the result matrix, you need to use a different row index variable for the source and result matrices.

[Werner_E · Accepted solution]

As Mark already said you need a separate row counter for your result matrix.

Maybe like this:

Here is a different approach:

Here is an approach using routines from the Data Analysis Extension Pack

and her the same but with an error check so the routine does not fail if no row has to be trimmed.

Werner

[AlvaroDíaz]

Hi Werner.

Or you have a lot of files ending at _WExxxxxx, or you came from a year back to the future.

Best regards.

Alvaro.

[Werner_E]

No, its simply  year-month-day, so the 17 at the end is the day, not the year. 😉

But probably I should rather prepend it to the original file name for sorting purposes if some day I'd like to go back to the past.

BTW, the last approach wrongly returns the full original matrix in the case when the first column contains only zeros. It should return something like NaN in that case.

But I guess that will be no problem for Paul as this case is quite unlikely.

Anyway ->

There is still one drawback and thats a limitation of match (and also of Match with "eq"). Any value in the range triggervalue +- TOL will trigger the row trimming. So with the default TOL=10^-3 a value of 0.001 or -0.0001 in the first column will get the row eliminated.

Also possibly no problem for this application as I just see integers here.

Werner

[AlvaroDíaz]

Hi Werner.

I see, I get confuse because when I read that I'm living in the august 16, not 17 like you, even we write dates in the reverse order here, as ddmmyy, which actually ins't an excellent choice if want to sort files.

Best regards.

Alvaro.

[Werner_E]

dd-mm-yy is the usual order over here, too. But for sorting purposes I got used to name files in the reverse order. Of course this does not make that much sense if I append it after the original file name unless all files are named the same apart from the date and the goal is just to sort different revisions of the same file.

Werner

[StuartBruff]

Werner Exinger wrote:

No, its simply  year-month-day, so the 17 at the end is the day, not the year. 😉

But probably I should rather prepend it to the original file name for sorting purposes if some day I'd like to go back to the past.

For a couple of years now, I've constructed my files names in the form

<group> - yy mm dd <subject><version>

eg,

collab - 16 05 20 LambertW 01.xmcd

codegolf - 16 06 09 find the factorial 01.xmcd

dev - 16 05 16 Direct Digital Synthesis 01.xmcd

phys - 13 02 01 fibonacci monster 01.mcd

test - 14 11 18 matlab magic squares ebook 02.xmcd

It's always a compromise when it comes to sorting order, but I decided on this method so I could sort on "date of creation" and have more of a visual clue when I started work on the concept.  In part, I ended up putting the date first because it has a more consistent position and width in the file name.

Stuart

[Werner_E]

Yes, a single file name always has to be just a compromise.

Its additionally necessary to use some kind of document management software and/or use directories and subdirs for additionally organizing your files.

Haven't found my optimal way yet (and probably never will).

After all its said that "Who holds order is only to lazy to search".

Werner

[VladimirN]

AlvaroDíaz wrote:

... you came from a year back to the future...

Why not ?

P.S. Now we understand why Werner knows all the answers in advance .

[Werner_E]

You got me!

And I thought I could keep my time machine a secret

Perhaps this explains my pessimism regarding the "development" of Mathcad/Prime?