WeBWorK Problems

Array construction problems, no idea how to fix it

Array construction problems, no idea how to fix it

by Alex Jordan -

Lines 34 and 35 of test2.pg are:

        my $data = shift @$cell;
        $opts = {%$cell};

The first of these lines expects $cell to be an array reference, and the second expects $cell to be a hash reference. I haven't dug into which kind of thing $cell is actually supposed to be, but there is some mistake here.

Does changing the latter line to
$opts = {@$cell};
fix things for you? For me it clears the error but I'm not paying attention to if the problem statement is what it should be and if answer checking is behaving as expected.

Once the perl error is removed though, there are PG warnings about how you are constructing the table. But there's a lot going on and I didn't dig deep to try to understand the table construction. Even the reduced test2.pg file is over 500 lines long. If you have a more minimal problem file I could look at, I might be able to suggest a more direct way to produce the PGML table.

Array construction problems, no idea how to fix it

by Nicole Wilson -
I appreciate you taking a look at this code but that approach will cause more problems for me than I have time to fix.
I've already used the PGMLTable subroutine 11 times in this problem so, I'm too deeply invested to change that.

Since it has worked for 11 other tables, I must be doing something different trying to make this table.

My biggest issue is that I have never written a subroutine before.

I have removed all the code that is not necessary for the Kmap to work from this version of the question.

You can see that the PGMLTable subroutine works three times
246 $PGMLLabelTable = PGMLTable(~~@fLabelTable);
247 $PGMLTable = PGMLTable(~~@table);
248 $PGMLAnsTable = PGMLTable(~~@ansTable);

But fails here
260 $PGMLAnsKMaps = PGMLTable(~~@kmapAns);

I'm trying to determine why @kmapAns has a different format than @fLabelTable, @table, @ansTable.

It has to be something in either "sub KmapMaker" (lines 62 to 93) or the creation of kmapAns (lines 250 to 258).

Array construction problems, no idea how to fix it

by Alex Jordan -

Hi Nicole, in the test3 file, you have not made the change that I think is the main issue that I mentioned in the last post. Change line 35 from

$opts = {%$cell};

to

$opts = {@$cell};

After making that change, the problem will render.

For me at least, using the soon-to-be-released version 2.20 of WeBWorK, at this point I see tons of PG warnings that say "Table text must be in cells", which indicate that your string for the table is not using [. and .] surrounding some sort of content within the table.

Array construction problems, no idea how to fix it

by Nicole Wilson -
I have, I believe tracked down the errors in my KmapMaker subroutine or more accurately started over.

I build the subroutine in perl, where it does work, then brought it back to pg.
I have changed all instances of \@arrayName to ~~@arrayName
Is there an easy way to determine if the array returned by my function is correct?
Is there an easy way to determine if the array I am sending as a parameter contains the correct values?

Array construction problems, no idea how to fix it

by Alex Jordan -
In case this is helpful...

Using test3 as an example, it has this line:
$PGMLLabelTable = PGMLTable(~~@fLabelTable);

and further below:
[$PGMLLabelTable]**

You could change those (respectively) to the following. I laid it out here with extra line breaks and comments to help understand how it works, but it doesn't need all the line breaks and comments.
$PGMLLabelTable = DataTable(
# one big array ref containing the rows of the table
[
# each row of the table is an array ref with three things
map {[
$fLabel[$_],
'=',
$f[$_]->TeX
]} (0 .. $#f)
],
# wrap each cell's content with math delimiters
encase => [$BM,$EM]
);

and:
[$PGMLLabelTable]*

and the output is identical. The idea here is to directly use the DataTable() subroutine instead of using PGML markup. If you gave the same treatment to the other tables, you would not need the PGMLTable subroutine, nor the subroutines it depends on (PGMLopts, convertRow, wrapCell).

Of course this is just an option. It may be easier to debug things without all those helper subroutines.

Array construction problems, no idea how to fix it

by Nicole Wilson -

Can a table made this way contain answer rules?

Array construction problems, no idea how to fix it

by Glenn Rice -

A table made the way Alex suggests can contain answer rules.  Note that you have to use the ans_rule and ANS methods to accomplish this though, instead of the PGML way.  In the table code where you want to add an answer call the ans_rule method of the MathObject answer, and then call ANS with the cmp method of each of those answers after the table code is generated.