Menu
▾
▴
openwebwork-devel
|
From: Davide C. <dp...@un...> - 2008-07-08 15:41:33
|
I think this was a file that John Jones wrote originally, so perhaps
he knows where they are used. I am not aware of any that use it, and
don't see any by grepping the libraries. The error was probably
introduced by me last summer when I was trying to encapsulate the
initialization code and make sure it runs from the _init() routine
rather than in the .pl file itself.
As for whether there is a better way, currently this is the right way
to do it. One of the things that came out of the AIM conference is
that there needs to be a better way to add features to a context
(rather than just load a completely new context). I have some ideas
for that, but haven't completed the work on it. After that, it would
be reasonable to make this a "context patch" rather than a separate
context, but for now, this is the right way.
I think the name change to contextCombinatorics would be fine.
Davide
On Jul 8, 2008, at 11:09 AM, Mike Gage via activitymail wrote:
> Log Message:
> -----------
> fixed typo by changing all references to IntegerFunction or
> IntegerFunctions to the plural
>
> The typo gave an immediate error when IntegerFunctions2::Init was
> called instead of
> IntegerFunction2::Init while the internal name of the package was
> integerFunction2.
> The external name of the context was IntegerFunctions and
> everything has been changed
> to match that.
>
> The fact that this bug has existed so long leads me to believe that
> this context is not
> much used. Is there an alternative or better way to include C(n,k)
> and P(n,k) as
> functions in the context? I'd also suggest changing the name to
> something like
> contextCombinatorics since I think this is more likely to show up
> when someone searches
> for C(n,k) or P(N,k) functionality using a keyword search. This
> would be feasible
> if the current contextIntegerFunctions has not be used very much.
>
> -- Mike Gage and Noah Bennett
>
> Tags:
> ----
> rel-2-4-patches
>
> Modified Files:
> --------------
> pg/macros:
> contextIntegerFunctions.pl
>
> Revision Data
> -------------
> Index: contextIntegerFunctions.pl
> ===================================================================
> RCS file: /webwork/cvs/system/pg/macros/contextIntegerFunctions.pl,v
> retrieving revision 1.1.6.2.2.1
> retrieving revision 1.1.6.2.2.2
> diff -Lmacros/contextIntegerFunctions.pl -Lmacros/
> contextIntegerFunctions.pl -u -r1.1.6.2.2.1 -r1.1.6.2.2.2
> --- macros/contextIntegerFunctions.pl
> +++ macros/contextIntegerFunctions.pl
> @@ -46,7 +46,7 @@
>
> sub _contextIntegerFunctions_init {context::IntegerFunctions2::Init
> ()}; # don't reload this file
>
> -package context::IntegerFunction2;
> +package context::IntegerFunctions2;
> our @ISA = qw(Parser::Function::numeric2); # checks for 2 numeric
> inputs
>
> sub C {
> @@ -69,8 +69,8 @@
> $context->{name} = "IntegerFunctions";
>
> $context->functions->add(
> - C => {class => 'context::IntegerFunction2'},
> - P => {class => 'context::IntegerFunction2'},
> + C => {class => 'context::IntegerFunctions2'},
> + P => {class => 'context::IntegerFunctions2'},
> );
>
> main::Context("IntegerFunctions");
>
> ----------------------------------------------------------------------
> ---
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> _______________________________________________
> OpenWeBWorK-CVS mailing list
> Ope...@li...
> https://lists.sf.net/lists/listinfo/openwebwork-cvs
>
>
|
|
From: John J. <jj...@as...> - 2008-07-08 16:23:23
|
I did add the original version of this context. I had someone who
wanted students to be able to use P(n,r) and C(n,r) in their answers on
some problems. But, for one reason or another, he never wrote any
problems with it for general use.
I don't see any obstruction to changing the name to
contextCombinatorics. I don't recall if there was some reason for
preferring contextIntegerFunctions initially. Maybe there was some
thought that people might want to extend it at a later time to allow
gcd, powermod, or some other integer functions.
John
Davide Cervone wrote:
> I think this was a file that John Jones wrote originally, so perhaps
> he knows where they are used. I am not aware of any that use it, and
> don't see any by grepping the libraries. The error was probably
> introduced by me last summer when I was trying to encapsulate the
> initialization code and make sure it runs from the _init() routine
> rather than in the .pl file itself.
>
> As for whether there is a better way, currently this is the right way
> to do it. One of the things that came out of the AIM conference is
> that there needs to be a better way to add features to a context
> (rather than just load a completely new context). I have some ideas
> for that, but haven't completed the work on it. After that, it would
> be reasonable to make this a "context patch" rather than a separate
> context, but for now, this is the right way.
>
> I think the name change to contextCombinatorics would be fine.
>
> Davide
>
>
> On Jul 8, 2008, at 11:09 AM, Mike Gage via activitymail wrote:
>
>
>> Log Message:
>> -----------
>> fixed typo by changing all references to IntegerFunction or
>> IntegerFunctions to the plural
>>
>> The typo gave an immediate error when IntegerFunctions2::Init was
>> called instead of
>> IntegerFunction2::Init while the internal name of the package was
>> integerFunction2.
>> The external name of the context was IntegerFunctions and
>> everything has been changed
>> to match that.
>>
>> The fact that this bug has existed so long leads me to believe that
>> this context is not
>> much used. Is there an alternative or better way to include C(n,k)
>> and P(n,k) as
>> functions in the context? I'd also suggest changing the name to
>> something like
>> contextCombinatorics since I think this is more likely to show up
>> when someone searches
>> for C(n,k) or P(N,k) functionality using a keyword search. This
>> would be feasible
>> if the current contextIntegerFunctions has not be used very much.
>>
>> -- Mike Gage and Noah Bennett
>>
>> Tags:
>> ----
>> rel-2-4-patches
>>
>> Modified Files:
>> --------------
>> pg/macros:
>> contextIntegerFunctions.pl
>>
>> Revision Data
>> -------------
>> Index: contextIntegerFunctions.pl
>> ===================================================================
>> RCS file: /webwork/cvs/system/pg/macros/contextIntegerFunctions.pl,v
>> retrieving revision 1.1.6.2.2.1
>> retrieving revision 1.1.6.2.2.2
>> diff -Lmacros/contextIntegerFunctions.pl -Lmacros/
>> contextIntegerFunctions.pl -u -r1.1.6.2.2.1 -r1.1.6.2.2.2
>> --- macros/contextIntegerFunctions.pl
>> +++ macros/contextIntegerFunctions.pl
>> @@ -46,7 +46,7 @@
>>
>> sub _contextIntegerFunctions_init {context::IntegerFunctions2::Init
>> ()}; # don't reload this file
>>
>> -package context::IntegerFunction2;
>> +package context::IntegerFunctions2;
>> our @ISA = qw(Parser::Function::numeric2); # checks for 2 numeric
>> inputs
>>
>> sub C {
>> @@ -69,8 +69,8 @@
>> $context->{name} = "IntegerFunctions";
>>
>> $context->functions->add(
>> - C => {class => 'context::IntegerFunction2'},
>> - P => {class => 'context::IntegerFunction2'},
>> + C => {class => 'context::IntegerFunctions2'},
>> + P => {class => 'context::IntegerFunctions2'},
>> );
>>
>> main::Context("IntegerFunctions");
>>
>> ----------------------------------------------------------------------
>> ---
>> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
>> Studies have shown that voting for your favorite open source project,
>> along with a healthy diet, reduces your potential for chronic lameness
>> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
>> _______________________________________________
>> OpenWeBWorK-CVS mailing list
>> Ope...@li...
>> https://lists.sf.net/lists/listinfo/openwebwork-cvs
>>
>>
>>
>
>
> -------------------------------------------------------------------------
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> _______________________________________________
> OpenWeBWorK-Devel mailing list
> Ope...@li...
> https://lists.sf.net/lists/listinfo/openwebwork-devel
>
|
|
From: Michael G. <ga...@ma...> - 2008-07-08 17:49:17
|
Hi John,
It might be reasonable to add those functions later. It's also
possible that there are few enough of these that
they could be added to PGcommonfunctions.pl or PGauxiliaryfunctions.
Here's my plan: For this rel-2-4-5 I'll just fix the typos and we
can think about how to
consolidate the functions later, perhaps along with a plan for allowing
context "patches".
Take care,
Mike
On Jul 8, 2008, at 12:23 PM, John Jones wrote:
> I did add the original version of this context. I had someone who
> wanted students to be able to use P(n,r) and C(n,r) in their
> answers on
> some problems. But, for one reason or another, he never wrote any
> problems with it for general use.
>
> I don't see any obstruction to changing the name to
> contextCombinatorics. I don't recall if there was some reason for
> preferring contextIntegerFunctions initially. Maybe there was some
> thought that people might want to extend it at a later time to allow
> gcd, powermod, or some other integer functions.
>
> John
>
> Davide Cervone wrote:
>> I think this was a file that John Jones wrote originally, so perhaps
>> he knows where they are used. I am not aware of any that use it, and
>> don't see any by grepping the libraries. The error was probably
>> introduced by me last summer when I was trying to encapsulate the
>> initialization code and make sure it runs from the _init() routine
>> rather than in the .pl file itself.
>>
>> As for whether there is a better way, currently this is the right way
>> to do it. One of the things that came out of the AIM conference is
>> that there needs to be a better way to add features to a context
>> (rather than just load a completely new context). I have some ideas
>> for that, but haven't completed the work on it. After that, it would
>> be reasonable to make this a "context patch" rather than a separate
>> context, but for now, this is the right way.
>>
>> I think the name change to contextCombinatorics would be fine.
>>
>> Davide
>>
>>
>> On Jul 8, 2008, at 11:09 AM, Mike Gage via activitymail wrote:
>>
>>
>>> Log Message:
>>> -----------
>>> fixed typo by changing all references to IntegerFunction or
>>> IntegerFunctions to the plural
>>>
>>> The typo gave an immediate error when IntegerFunctions2::Init was
>>> called instead of
>>> IntegerFunction2::Init while the internal name of the package was
>>> integerFunction2.
>>> The external name of the context was IntegerFunctions and
>>> everything has been changed
>>> to match that.
>>>
>>> The fact that this bug has existed so long leads me to believe that
>>> this context is not
>>> much used. Is there an alternative or better way to include C(n,k)
>>> and P(n,k) as
>>> functions in the context? I'd also suggest changing the name to
>>> something like
>>> contextCombinatorics since I think this is more likely to show up
>>> when someone searches
>>> for C(n,k) or P(N,k) functionality using a keyword search. This
>>> would be feasible
>>> if the current contextIntegerFunctions has not be used very much.
>>>
>>> -- Mike Gage and Noah Bennett
>>>
>>> Tags:
>>> ----
>>> rel-2-4-patches
>>>
>>> Modified Files:
>>> --------------
>>> pg/macros:
>>> contextIntegerFunctions.pl
>>>
>>> Revision Data
>>> -------------
>>> Index: contextIntegerFunctions.pl
>>> ===================================================================
>>> RCS file: /webwork/cvs/system/pg/macros/contextIntegerFunctions.pl,v
>>> retrieving revision 1.1.6.2.2.1
>>> retrieving revision 1.1.6.2.2.2
>>> diff -Lmacros/contextIntegerFunctions.pl -Lmacros/
>>> contextIntegerFunctions.pl -u -r1.1.6.2.2.1 -r1.1.6.2.2.2
>>> --- macros/contextIntegerFunctions.pl
>>> +++ macros/contextIntegerFunctions.pl
>>> @@ -46,7 +46,7 @@
>>>
>>> sub _contextIntegerFunctions_init {context::IntegerFunctions2::Init
>>> ()}; # don't reload this file
>>>
>>> -package context::IntegerFunction2;
>>> +package context::IntegerFunctions2;
>>> our @ISA = qw(Parser::Function::numeric2); # checks for 2 numeric
>>> inputs
>>>
>>> sub C {
>>> @@ -69,8 +69,8 @@
>>> $context->{name} = "IntegerFunctions";
>>>
>>> $context->functions->add(
>>> - C => {class => 'context::IntegerFunction2'},
>>> - P => {class => 'context::IntegerFunction2'},
>>> + C => {class => 'context::IntegerFunctions2'},
>>> + P => {class => 'context::IntegerFunctions2'},
>>> );
>>>
>>> main::Context("IntegerFunctions");
>>>
>>> --------------------------------------------------------------------
>>> --
>>> ---
>>> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
>>> Studies have shown that voting for your favorite open source
>>> project,
>>> along with a healthy diet, reduces your potential for chronic
>>> lameness
>>> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
>>> _______________________________________________
>>> OpenWeBWorK-CVS mailing list
>>> Ope...@li...
>>> https://lists.sf.net/lists/listinfo/openwebwork-cvs
>>>
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> ----
>> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
>> Studies have shown that voting for your favorite open source project,
>> along with a healthy diet, reduces your potential for chronic
>> lameness
>> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
>> _______________________________________________
>> OpenWeBWorK-Devel mailing list
>> Ope...@li...
>> https://lists.sf.net/lists/listinfo/openwebwork-devel
>>
>
>
> ----------------------------------------------------------------------
> ---
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> _______________________________________________
> OpenWeBWorK-Devel mailing list
> Ope...@li...
> https://lists.sf.net/lists/listinfo/openwebwork-devel
>
|
|
From: John J. <jj...@as...> - 2008-07-08 17:58:41
|
Michael Gage wrote: > Hi John, > > It might be reasonable to add those functions later. It's also > possible that there are few enough of these that they could be added > to PGcommonfunctions.pl or PGauxiliaryfunctions. The current plan sounds fine. When considering where to add functions, bear in mind the issue of whether only problem authors will be able to use the function, or if students can use it in their answers. In the second case, I suppose you would also need to decide if the default is to allow them to use the functions or not. This was part of the rationale for the new context initially (by default students would not be able to use say C(n,r) or it would trivialize some existing problems, but in more complicated counting problems you might want to enable it). By the way, does webwork have a version of PowerMod for problem authors? I was thinking of using webwork with a cryptography class (it would be my first time!), and this was one of the first functions I wanted. John |
|
From: Davide P. C. <dp...@un...> - 2008-07-08 18:42:01
|
> It might be reasonable to add those functions later. It's also > possible that there are few enough of these that > they could be added to PGcommonfunctions.pl or PGauxiliaryfunctions. John has already mentioned this, but I want to be extra clear about the point he made. The PGcommonfunctions.pl and PGauxiliaryfunction.pl files defined commands available to the problem AUTHOR. Note that C() and P() are already defined there. The functions available to the students in their answers is controlled by the Context(), and contextIntegerFunctions.pl makes C() and P() available to students in their answers. That certainly should not be the default, in my opinion. Davide |
|
From: Michael G. <ga...@ma...> - 2008-07-08 19:36:05
|
I think I've got it :-). Thanks.
The PGauxiliaryfunctions.pl and PGcommonFunctions.pl define perl
functions not MathObject functions.
Instructors can use perl functions such as $a = C(15,3)
but $A = Compute("C(15,3)"); will produce an error and students will
not be able to use C(15,3) as part of their answer. This all seems
like the correct behavior to me.
(I believe this is a minor change from the behavior of fun_cmp before
MathObjects since, to the best of my recollection,
the perl parser for fun_cmp had access to any function defined in a
main:: by PGauxiliaryfunctions.pl ) The current situation is
preferable I just
need to make sure I understand it well enough to document it accurately.
For the next step: My first impression is that we can add the dozen
or so remaining functions in PGauxiliaryfunctions.pl to
PGcommonFunctions.pl and eliminate or redirect the first file
completely. Another task will be to inventory the functions defined
in PGauxiliaryfunctions.pl
(and perhaps PGcommonFunctions.pl) and see which of them should be
added either to the general context or added to specialized
contexts so that the functions can also be used in MathObjects. Many
of them have already been added.
In both cases the goal would be to make it easy for a new author to
determine
(1) which "special" functions have already been defined somewhere in
the PG files.
(2) which contexts (specialized or general) are needed in order to
allow use
of these functions in MathObjects by instructors or students.
Take care,
Mike
On Jul 8, 2008, at 2:41 PM, Davide P. Cervone wrote:
>> It might be reasonable to add those functions later. It's also
>> possible that there are few enough of these that
>> they could be added to PGcommonfunctions.pl or PGauxiliaryfunctions.
>
> John has already mentioned this, but I want to be extra clear about
> the point he made. The PGcommonfunctions.pl and
> PGauxiliaryfunction.pl files defined commands available to the
> problem AUTHOR. Note that C() and P() are already defined there.
> The functions available to the students in their answers is
> controlled by the Context(), and contextIntegerFunctions.pl makes C()
> and P() available to students in their answers. That certainly should
> not be the default, in my opinion.
>
> Davide
>
> ----------------------------------------------------------------------
> ---
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> _______________________________________________
> OpenWeBWorK-Devel mailing list
> Ope...@li...
> https://lists.sf.net/lists/listinfo/openwebwork-devel
>
|
|
From: Davide P. C. <dp...@un...> - 2008-07-09 12:19:28
|
> The PGauxiliaryfunctions.pl and PGcommonFunctions.pl define perl
> functions not MathObject functions.
Right.
> Instructors can use perl functions such as $a = C(15,3)
> but $A = Compute("C(15,3)"); will produce an error and students will
> not be able to use C(15,3) as part of their answer.
Right again.
> This all seems like the correct behavior to me.
Good.
> (I believe this is a minor change from the behavior of fun_cmp before
> MathObjects since, to the best of my recollection,
> the perl parser for fun_cmp had access to any function defined in a
> main:: by PGauxiliaryfunctions.pl ) The current situation is
> preferable I just
> need to make sure I understand it well enough to document it
> accurately.
That might be the case, but I don't remember. That would be bad,
since main:: contains LOTS of functions.
> For the next step: My first impression is that we can add the dozen
> or so remaining functions in PGauxiliaryfunctions.pl to
> PGcommonFunctions.pl and eliminate or redirect the first file
> completely.
I think PGcommonFunctions.pl would be the one to remove, as it is not
called directly from any problem files, but only from
PGauxiliaryFunctions.pl and Parser.pl (or maybe it's Value.pl; I
don't remember).
Note that the dozen or so other functions are not ones that usually
make sense for use in student answers, which is one of the reasons
that they are not available in MathObjects. But it would not be a
problem if they were moved to PGcommonFunctions.pl either as direct
definitions, or as the kind that use CommonFunctions->Call so that
they COULD be hooked into MathObjects if desired.
> Another task will be to inventory the functions defined
> in PGauxiliaryfunctions.pl
> (and perhaps PGcommonFunctions.pl) and see which of them should be
> added either to the general context or added to specialized
> contexts so that the functions can also be used in MathObjects. Many
> of them have already been added.
All the ones in commonFunctions.pl are in MathObjects contexts. You
could list which ones are in which contexts, I guess. The ones in
PGauxiliaryFunctions.pl are NOT in any MathObject context.
> In both cases the goal would be to make it easy for a new author to
> determine
> (1) which "special" functions have already been defined somewhere in
> the PG files.
> (2) which contexts (specialized or general) are needed in order to
> allow use of these functions in MathObjects by instructors or
> students.
Remember that is is always possible to add new functions to a context
(and to copy them from one context to another on the fly).
Davide
|
|
From: Michael G. <ga...@ma...> - 2008-07-08 16:04:32
|
Thanks Davide, On another issue -- problemPreserveAnswers.pl keeps $ from being erased in student sticky answers. Does using EV3P fix this problem directly in PGbasicmacros.pl? I don't have a test case to work on to see if this issue is fixed in rel-2-4-patches. If it's not already fixed then one will still have to use problemPreserveAnswers.pl for this release. Take care, Mike On Jul 8, 2008, at 11:41 AM, Davide Cervone wrote: > I think this was a file that John Jones wrote originally, so perhaps > he knows where they are used. I am not aware of any that use it, and > don't see any by grepping the libraries. The error was probably > introduced by me last summer when I was trying to encapsulate the > initialization code and make sure it runs from the _init() routine > rather than in the .pl file itself. > > As for whether there is a better way, currently this is the right way > to do it. One of the things that came out of the AIM conference is > that there needs to be a better way to add features to a context > (rather than just load a completely new context). I have some ideas > for that, but haven't completed the work on it. After that, it would > be reasonable to make this a "context patch" rather than a separate > context, but for now, this is the right way. > > I think the name change to contextCombinatorics would be fine. > > Davide > > |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X