Changes between Version 17 and Version 18 of Ticket #5572


Ignore:
Timestamp:
09/07/10 02:49:45 (9 years ago)
Author:
jason
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #5572

    • Property Authors changed from to Jason Grout
  • Ticket #5572 – Description

    v17 v18  
    11The code at #5093 is very good and ready to go in, but there are several improvements that have been suggested and agreed work on at a later date. They are posted here so we can merge and close the other ticket.
    22
    3 Specifically,
     3Specifically, this ticket addresses these issues:
    44
    5 Not fixed:
     5  * fast_callable on list,tuple,vector,matrix arguments
    66
    7 * Robert's suggestion: an option that uses a fast domain, if it's there, but ignores the domain parameter if it's not (I don't mind the idea, and the implementation is easy; what should the syntax be? Part of my problem picking a syntax is that I don't want to promise that a specialized interpreter is always faster than the Python-object interpreter, so I don't particularly want to use the word "fast" in any option names.)
     7  * fast_callable on constant arguments
    88
    9 * fast_callable on list,tuple,vector,matrix arguments
     9  * fast_callable of a zero multivariate polynomial returns a zero of the base ring, without paying attention to the types of the arguments
    1010
    11 * any interaction with #5413 (my plan is to wait until either #5093 or #5413 gets a positive review, then fix the other one to match)
     11  * in general replaces calls to fast_float with calls to fast_callable.
    1212
    13 * fast_callable on constant arguments (waiting for a spec from Jason!)
     13  * Carries out the deprecation in #5413 (removes the functionality deprecated there)
    1414
    15 * fast_callable of a zero multivariate polynomial returns a zero of the base ring, without paying attention to the types of the arguments
     15Because of some of the far-reaching changes, this should probably not be merged in a point-point release.
     16
     17What is not fixed:
     18
     19  * Robert's suggestion: an option that uses a fast domain, if it's there, but ignores the domain parameter if it's not (I don't mind the idea, and the implementation is easy; what should the syntax be? Part of my problem picking a syntax is that I don't want to promise that a specialized interpreter is always faster than the Python-object interpreter, so I don't particularly want to use the word "fast" in any option names.)
     20
     21
     22
     23
    1624
    1725The work on this ticket: