#7008: [with patch, needs work] consolidate in plotting all extraction of
variables, ranges, and fast_float setup
----------------------+-----------------------------------------------------
Reporter: jason | Owner: was
Type: defect | Status: new
Priority: major | Milestone: sage-4.1.2
Component: graphics | Keywords:
Reviewer: | Author: Jason Grout
Merged: |
----------------------+-----------------------------------------------------
Comment(by jason):
Replying to [comment:5 kcrisman]:
> Cursory review reveals a bit of a slowdown. Try even
> {{{
> sage: f(x)=sin(x)
> sage: timeit('plot(f,(-pi,pi))')
> }}}
> Also notice that
> {{{
> sage: timeit('plot(f(x),(-pi,pi))')
> }}}
> is even slower yet. These are all milliseconds, not seconds, of course,
but in a large plot of many functions, a contour plot with a very dense
grid, or for making interacts snappy... Is there any way to fix that?
I will check into this. My guess is that any slowdown is in a fixed cost,
not a marginal cost, so the slowdown should not scale. Can you test, for
example, contour plots with varying grid sizes (before/after the patch) to
see if there is a huge slowdown?
I wonder how much moving this function to cython might help. Well, I
guess checking and then profiling is the right course of action.
>
> Also, what is the rationale for using fast_float and not fast_callable?
I ask only because there has been so much talk about "we should really use
fast_callable instead of fast_float for X". But I may not understand the
difference between the two.
fast_callable has not matured to the point that we need it yet. For
example, fast_callable(0) does not work, whereas fast_float(0) does.
#5572 lists some of the things that fast_callable needs to still
implement.
That said, fast_float uses fast_callable where it can. So for most
functions, I am actually using fast_callable underneath things.
>
> Finally, there should be at least one test to demonstrate that
> {{{
> sage: plot(f, -pi, pi)
> }}}
> and friends still work in the one-variable case, because there is no
reason for that to disappear in the name of consistency. The more
parentheses, the more confused students get. But it can be a test, since
of course we don't have to promote that syntax.
Hmmm...did I delete a test doing that? I didn't mean to.
I did change the parametric_plot syntax to deprecate ranges without
parenthesis. This was to maintain consistency with the 3d parametric
plot. For example, currently, parametric_plot((t,t^2), 0, 2*pi) works,
but parametric_plot((t,t^2,t^3), 0, 2*pi) does not work.
>
> These are all nitpicky. Nice refactoring, and all tests pass!
Thanks!
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/7008#comment:6>
Sage <http://sagemath.org/>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/sage-trac?hl=en
-~----------~----~----~----~------~----~------~--~---
