openwebwork-devel — WeBWorK development discussion

[WWdevel] Subtractive cancellation

[Davide P. C. <dp...@un...>]

Folks:

Well, this mailing list has been pretty quiet, so I thought I'd bring  
up an issue I've been thinking about.  On a number of occasions, I've  
seen WeBWorK reject a correct answer because of numeric instability  
at one of the test points.  This is usually the result of one of the  
main sources of error in numeric computations:  subtractive  
cancellation.

When two nearly identical numbers are subtracted, most of the digits  
cancel leaving something near zero.  That is correct and perfectly  
normal.  The problem, however, is that when you are only storing a  
fixed number of digits, you can go from having 16 digits of precision  
and cancel out 13 of them, leaving only 3 digits left, so you have a  
massive loss of quality of the results.  Moreover, these lowest 3  
digits are where all the accumulated round-off errors are, and so  
these 3 digits are essentially random, and so those random digits  
have been moved up to the most significant digits, and your results  
are essentially worthless.

For example, if you compute  a - b  where a = 3.14159265395 and b =  
3.14159265213, then you get 1-b = .00000000182, and even though your  
original numbers have 12 significant digits, the result has only  
three, which is a significant loss of precision.  And since these 3  
digits are the least significant ones in the original numbers, they  
are subject to the most error due to accumulated round-off from  
previous computations.  This is how round-off error becomes  
significant in a computation.

Note also in this example that the result has only three digits, so  
if this gets compared to a student's answer that is computed in a  
slightly different way (with a slightly different 3-digit result),  
the relative error between the two answers will be quite high (it  
will be in the second or third digit, which is far higher than the  
usual tolerances, which are in the 4th digit or so).   I know that  
the zeroLevel and zeroLevelTol settings are intended to address this  
issue, but there is a problem with that approach:  the subtractive  
cancellation can occur at any order of magnitude.  For example, with  
numbers on the order of 1000, when 16 digits are being stored (the  
usual number for 64-bit floating point reals), if say 12 digits  
cancel (leaving only 4), the result will be on the order of 1E-8,  
which is significantly ABOVE the zeroLevelTol of 1E-12, and so will  
not be detected via that method, and we will go on with only 4 digits  
of precision to obtain values that are substantially less precise  
than usual.

The only way out of this currently is to adjust the limits used in  
the problem to avoid the test points where subtractive cancellation  
occurs.  Usually, this means avoiding the points where the function  
is zero (these points almost always involve subtractive cancellation  
somehow).  But it is not always easy to determine where these will  
be, especially when it depends on the random parameters, and since so  
few problem designers think carefully about their domains in any  
case, this is is not a very reliable method even when the zeros are  
clear.

I have been looking into a method that could help with this sort of  
problem.  Since the Parser handles the various operations (like  
subtraction) through overloaded operators, it would be possible to  
check each subtraction to see whether there has been a significant  
loss of precision (i.e., subtractive cancellation), and track the  
maximum loss for the evaluation of the function.  When selecting test  
points, if the computation caused a significant loss, the test point  
could be discarded and another one selected.

A more aggressive alternative would be to have subtraction convert  
the answer to zero when such a massive loss of precision occurs.   
This has the advantage of working no mater what the magnitude of the  
results, but might have unforeseen consequences, and would have to be  
watched carefully.

The drawback to this approach is that there would be more overhead  
involved with EVERY computation.  Currently, the computations  
performed when two functions are compared are NOT performed through  
the overloaded operators (for efficiency), and so changing things to  
allow tracking of cancellation would mean adding a lot of new  
overhead.  It may not be worth the cost.

A less aggressive approach would be to add a numeric stability test  
to the diagnostic output that is available in the Parser's function  
checker, so that the problem author could get a report of ranges  
where subtractive cancellation is a problem, and so can adjust the  
limits to avoid them.  This was one of the things I had in mind when  
I wrote the diagnostic display, but hadn't gotten to it.  (BTW, we  
still need a better way to get the diagnostic output into the WW page  
-- currently it is via warn messages, which fills up the server error  
log with lots of long messages that are not really errors.  But  
that's a different discussion.)  That is, the overhead would only  
occur at the request of the professor during problem development, not  
when the student is running the problem, and so would not be such a  
problem.  But is suffers from the flaw that the problem developer  
needs to do something extra in order to get the diagnostics.  (Of  
course, if we made that easier, say with a button on the professor's  
screen, and it became a normal part of the development process, that  
might not be so bad.)

Anyway, I have made some tests, and it IS feasible to track the  
subtractive cancellation, and so it could be used to avoid the major  
cause of numeric instability.  Any comments?

Davide

Re: [WWdevel] Lessons learned from 2.2 freeze/release

[Davide P. C. <dp...@un...>]

> The procedure I gave for committing a change to two different  
> branches is somewhat cumbersome. I found myself instead maintaining  
> two up-to-date working copies, one on rel-2-2-dev and one on MAIN,  
> and doing like this: ...

I agree with you, I used the procedure you outline for my first few  
updates, but found that I was never certain that things had been left  
the way that they were supposed to be.  So I did essentially the same  
that you did:  ran two separate versions, one a copy of MAIN and one  
a copy of the developer version.

> The rel-2-2-dev branch and the MAIN branch remained largely  
> identical, indicating that no one was doing any "new" development  
> during the freeze period. I still think it was good to start the - 
> dev branch when we did, just in case new development is taking  
> place in parallel.

Yes, I think you are right to do this.  I had considered some changes  
to the Parser that I would not want to have put into the 2.2 release  
and would have used just the MAIN branch, but just didn't have time  
to get to them.

Davide

[WWdevel] Lessons learned from 2.2 freeze/release

[Sam H. <sh...@ma...>]

Hi All,

Now that 2.2.0 is out, it's a good time to think about what worked  
and what didn't in preparing for this release. Here are my thoughts:

It doesn't really matter whether we fix a bug in rel-2-2-dev and then  
forward-port it to MAIN, or vice versa. Both work equally well, as  
long as your careful.

The procedure I gave for committing a change to two different  
branches is somewhat cumbersome. I found myself instead maintaining  
two up-to-date working copies, one on rel-2-2-dev and one on MAIN,  
and doing like this:

  # make some change to my 2.2 working copy.
  cd webwork2_rel-2-2-dev
  nano Foo.pm
  nano Bar.pm
  # before committing, send that change over to my MAIN working copy.
  cvs diff Foo.pm Bar.pm | (cd ../webwork2_MAIN&&patch)
  # commit to rel-2-2-dev
  cvs commit
  # (copy the log message for use in the other commit.)
  # commit to MAIN
  cd ../webwork2_MAIN
  cvs commit

I also ended up watching the commit stream, so other developers  
didn't need to be totally disciplined about making sure bugfixes got  
into both branches. I'll still miss bugfixes that are embedded in  
larger non-backportable changes committed to MAIN, so please split up  
bugfixes and enhancements or at least mention in the commit message  
when both are in a single commit.

The rel-2-2-dev branch and the MAIN branch remained largely  
identical, indicating that no one was doing any "new" development  
during the freeze period. I still think it was good to start the -dev  
branch when we did, just in case new development is taking place in  
parallel.

Does anyone have any thoughts about the freeze/release process this  
time around? (I'll be addressing 2.3 development and 2.2 maintenance  
in a separate email.)
-sam

Re: [WWdevel] time for 2.2.0?

[Sam H. <sh...@ma...>]

On Feb 9, 2006, at 20:06, Michael Gage wrote:

> I take it back.  As far as I can tell by searching the CVS
> the edit link has always been at the bottom.  My memory is playing
> tricks on me.
>
> let's leave it as it is and release 2.2
>
> We'll fix the edit link later.

Too late, I already fixed it. It's better up there anyway.
-sam

> On Feb 9, 2006, at 7:50 PM, Michael Gage wrote:
>
>> Could we fix the misplaced [edit] link first?  Otherwise people  
>> are going to search for it in the new release since it's different  
>> from what they are used to.
>> Bug 978
>>
>> Otherwise it has been working fine on hosted.
>>
>> Take care,
>>
>> Mike
>>
>> On Feb 9, 2006, at 5:44 PM, Davide P. Cervone wrote:
>>
>>>> The 2.2 branch seems stable. I think it's time to release 2.2.0.  
>>>> Is there anything you'd like to see fixed before we do release?
>>>
>>> I think it's ready to go.
>>>
>>> Davide
>>>
>>>
>>>
>>> -------------------------------------------------------
>>> This SF.net email is sponsored by: Splunk Inc. Do you grep  
>>> through log files
>>> for problems?  Stop!  Download the new AJAX search engine that makes
>>> searching your log files as easy as surfing the  web.  DOWNLOAD  
>>> SPLUNK!
>>> http://sel.as-us.falkag.net/sel? 
>>> cmd=lnk&kid=103432&bid=230486&dat=121642
>>> _______________________________________________
>>> OpenWeBWorK-Devel mailing list
>>> Ope...@li...
>>> https://lists.sf.net/lists/listinfo/openwebwork-devel
>>
>> "Only dead fish swim with the stream."
>>
>
> "Only dead fish swim with the stream."
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through  
> log files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD  
> SPLUNK!
> http://sel.as-us.falkag.net/sel? 
> cmd=lnk&kid=103432&bid=230486&dat=121642
> _______________________________________________
> OpenWeBWorK-Devel mailing list
> Ope...@li...
> https://lists.sf.net/lists/listinfo/openwebwork-devel

Re: [WWdevel] time for 2.2.0?

[Michael G. <ga...@ma...>]

I take it back.  As far as I can tell by searching the CVS
the edit link has always been at the bottom.  My memory is playing
tricks on me.

let's leave it as it is and release 2.2

We'll fix the edit link later.

Take care,

Mike

On Feb 9, 2006, at 7:50 PM, Michael Gage wrote:

> Could we fix the misplaced [edit] link first?  Otherwise people are  
> going to search for it in the new release since it's different from  
> what they are used to.
> Bug 978
>
> Otherwise it has been working fine on hosted.
>
> Take care,
>
> Mike
>
> On Feb 9, 2006, at 5:44 PM, Davide P. Cervone wrote:
>
>>> The 2.2 branch seems stable. I think it's time to release 2.2.0.  
>>> Is there anything you'd like to see fixed before we do release?
>>
>> I think it's ready to go.
>>
>> Davide
>>
>>
>>
>> -------------------------------------------------------
>> This SF.net email is sponsored by: Splunk Inc. Do you grep through  
>> log files
>> for problems?  Stop!  Download the new AJAX search engine that makes
>> searching your log files as easy as surfing the  web.  DOWNLOAD  
>> SPLUNK!
>> http://sel.as-us.falkag.net/sel? 
>> cmd=lnk&kid=103432&bid=230486&dat=121642
>> _______________________________________________
>> OpenWeBWorK-Devel mailing list
>> Ope...@li...
>> https://lists.sf.net/lists/listinfo/openwebwork-devel
>
> "Only dead fish swim with the stream."
>

"Only dead fish swim with the stream."

Re: [WWdevel] time for 2.2.0?

[Michael G. <ga...@ma...>]

Could we fix the misplaced [edit] link first?  Otherwise people are  
going to search for it in the new release since it's different from  
what they are used to.
Bug 978

Otherwise it has been working fine on hosted.

Take care,

Mike

On Feb 9, 2006, at 5:44 PM, Davide P. Cervone wrote:

>> The 2.2 branch seems stable. I think it's time to release 2.2.0.  
>> Is there anything you'd like to see fixed before we do release?
>
> I think it's ready to go.
>
> Davide
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through  
> log files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD  
> SPLUNK!
> http://sel.as-us.falkag.net/sel? 
> cmd=lnk&kid=103432&bid=230486&dat=121642
> _______________________________________________
> OpenWeBWorK-Devel mailing list
> Ope...@li...
> https://lists.sf.net/lists/listinfo/openwebwork-devel

"Only dead fish swim with the stream."

Re: [WWdevel] time for 2.2.0?

[Davide P. C. <dp...@un...>]

> The 2.2 branch seems stable. I think it's time to release 2.2.0. Is  
> there anything you'd like to see fixed before we do release?

I think it's ready to go.

Davide

[WWdevel] time for 2.2.0?

[Sam H. <sh...@ma...>]

Hi,

The 2.2 branch seems stable. I think it's time to release 2.2.0. Is  
there anything you'd like to see fixed before we do release?
-sam

Re: [WWdevel] links to problem libraries

[John J. <jj...@as...>]

Hi,

Having a mechanism to specify a path which is not under templates seems 
like a good idea, and better in general than the current mechanism used 
by the database_problems.

One note on the current database_problems approach - it only makes the 
link when you try to access the "Problem Library" part of the "Library 
Browser".  It should also handle the situation where a problem is looked 
for and not found.  This can happen when you import a set with problems 
from the database_problems, but haven't accessed them through the 
Library Browser in that course yet.  I don't know if I made that clear.

John


Sam Hathaway wrote:

> On Jan 16, 2006, at 21:32, Michael Gage wrote:
>
>> Hi all,
>>
>> I've had some difficulties describing the process of adding new  
>> problem libraries to other webwork system admins.
>> The problem is retroactively adding links to the problem libraries  
>> from the templates files of the existing courses.
>>
>> For new courses, I simply add the links to the modelCourse and copy  
>> that whenever I make a new course.
>> For the old courses I have written a script, but it's not that  
>> robust or portable.
>>
>> The nationalLibrary  (or database_problib or whatever name you wish  
>> to use) automatically adds a link if its missing.
>>
>> I was thinking of adding some information to global.conf, so that  
>> something similar could be done with the other problem libraries.   
>> I'd replace
>>
>> $courseFiles{problibs}    = {
>>     rochesterLibrary => "Rochester",
>>     rochester_grade8Library =>"Rochester grade 8",
>>     asuLibrary       => "Arizona State",
>>     dcdsLibrary      => "Detroit CDS",
>>     dartmouthLibrary => "Dartmouth",
>>     indianaLibrary   => "Indiana",
>>     nauLibrary       => "Northern Arizona",
>>     osuLibrary       => "Ohio State",   
>>    capaLibrary      => "CAPA",
>>    unionLibrary     =>  "Union",
>>    tcnjLibrary      => "TCNJ"
>> };
>>
>>
>> by
>>
>> $courseFiles{problibs}    = {
>>     rochesterLibrary => { name => "Rochester", path=> '/ww/webwork/ 
>> rochester_problib'},
>>     rochester_grade8Library =>{name=> "Rochester grade 8", path => '/ 
>> ww/webwork/rochester8thgrade_problib'},
>> ... etc.
>> };
>>
>> With this structure we could later add more information about each  
>> library if that was needed.
>>
>>
>>
>> Does anyone see downsides to this?  Should we just encourage the  use 
>> of scripts, and perhaps write some robust ones?
>> Does anyone have better/different ideas about this?
>
>
> Hi Mike,
>
> This looks good to me. I'm for courses being "self-healing" in some  
> ways. For example, creating temp directories as needed. I don't see a  
> problem with auto-creating symlinks, as long as we do it securely and  
> are careful not to overwrite existing files/symlinks.
>
> At some point we might want to stop using symlinks to get to problem  
> libraries, and instead access them directly, and the $courseFiles 
> {problibs} format you propose allows for that.
>
> The only downside I can think of is that some courses might want to  
> "opt out" of access to problem libraries, perhaps to speed up  
> traversal of the templates directory. But this could be achieved by  
> adding "delete $courseFiles{problibs}{some_problib}" to that course's  
> course.conf.
>
> When we implement this, we should use the same symlink-generating  
> code for both the regular problem libraries and the database problem  
> library, if possible.
> -sam
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log 
> files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
> _______________________________________________
> OpenWeBWorK-Devel mailing list
> Ope...@li...
> https://lists.sf.net/lists/listinfo/openwebwork-devel

Re: [WWdevel] links to problem libraries

[Sam H. <sh...@ma...>]

On Jan 16, 2006, at 21:32, Michael Gage wrote:

> Hi all,
>
> I've had some difficulties describing the process of adding new  
> problem libraries to other webwork system admins.
> The problem is retroactively adding links to the problem libraries  
> from the templates files of the existing courses.
>
> For new courses, I simply add the links to the modelCourse and copy  
> that whenever I make a new course.
> For the old courses I have written a script, but it's not that  
> robust or portable.
>
> The nationalLibrary  (or database_problib or whatever name you wish  
> to use) automatically adds a link if its missing.
>
> I was thinking of adding some information to global.conf, so that  
> something similar could be done with the other problem libraries.   
> I'd replace
>
> $courseFiles{problibs}    = {
> 	rochesterLibrary => "Rochester",
> 	rochester_grade8Library =>"Rochester grade 8",
> 	asuLibrary       => "Arizona State",
> 	dcdsLibrary      => "Detroit CDS",
> 	dartmouthLibrary => "Dartmouth",
> 	indianaLibrary   => "Indiana",
> 	nauLibrary       => "Northern Arizona",
> 	osuLibrary       => "Ohio State",	
>    capaLibrary      => "CAPA",
>    unionLibrary     =>  "Union",
>    tcnjLibrary      => "TCNJ"
> };
>
>
> by
>
> $courseFiles{problibs}    = {
> 	rochesterLibrary => { name => "Rochester", path=> '/ww/webwork/ 
> rochester_problib'},
> 	rochester_grade8Library =>{name=> "Rochester grade 8", path => '/ 
> ww/webwork/rochester8thgrade_problib'},
> ... etc.
> };
>
> With this structure we could later add more information about each  
> library if that was needed.
>
>
>
> Does anyone see downsides to this?  Should we just encourage the  
> use of scripts, and perhaps write some robust ones?
> Does anyone have better/different ideas about this?

Hi Mike,

This looks good to me. I'm for courses being "self-healing" in some  
ways. For example, creating temp directories as needed. I don't see a  
problem with auto-creating symlinks, as long as we do it securely and  
are careful not to overwrite existing files/symlinks.

At some point we might want to stop using symlinks to get to problem  
libraries, and instead access them directly, and the $courseFiles 
{problibs} format you propose allows for that.

The only downside I can think of is that some courses might want to  
"opt out" of access to problem libraries, perhaps to speed up  
traversal of the templates directory. But this could be achieved by  
adding "delete $courseFiles{problibs}{some_problib}" to that course's  
course.conf.

When we implement this, we should use the same symlink-generating  
code for both the regular problem libraries and the database problem  
library, if possible.
-sam

Re: [WWdevel] Re: Feedback bug still there after update

[Sam H. <sh...@ma...>]

On Jan 29, 2006, at 15:59, John Jones wrote:

> This should now be fixed in cvs.

John,

Thanks for the fix. I merged it into rel-2-2-dev.
-sam

> Sam Hathaway wrote:
>
>> On Jan 25, 2006, at 16:07, Arnold Pizer wrote:
>>
>>> I updated webwork.rochester.edu to version rel-2-2-dev and  
>>> feedback  still doesn't work.  Actually this is a big pain. If  
>>> you use Course  Configuration, select E-mail, set
>>>  "E-mail feedback from students automatically sent to this   
>>> permission level and higher" to nobody, and then fill in   
>>> "Additional addresses for receiving feedback e-mail" you get an   
>>> error message that no recipients were selected when you try to  
>>> send  email. If you set the permission level to "prof" and then  
>>> add  additional addresses (e.g. the webwork TA!!), email is never  
>>> sent  to the additional addresses.  It looks like line that is  
>>> generated  in simple.conf (e.g.
>>> $mail{allowedFeedback} =   
>>> ['ap...@ma...','mp...@ma...'];
>>> )
>>> is never read.  I greped for "allowedFeedback" and the only place  
>>> I  saw that it appeared was in Constants.pm
>>
>>
>> Apparently there is a bug in the web-based configuration system.  
>> $mail {allowedFeedback} should actually be $mail 
>> {feedbackRecipients}.  Here's the pertinent code in Feedback.pm:
>>
>>     foreach my $rcptName ($db->listUsers()) {
>>         if ($authz->hasPermissions($rcptName, "receive_feedback")) {
>>             my $rcpt = $db->getUser($rcptName); # checked
>>             if ($rcpt and $rcpt->email_address) {
>>                 push @recipients, $rcpt->rfc822_mailbox;
>>             }
>>         }
>>     }
>>
>>     if (defined $ce->{mail}->{feedbackRecipients}) {
>>         push @recipients, @{$ce->{mail}->{feedbackRecipients}};
>>     }
>>
>> Constants.pm should be changed to refer to the correct variable.  
>> I've  filed a bug report on this issue: <http:// 
>> bugs.webwork.rochester.edu/ show_bug.cgi?id=961>.
>>
>> Thanks for going to the trouble to track this down.
>> -sam

Re: [WWdevel] Re: Feedback bug still there after update

[John J. <jj...@as...>]

This should now be fixed in cvs.

John


Sam Hathaway wrote:

> On Jan 25, 2006, at 16:07, Arnold Pizer wrote:
>
>> I updated webwork.rochester.edu to version rel-2-2-dev and feedback  
>> still doesn't work.  Actually this is a big pain. If you use Course  
>> Configuration, select E-mail, set
>>  "E-mail feedback from students automatically sent to this  
>> permission level and higher" to nobody, and then fill in  "Additional 
>> addresses for receiving feedback e-mail" you get an  error message 
>> that no recipients were selected when you try to send  email. If you 
>> set the permission level to "prof" and then add  additional addresses 
>> (e.g. the webwork TA!!), email is never sent  to the additional 
>> addresses.  It looks like line that is generated  in simple.conf (e.g.
>> $mail{allowedFeedback} =  
>> ['ap...@ma...','mp...@ma...'];
>> )
>> is never read.  I greped for "allowedFeedback" and the only place I  
>> saw that it appeared was in Constants.pm
>
>
> Apparently there is a bug in the web-based configuration system. $mail 
> {allowedFeedback} should actually be $mail{feedbackRecipients}.  
> Here's the pertinent code in Feedback.pm:
>
>     foreach my $rcptName ($db->listUsers()) {
>         if ($authz->hasPermissions($rcptName, "receive_feedback")) {
>             my $rcpt = $db->getUser($rcptName); # checked
>             if ($rcpt and $rcpt->email_address) {
>                 push @recipients, $rcpt->rfc822_mailbox;
>             }
>         }
>     }
>
>     if (defined $ce->{mail}->{feedbackRecipients}) {
>         push @recipients, @{$ce->{mail}->{feedbackRecipients}};
>     }
>
> Constants.pm should be changed to refer to the correct variable. I've  
> filed a bug report on this issue: <http://bugs.webwork.rochester.edu/ 
> show_bug.cgi?id=961>.
>
> Thanks for going to the trouble to track this down.
> -sam
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log 
> files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
> _______________________________________________
> OpenWeBWorK-Devel mailing list
> Ope...@li...
> https://lists.sf.net/lists/listinfo/openwebwork-devel

[WWdevel] CVS: "webwork-modperl" alias going away

[Sam H. <sh...@ma...>]

Hi,

I'd like to remove the symlink "webwork-modperl" from the CVS  
repository soon. If your working copy is checked out using that  
module name, you can move over to using the current module name  
"webwork2" my modifying each CVS/Repository file in your working copy:

find . -regex '.*/CVS/Repository$' -print0 |
   xargs -0 perl -pi -e 's/webwork-modperl/webwork2/'

Or simply check out a new working copy.
-sam

[WWdevel] Re: Feedback bug still there after update

[Sam H. <sh...@ma...>]

On Jan 25, 2006, at 16:07, Arnold Pizer wrote:

> I updated webwork.rochester.edu to version rel-2-2-dev and feedback  
> still doesn't work.  Actually this is a big pain. If you use Course  
> Configuration, select E-mail, set
>  "E-mail feedback from students automatically sent to this  
> permission level and higher" to nobody, and then fill in  
> "Additional addresses for receiving feedback e-mail" you get an  
> error message that no recipients were selected when you try to send  
> email. If you set the permission level to "prof" and then add  
> additional addresses (e.g. the webwork TA!!), email is never sent  
> to the additional addresses.  It looks like line that is generated  
> in simple.conf (e.g.
> $mail{allowedFeedback} =  
> ['ap...@ma...','mp...@ma...'];
> )
> is never read.  I greped for "allowedFeedback" and the only place I  
> saw that it appeared was in Constants.pm

Apparently there is a bug in the web-based configuration system. $mail 
{allowedFeedback} should actually be $mail{feedbackRecipients}.  
Here's the pertinent code in Feedback.pm:

     foreach my $rcptName ($db->listUsers()) {
         if ($authz->hasPermissions($rcptName, "receive_feedback")) {
             my $rcpt = $db->getUser($rcptName); # checked
             if ($rcpt and $rcpt->email_address) {
                 push @recipients, $rcpt->rfc822_mailbox;
             }
         }
     }

     if (defined $ce->{mail}->{feedbackRecipients}) {
         push @recipients, @{$ce->{mail}->{feedbackRecipients}};
     }

Constants.pm should be changed to refer to the correct variable. I've  
filed a bug report on this issue: <http://bugs.webwork.rochester.edu/ 
show_bug.cgi?id=961>.

Thanks for going to the trouble to track this down.
-sam

Re: [WWdevel] Re: pretty awesome

[Sam H. <sh...@ma...>]

On Jan 20, 2006, at 0:14, William H. Wheeler wrote:

> The site you found in Korea is an offspring of Indiana.
> It was initiated by a faculty member of our department
> who is from Korea and has an ongoing, strong relationship
> with SNU (Seoul National University).  He visits there
> regularly.  He told them about WeBWorK about four years
> ago and persuaded them to undertake a project to
> develop a Korean localization.   They invested a lot
> of time and money.  Their goal is to provide
> WeBWorK service throughout South Korea.
>
> The development team visited the U.S. in January of 2004.
> I thought they met Mike and Arnie then.

Thanks for the information, Bill. I'd like to get in touch with them  
some time after 2.2 is released. (Maybe through Mike and Arnie.) Do  
you know if their modifications are available?
-sam

[WWdevel] Re: pretty awesome

[William H. W. <wh...@in...>]

Dear Sam,

The site you found in Korea is an offspring of Indiana.
It was initiated by a faculty member of our department
who is from Korea and has an ongoing, strong relationship
with SNU (Seoul National University).  He visits there
regularly.  He told them about WeBWorK about four years
ago and persuaded them to undertake a project to
develop a Korean localization.   They invested a lot
of time and money.  Their goal is to provide
WeBWorK service throughout South Korea.

The development team visited the U.S. in January of 2004.
I thought they met Mike and Arnie then.

Sincerely,

Bill Wheeler

--------------------------------------------------------------------------------

On Thu, 19 Jan 2006, ope...@li... wrote:

>
> Message: 2
> From: Sam Hathaway <sh...@ma...>
> Date: Thu, 19 Jan 2006 23:16:48 -0500
> To: ope...@li...
> Subject: [WWdevel] pretty awesome
>
> I found this site:
>
> http://webwork2.math.snu.ac.kr/
>
> Almost the entire interface has been localized. The course names are
> given in Korean, which as far as I know isn't supported by WW 1.9,
> although it might be accidentally. The spaces in set names are nice
> too. We should talk to them about a localized version of WeBWorK 2.
> What would they like to see in the architecture to make translation
> easier?
> -sam
>

[WWdevel] pretty awesome

[Sam H. <sh...@ma...>]

I found this site:

http://webwork2.math.snu.ac.kr/

Almost the entire interface has been localized. The course names are  
given in Korean, which as far as I know isn't supported by WW 1.9,  
although it might be accidentally. The spaces in set names are nice  
too. We should talk to them about a localized version of WeBWorK 2.  
What would they like to see in the architecture to make translation  
easier?
-sam

[WWdevel] Re: [WWcvs] webwork2: backport to rel-2-1-patches (roll back part of change in

[Michael G. <ga...@ma...>]

Hi Sam,

I think the course_info.txt panel has to go on the right hand side,  
not the top.  Look at

http://webwork.math.rochester.edu/webwork2/fall05-mth162/

for an example of how I used it.  If the info panel is on the top,  
you have to scroll down to get to the courses.

(see http://devel.webwork.rochester.edu:8002/webwork2/ 
gage_course_single_sql )

Take care,

Mike


On Jan 19, 2006, at 7:22 PM, Sam Hathaway via activitymail wrote:

> Log Message:
> -----------
> backport to rel-2-1-patches (roll back part of change in version  
> 1.58.)
>
> Tags:
> ----
> rel-2-1-patches
>
> Modified Files:
> --------------
>     webwork2/lib/WeBWorK/ContentGenerator:
>         ProblemSets.pm
>
> Revision Data
> -------------
> Index: ProblemSets.pm
> ===================================================================
> RCS file: /webwork/cvs/system/webwork2/lib/WeBWorK/ContentGenerator/ 
> ProblemSets.pm,v
> retrieving revision 1.56.2.1
> retrieving revision 1.56.2.2
> diff -Llib/WeBWorK/ContentGenerator/ProblemSets.pm -Llib/WeBWorK/ 
> ContentGenerator/ProblemSets.pm -u -r1.56.2.1 -r1.56.2.2
> --- lib/WeBWorK/ContentGenerator/ProblemSets.pm
> +++ lib/WeBWorK/ContentGenerator/ProblemSets.pm
> @@ -61,11 +61,7 @@
>  		} else {
>  			print CGI::p(CGI::b("Course Info"));
>  		}
> -		unless (-e $course_info_path) {       # FIXME
> -			`echo "" >$course_info_path`;     # we seem to need to have  
> this file
> -			                                  # around to prevent
> -			                                  # spurious errors when  
> editing it.
> -		}
> +		
>  		if (-f $course_info_path) { #check that it's a plain  file
>  			my $text = eval { readFile($course_info_path) };
>  			if ($@) {
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through  
> log files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD  
> SPLUNK!
> http://sel.as-us.falkag.net/sel? 
> cmd=lnk&kid=103432&bid=230486&dat=121642
> _______________________________________________
> OpenWeBWorK-CVS mailing list
> Ope...@li...
> https://lists.sf.net/lists/listinfo/openwebwork-cvs

"Only dead fish swim with the stream."

[WWdevel] links to problem libraries

[Michael G. <ga...@ma...>]

Hi all,

I've had some difficulties describing the process of adding new  
problem libraries to other webwork system admins.
The problem is retroactively adding links to the problem libraries  
from the templates files of the existing courses.

For new courses, I simply add the links to the modelCourse and copy  
that whenever I make a new course.
For the old courses I have written a script, but it's not that robust  
or portable.

The nationalLibrary  (or database_problib or whatever name you wish  
to use) automatically adds a link if its missing.

I was thinking of adding some information to global.conf, so that  
something similar could be done with the other problem libraries.   
I'd replace

$courseFiles{problibs}    = {
	rochesterLibrary => "Rochester",
	rochester_grade8Library =>"Rochester grade 8",
	asuLibrary       => "Arizona State",
	dcdsLibrary      => "Detroit CDS",
	dartmouthLibrary => "Dartmouth",
	indianaLibrary   => "Indiana",
	nauLibrary       => "Northern Arizona",
	osuLibrary       => "Ohio State",	
    capaLibrary      => "CAPA",
    unionLibrary     =>  "Union",
    tcnjLibrary      => "TCNJ"
};


by

$courseFiles{problibs}    = {
	rochesterLibrary => { name => "Rochester", path=> '/ww/webwork/ 
rochester_problib'},
	rochester_grade8Library =>{name=> "Rochester grade 8", path => '/ww/ 
webwork/rochester8thgrade_problib'},
... etc.
};

With this structure we could later add more information about each  
library if that was needed.



Does anyone see downsides to this?  Should we just encourage the use  
of scripts, and perhaps write some robust ones?
Does anyone have better/different ideas about this?

Thanks much.

Take care,

Mike

Re: [WWdevel] Fwd: Hard copy generation

[Davide P. C. <dp...@un...>]

>> By the way, the error was in the line
>> ANS fun_cmp("t^2+at+b",var=>'t',params=>['a','b'])   ;
>>
>> which I changed to
>>
>> ANS fun_cmp("t^2+a t+b",var=>'t',params=>['a','b'])   ;
>>
>> In this case "at" was not recognized.  Maybe the old parser  
>> handled something like that or maybe Rick (the course was MTH 163)  
>> just ignored this error.

This was due to an error introduced with a recent change I had made  
(a couple of weeks ago) to allow multi-letter variable names (like  
x1, C0, etc).  I have fixed it and committed the changes to HEAD and  
the 2-2-dev revision.

Davide

[WWdevel] Re: comment on add courses

[Sam H. <sh...@ma...>]

On Jan 13, 2006, at 13:41, Arnold Pizer wrote:

> Hi Sam,
>
> I tried to used course_admin to add a course and got the error:
>
>
> An error occured while creating the course mth162:
> Failed to create course directory /ww/htdocs/tmp/mth162: File exists
>
> I think it would be reasonable in adding a course to just give a  
> warning message if the tmp directory can not be created.  In the  
> above case it's clear what's wrong and how to fix things but in  
> other cases (e.g. with sticky bits) it might not be. The downside  
> is that a course may be created without the tmp directory set up  
> correctly, but in the other case people may not be able to create a  
> course at all.  Also the message should make it clear whether or  
> not a course has been created.

Hi,

I'll change addCourse and deleteCourse to warn about directory  
creation/deletion errors as with renameCourse. Thanks for testing this.
-sam

[WWdevel] comment on add courses

[Arnold P. <ap...@ma...>]

<html>
<body>
Hi Sam,<br><br>
I tried to used course_admin to add a course and got the error:<br><br>
<br>
An error occured while creating the course mth162:<br>
<tt>Failed to create course directory /ww/htdocs/tmp/mth162: File
exists</tt> <br><br>
I think it would be reasonable in adding a course to just give a warning
message if the tmp directory can not be created.&nbsp; In the above case
it's clear what's wrong and how to fix things but in other cases (e.g.
with sticky bits) it might not be. The downside is that a course may be
created without the tmp directory set up correctly, but in the other case
people may not be able to create a course at all.&nbsp; Also the message
should make it clear whether or not a course has been created.&nbsp;
<br><br>
Arnie<br>
<x-sigsep><p></x-sigsep>
Prof. Arnold K. Pizer <br>
Dept. of Mathematics <br>
University of Rochester <br>
Rochester, NY 14627 <br>
(585) 275-7767<br>
</body>
</html>

[WWdevel] Fwd: Hard copy generation

[Sam H. <sh...@ma...>]

Begin forwarded message:

> From: Arnold Pizer <ap...@ma...>
> Date: January 11, 2006 21:12:05 EST
> To: sh...@ma...
> Cc: ap...@ma..., ga...@ma...
> Subject: Hard copy generation
>
> Hi Sam,
>
> I just went through all the fall courses generating hard copies of  
> all the assignments and this process went MUCH BETTER than in the  
> past.  The changes you made to the error reporting are excellent.   
> E.g in one course there were two problems that were bad (maybe  
> because a change to the new parser) and hardcopy pointed out the  
> bad problems, gave a link to edit them, and went on generating the  
> output with a warning that the bad problems were skipped.  In  
> another case, when there was a TeX error, it also did well.
>
> By the way, the error was in the line
> ANS fun_cmp("t^2+at+b",var=>'t',params=>['a','b'])   ;
>
> which I changed to
>
> ANS fun_cmp("t^2+a t+b",var=>'t',params=>['a','b'])   ;
>
> In this case "at" was not recognized.  Maybe the old parser handled  
> something like that or maybe Rick (the course was MTH 163) just  
> ignored this error.
>
> Arnie

[WWdevel] Re: NAU library,

[Michael G. <ga...@ma...>]

Hi David,

The NAU folks had made some changes in their directory structure and
added many more problems.  When I updated
the library accessed by the ProblemLibrary link at webwork  the  
pictures fixed themselves.
(I'm not 100% sure what the problem is, so I wouldn't say that this  
is a completely stable
fix, but for now the pictures are working again.)

Some of the problems involving Chromatic.pm  won't work from the  
ProblemLibrary link.
That module has some hardwired files in it, so it needs to be tweaked  
at each installation.

I probably won't do that for ProblemLibrary, but I have submitted a  
bug report to remind
me (or someone) to modify Chromatic.pm so that it is more portable.  
-- This won't be
a hard project, but it's not an urgent matter here, so it may take a  
while before it gets done by me. :-)


Thanks for the alert.

Take care,

Mike

On Jan 8, 2006, at 5:30 AM, David K. Watson wrote:

> I was looking at the NAU library problems, and the graph theory  
> problems do not
> have the correct images.  Instead of seeing euler graphs with edges  
> and vertices,
>  I keep seeing the same cartesian graph of a line in the xy-plane.
>
> David Watson

"Only dead fish swim with the stream."

Re: [WWdevel] WeBWorK 2.2 prerelease, PGProblemEditor.pm fixes.

[Michael G. <ga...@ma...>]

Hi all,

I think that PGProblemEditor.pm is ready for further testing again.   
I've checked it into both HEAD and to rel-2-2-dev   since
I think it is important that it work smoothly for this next release.

Davide, I don't think I have access to your version of Options.pm    
so I while I have included the hooks for options_info files they
may not work quite right.  Could you upload your version of  
Options.pm to HEAD?  I'd like to see what it does.

Bug report  #939 describes some of the cleanup efforts that could  
still be made to PGProblemEditor.pm, but I'm not planning to do that
in the near future.  It's a pretty complicated module -- I'd be happy  
to have some other eyes looking at it to see if some of the code can
be simplified -- but I don't think this is urgent either.

Take care,

Mike