On 2016-04-09 16:23, William Stein wrote:
Feedback from users makes it clear they need a stable foundation on
which to build their work
And you think having *many* packages with interdependencies which are
independently managed will actually make it more *stable*? Sounds like
the contrary to
integrate( lambda(y),x^2+y^2)) could be mechanically converted to
integrate(x^2+y^2, y)
and vice versa.
There is a name for this in lambda calculus. alpha conversion or some such
thing.
Should you do this?
doesn't matter. But if so, do it for summation, products, plotting, etc.
On Sat
I don't know what nonsense you are trying out, but f(r,phi):=signum(r^2-4)
is a function that does not
depend on phi.
If you want to integrate functions that are discontinuous, there are two
processes
involved. One: find the continuous pieces and break up the problem.
Two, integrate, as appro
On Saturday, April 9, 2016 at 9:17:27 AM UTC-7, David Roe wrote:
>
>
> Is there any ambiguity? g is a function of one variable and we're
> specifying the variable of integration. Is there a reason that we
> shouldn't allow indefinite_integral(g, x) to work?
> David
>
> In you just use integral,
There may be a few extra kinks. I never tested MKL in sage-on-gentoo. It may
require setting
extra rpath for the library if it is not in a path in ld.conf.so. Not difficult.
François
> On 10/04/2016, at 06:44, Volker Braun wrote:
>
> Just recently we changed the way we link to blas, it is now
maxima's definite integration is quite buggy, we see dozens bugs like this
a year, and report them upstream, with limited success...
On Saturday, April 9, 2016 at 7:17:09 PM UTC+1, Sergey V Kozlukov wrote:
>
> (%i1) f(r,phi) := signum(r^2 - 4);
>2
Just recently we changed the way we link to blas, it is now all
through local/lib/pkgconfig/blas.pc. So it will be massively easier to
change the underlying blas implementation, and we are preparing to work
with openblas. And MKL shouldn't be too hard either.
We do have a MKL license to use it
On 09/04/16 14:36, Dima Pasechnik wrote:
On Saturday, April 9, 2016 at 6:19:57 PM UTC+1, lundy@gmail.com wrote:
Thanks Dima,
this will at least allow me to do what I need.
note, I have avoided using f=x^2, for a while now due to deprecation
warnings like this:
sage: f=x^2
sage: f(5)
/usr
(%i1) f(r,phi) := signum(r^2 - 4);
2
(%o1) f(r, phi) := signum(r - 4)
(%i2) integrate(integrate(r*f(r,phi), r, 0, 3), phi, 0, 2*%pi);
(%o2) - 9 %pi
That's strange
суббота, 9 апреля 2016 г., 19:14:49
On Saturday, April 9, 2016 at 6:51:53 PM UTC+1, David Roe wrote:
>
>
> On Sat, Apr 9, 2016 at 12:33 PM, Ahmed Fasih > wrote:
>
>> Hi everyone, it may be time to revisit Sage & Intel's high-performance
>> libraries—Intel's Community License Program launched a few months ago and
>> gives no-cost
On Sat, Apr 9, 2016 at 12:33 PM, Ahmed Fasih wrote:
> Hi everyone, it may be time to revisit Sage & Intel's high-performance
> libraries—Intel's Community License Program launched a few months ago and
> gives no-cost, royalty-free licenses for MKL, TBB, IPP, & DAAL:
> https://software.intel.com/e
On Saturday, April 9, 2016 at 6:19:57 PM UTC+1, lundy@gmail.com wrote:
>
> Thanks Dima,
> this will at least allow me to do what I need.
>
> note, I have avoided using f=x^2, for a while now due to deprecation
> warnings like this:
> sage: f=x^2
> sage: f(5)
> /usr/lib/sagemath/local/lib/pyt
Thanks Dima,
this will at least allow me to do what I need.
note, I have avoided using f=x^2, for a while now due to deprecation
warnings like this:
sage: f=x^2
sage: f(5)
/usr/lib/sagemath/local/lib/python2.7/site-packages/IPython/core/
interactiveshell.py:2885:
DeprecationWarning: Substitution
Hi everyone, it may be time to revisit Sage & Intel's high-performance
libraries—Intel's Community License Program launched a few months ago and
gives no-cost, royalty-free licenses for MKL, TBB, IPP, & DAAL:
https://software.intel.com/en-us/free_tools_and_libraries
You register, they send you
On Sat, Apr 9, 2016 at 12:12 PM, Dima Pasechnik wrote:
>
>
> On Saturday, April 9, 2016 at 4:53:50 PM UTC+1, lundy@gmail.com wrote:
>>
>> I believe I have found a bug, and was not able to find any previous
>> report or ticket to have it fixed.
>>
>> I would expect the indefinite_integral meth
Try these computations directly in Maxima, and see whether it's still a
discrepancy there.
On Saturday, April 9, 2016 at 1:31:44 PM UTC+1, Sergey V Kozlukov wrote:
>
> x, y, r, phi = var('x y r phi')
> f(x, y) = sign(x^2 + y^2 - 4)
> T(r, phi) = [r*cos(phi), r*sin(phi)]
> J = diff(T).det().simpli
On Saturday, April 9, 2016 at 4:53:50 PM UTC+1, lundy@gmail.com wrote:
>
> I believe I have found a bug, and was not able to find any previous report
> or ticket to have it fixed.
>
> I would expect the indefinite_integral method to accept a function and
> provide output, but it only works
On Saturday, April 9, 2016 at 3:24:27 PM UTC+1, William wrote:
>
> On Sat, Apr 9, 2016 at 2:49 AM, Dima Pasechnik > wrote:
> >> SMC does inform my frustration with the current limitations on Sage
> >> development.
> >
> > I am afraid we see a conflict of interest here.
> > It is in interests
I believe I have found a bug, and was not able to find any previous report
or ticket to have it fixed.
I would expect the indefinite_integral method to accept a function and
provide output, but it only works if I input the symbolic expression itself.
EX:
sage: from sage.symbolic.integration.in
I think that this summary is right, including the explicit conversion that
relies on the index in gens().
David
On Sat, Apr 9, 2016 at 4:15 AM, Volker Braun wrote:
> Let me try to summarize the expected behavior: If there is a coercion of
> the base rings, then there should be a coercion to the
On Sat, Apr 9, 2016 at 2:49 AM, Dima Pasechnik wrote:
>> SMC does inform my frustration with the current limitations on Sage
>> development.
>
> I am afraid we see a conflict of interest here.
> It is in interests of SMC that Sage is very, very stable... Frozen.
I want Sage to be (massively) eas
I mentioned that; Is it really strange though? It does not happen
implicitly through coercion. You have to explicitly ask to convert one
polynomial ring in two variables to another polynomial ring in two
variables (with mismatching generator names).
On Saturday, April 9, 2016 at 3:09:08 PM UT
On 09/04/16 05:15, Volker Braun wrote:
Let me try to summarize the expected behavior: If there is a coercion of
the base rings, then there should be a coercion to the (laurent) polynomial
ring with additional variables. The variables in the different rings are
identified using their name (and not
x, y, r, phi = var('x y r phi')
f(x, y) = sign(x^2 + y^2 - 4)
T(r, phi) = [r*cos(phi), r*sin(phi)]
J = diff(T).det().simplify_full()
T_f = f.substitute(x=T[0], y=T[1])
int_f = integral(integral(T_f*abs(J), r, 0, 3), phi, 0, 2*pi).simplify_full
()
show(r"$\iint\limits_\Omega%s = %s$"%(latex(f(x)), l
On Saturday, April 9, 2016 at 12:17:21 AM UTC+1, William wrote:
>
>
>
> On Friday, April 8, 2016, Dima Pasechnik >
> wrote:
>
>>
>>
>> On Friday, April 8, 2016 at 7:40:02 PM UTC+1, William wrote:
>>>
>>>
>>>
>>> On Friday, April 8, 2016, Volker Braun wrote:
>>>
On Friday, April 8, 2016 at
Let me try to summarize the expected behavior: If there is a coercion of
the base rings, then there should be a coercion to the (laurent) polynomial
ring with additional variables. The variables in the different rings are
identified using their name (and not index in gens() or any other rule).
26 matches
Mail list logo
