I am very interested by what you have developped. It looks a bit like
what I am doing.
I 'll contact you directly.
yours
t.
Le 11/10/2014 03:26, Alasdair a écrit :
I've written an article about using Sage to develop explicit Runge-Kutta
formulas for the numerical solution of ODEs. I've sent
Hi Jori,
When Travis and I were working on the bug fix for 14019, we were also
contemplating deprecating HasseDiagram
and moving the methods to FinitePoset. This seems like a logical thing to
do. I think this is the right next step
to clean up the code!
Anne
--
You received this message becau
I've written an article about using Sage to develop explicit Runge-Kutta
formulas for the numerical solution of ODEs. I've sent it off to a few
journals, all of whom have rejected it - clearly it's not quite the right
"fit" for any of them: it's too technical for education journals, and not
th
On Friday, October 10, 2014 2:11:40 PM UTC-7, Dan Drake wrote:
>
> On Fri, 10 Oct 2014 at 03:52PM -0500, Dan Drake wrote:
> > I wish there was, say, search_methods. On a matrix, for example:
>
> I also wish I would remember "dir()", which naturally came to me after
> hitting "send".
>
> Argh.
On Fri, 10 Oct 2014 at 03:52PM -0500, Dan Drake wrote:
> I wish there was, say, search_methods. On a matrix, for example:
I also wish I would remember "dir()", which naturally came to me after
hitting "send".
Argh.
(But I do kinda want search_methods, since it's more likely I would
remember it..
What about A.*eiegn[tab]
On Oct 10, 2014 1:54 PM, "Dan Drake" wrote:
> For objects that have lots of methods, it's not very easy to find one by
> doing
>
> X.
>
> since there's just so much. In analogy with search_def, search_src, etc,
> I wish there was, say, search_methods. On a matrix, for
On Friday, October 10, 2014 1:54:37 PM UTC-7, Dan Drake wrote:
>
> For objects that have lots of methods, it's not very easy to find one by
> doing
>
> X.
>
> since there's just so much. In analogy with search_def, search_src, etc,
> I wish there was, say, search_methods. On a matrix, for
Hello !
> And .is_exact(). But to be honest, at the end of documentation of
> .base_ring() it says "Todo Move this method elsewhere - -".
"git blame" will tell you that these things are here since around
2008. The message has been written in #10963 though.
> Thinking more about (possible) logic
For objects that have lots of methods, it's not very easy to find one by
doing
X.
since there's just so much. In analogy with search_def, search_src, etc,
I wish there was, say, search_methods. On a matrix, for example:
search_methods(A, 'eigen')
which would, in effect, do
A. | gr
On Fri, 10 Oct 2014, Nathann Cohen wrote:
So, what is the logic behind this?
I don't think that there is any.
Duh.
To understand what I mean, just observe that posets have a .base_ring()
method. Or a .construction() method.
And .is_exact(). But to be honest, at the end of documentation
> Travis and I fixed the bug on the ticket. See the comments there.
Thank you for working on that.
Nathann
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-d
> The reason why I cannot fix the bug, however, is because of a bad
> design that appeared before.
Travis and I fixed the bug on the ticket. See the comments there.
Anne
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this gr
Hello !
So, what is the logic behind this?
>
I don't think that there is any. From what I know of this class nobody
cares sufficiently to do that consistently. If you think that things should
be done a different way, just do it. Just make sure that it does not break
anything.
To understand w
On Friday, October 10, 2014 8:07:50 AM UTC-7, Volker Braun wrote:
>
> Don't build Sage as root, build it as normal user.
>
Should we check this at the very beginning of the build process and print a
clear warning if someone tries to build as root?
John
>
>
>
> On Friday, October 10, 2014
Don't build Sage as root, build it as normal user.
On Friday, October 10, 2014 3:42:44 PM UTC+1, Nigel Smart wrote:
>
> Hi
>
> On compiling i get the following error when it gets to ntl...
>
> mkdir -m 755 /usr/local/sage/sage-6.3/local/include/NTL
> cp -p ../include/NTL/*.h /usr/local/sage/sage
Hi
On compiling i get the following error when it gets to ntl...
mkdir -m 755 /usr/local/sage/sage-6.3/local/include/NTL
cp -p ../include/NTL/*.h /usr/local/sage/sage-6.3/local/include/NTL
cp: preserving permissions for
`/usr/local/sage/sage-6.3/local/include/NTL/FFT.h': Operation not supported
Ok, you are talking about 1.0 argument, which should lower the precision to
53 bit.
We should probably use all inexact (floating-point) arguments to decide the
precision, not just the first one.
On Friday, October 10, 2014 12:32:29 PM UTC+1, Jeroen Demeyer wrote:
>
> On 2014-10-10 12:38, Volk
On 2014-10-10 12:38, Volker Braun wrote:
This is probably what you wanted:
sage: bessel_Y(RealField(200)(1), 1.0, hold=True)
-0.7812128213002887165471504796482054990639071644460784383
No, that's not what I wanted. It doesn't make sense to return an answer
which is more precise than the inpu
This is probably what you wanted:
sage: bessel_Y(RealField(200)(1), 1.0, hold=True)
-0.7812128213002887165471504796482054990639071644460784383
On Friday, October 10, 2014 10:25:57 AM UTC+1, Jeroen Demeyer wrote:
>
> Could somebody who knows about numerical evaluation of symbolic
> functions
Could somebody who knows about numerical evaluation of symbolic
functions please have a look at #17130. The problem is that there is
some coercion going on *after* calling _eval_().
Look at the difference between the following two (the second has false
precision):
sage: bessel_Y._eval_(RealF
20 matches
Mail list logo
