Le lundi 25 novembre 2013 01:02:39 UTC+1, Volker Braun a écrit :
Note that there is no need to repeat the 'x, y' labels here if you adjust
the argspec for U.chart a bit. The point of the R.x syntax is that the
coordinate names are supplied as strings as well as assigned to variables:
to be done. People interested in contributing are
welcome! We have set up a git repository (
https://gitroc.obspm.fr/gitweb/SageManifolds.git /) for this (see the
instructions here /), as well as a mailing list /.
Eric Gourgoulhon Michal Bejger.
--
You received this message because you
Sorry, the last links in the above message have been mistyped:
- the S^2 example is here http://sagemanifolds.obspm.fr/examples.html
- the git repository is
herehttps://gitroc.obspm.fr/gitweb/SageManifolds.git(follow these
instructions
Hi,
I already answered on SageManifolds list but I repeat here for people
interested:
yes it is possible to define a general (i.e. not necessarily Levi-Civita)
affine connection in SageManifolds; see the examples on the page
http://sagemanifolds.obspm.fr/doc/sagemanifolds/connection.html
Best
Hi,
I totally subscribe to your point 2: the line numbers provided with
warnings during the documentation built do not correspond to actual line
numbers in the source files. I do not know the meaning of these line
numbers. Does anybody have some hint about this ?
Best wishes,
Eric.
Le
Le samedi 14 septembre 2013 22:03:59 UTC+2, Simon King a écrit :
I hope that
http://www.sagemath.org/doc/thematic_tutorials/coercion_and_categories.html
will also be helpful.
Thank you for this link ! Indeed, it seems the right place to start with.
Best,
Eric.
--
You received this
Le vendredi 13 septembre 2013 16:50:41 UTC+2, Volker Braun a écrit :
In Sage, parents pretty much need to be logically immutable. You can
certainly add cached data (that can be derived from the originial input)
but you shouldn't modify them in a way that makes them mathematically
Dear Volker,
Thanks for your very instructive comments.
I agree we should use factory methods and implement Parent/Element for
Manifold/Point.
Regarding the mutability, I am not sure it is a good thing to construct a
manifold in a single step by passing all the charts and all the transition
outputs
- better efficiency (migrating some parts to Cython?)
and probably a lot more...
Comments, suggestions and helps are most welcome!
Eric Gourgoulhon Michal Bejger.
--
You received this message because you are subscribed to the Google Groups
sage-devel group.
To unsubscribe from
Le jeudi 12 septembre 2013 18:30:21 UTC+2, vdelecroix a écrit :
Still missing:
- the implementation of Sage Parent/Element scheme for a better
integration in Sage
Do you need some help for that point? It is not clear what to do. On a
manifold you have points (and more
We have just added a tutorial introducing the package at the page:
http://sagemanifolds.obspm.fr/documentation.html
A mailing list has also been opened:
http://sagemanifolds.obspm.fr/contact.html
--
You received this message because you are subscribed to the Google Groups
sage-devel group.
To
Le jeudi 11 juillet 2013 21:26:43 UTC+2, mmarco a écrit :
It looks very good. Just one remark: i think that the different functions
you define (Lie, xdef...) should be methods better than external functions.
In general, the use seems a bit confuding to me... i would say that it
looks
Le dimanche 7 juillet 2013 10:39:30 UTC+2, vdelecroix a écrit :
Cool! It looks nice. How do you intend to define a manifold: numerically
(via fine triangulations) or via symbolic expressions? Both?
At the moment, a manifold is mostly defined as a set of charts with the
associated
Hi,
Michal Bejger and I have started a project regarding differential geometry
in Sage.
At present, differential geometry in Sage is limited to the class
DifferentialForm created by Joris Vankerschaver. The project SageManifolds
extends it in at least two directions:
- general tensors (and not
Le mercredi 3 juillet 2013 01:07:35 UTC+2, rjf a écrit :
Your statement then translates to RPBSRPN(x^2) = abs(x) .
But then if it ir R+--R+, the abs() is unnecessary, and RPBSRPN(x^2) =
x.
No, the abs is necessary: consider the following function:
f : R -- R+, x |-- RPBSRPN(x^2)
Le mardi 2 juillet 2013 02:38:44 UTC+2, rjf a écrit :
What you've written is just a hack.
Of course it's a hack; this is why I did not submit it as a patch for Sage.
As far as one restricts oneself to the REAL DOMAIN, I think it works.
Please show me a counter-example.
Again, let me
Le vendredi 21 juin 2013 07:00:54 UTC+2, rjf a écrit :
Yes, I wrote radcan. The full source of it is available. I think it is in
file rat3e.lisp. Look for
(defun $radcan
or perhaps (defmfun $radcan
I think that if you wish to modify it to make a function with another
name, you will
into account ?
Eric.
Le mercredi 19 juin 2013 13:38:18 UTC+2, Michael Orlitzky a écrit :
On 06/19/2013 03:03 AM, Eric Gourgoulhon wrote:
Thanks for your explanation regarding how radcan works.
If radcan ignores assumptions, how can one explain the following
behavior:
sage: assume(x0
Thanks for your explanation regarding how radcan works.
If radcan ignores assumptions, how can one explain the following behavior:
sage: assume(x0)
sage: sqrt(x^2).simplify_radical()
x
sage: maxima_calculus.eval('domain:real')
'real'
sage: sqrt(x^2).simplify_radical()
-x
It seems that assuming
doesn't say much.
e.g. even sqrt(9) is +-3.
who cares about the sign of 9.
In some engineering and physical circumstances, a branch of the sqrt
can be intuited. But the math issue is not resolved by assume(x0) etc
On Saturday, June 15, 2013 8:31:02 AM UTC-7, Eric Gourgoulhon wrote:
Hi
Hi,
Here is some behavior of Sage which can be quite disturbing for a new user
and probably would be considered as a bug:
sage: assume(x0)
sage: sqrt(x^2).simplify_full()
x
It appears that the instruction assume(x0) is not sufficient to enforce
the desired behavior: x is still considered as a
I confirm this behavior on a fresh install of version 5.9 from the sources:
sage -clone triggers the recompilation of the Cython sources. In version
5.8, it did not. Don't know the reason for this...
Eric.
Le vendredi 10 mai 2013 14:53:27 UTC+2, vdelecroix a écrit :
Hi,
It seems that the
Thanks for having set up a ticket for this.
On Wednesday, April 3, 2013 7:16:31 AM UTC+2, Nils Bruin wrote:
I guess someone should fix this at some point:
http://trac.sagemath.org/sage_trac/ticket/14403
--
You received this message because you are subscribed to the Google Groups
Hello,
I've noticed this strange behavior (bug ?) on the following elementary
computation:
sage: a = matrix([[sqrt(x),0,0,0], [0, 1, 0, 0], [0, 0, 1, 0], [0, 0, 0,
1]])
sage: det(a)
...
TypeError: no conversion of this rational to integer
If the matrix is smaller, it is fine:
sage: a =
Hi,
In Sage, the reflected division operator, __rdiv__, seems not to behave as
the other reflected operators, __radd__, __rsub__ and __rmul__: it
generates an error in the following example: consider the simple class:
class A(SageObject):
def __init__(self, x):
self.x = x
.
What could be the reason of this difference of behaviour with respect to
__radd__, __rsub__ and __rmul__ ?
Thank you for your help.
Eric.
Le lundi 4 mars 2013 16:29:28 UTC+1, Eric Gourgoulhon a écrit :
Hi,
In Sage, the reflected division operator, __rdiv__, seems not to behave
Hi,
I had the same problem with Sage 5.4 on Mandriva 2010.1. As explained in
the post
https://groups.google.com/d/topic/sage-devel/7BpVcXiN9Cg/discussion, the
problem arises from the function time.
A workaround is to edit the file
$SAGE_ROOT/spkg/bin/sage
and to suppress the time command in
601 - 627 of 627 matches
Mail list logo
