On Mar 31, 2016, at 12:33 , William Stein wrote:
> On Thu, Mar 31, 2016 at 12:31 PM, Justin C. Walker wrote:
>> Dear Sage Support:
>>
>> Just checking, but this seems wrong:
>>
>> sage: R12=Integers(12)
>> sage: Spec12=Spec(R12)
>> sage: Spec12.an_element()
>> Point on
On Thu, Mar 31, 2016 at 12:31 PM, Justin C. Walker wrote:
> Dear Sage Support:
>
> Just checking, but this seems wrong:
>
> sage: R12=Integers(12)
> sage: Spec12=Spec(R12)
> sage: Spec12.an_element()
> Point on Spectrum of Ring of integers modulo 12 defined by the Principal
>
Dear Sage Support:
Just checking, but this seems wrong:
sage: R12=Integers(12)
sage: Spec12=Spec(R12)
sage: Spec12.an_element()
Point on Spectrum of Ring of integers modulo 12 defined by the Principal ideal
(0) of Ring of integers modulo 12
Checking the code (schemes/generic/scheme.py), if the
On Mar 31, 2016, at 10:36 , Jacques Tramu wrote:
> Hi, after installation of Sage-6.9 which did not work (unknow signal at
> startup), I installed
> Sage 7-1. osX-10-11.3-x86-64
> IT aborts with the following message :
>
>
> Last login: Thu Mar 31 19:20:44 on ttys000
> -bash: PS1: command
Do you have SAGE_ROOT set permanently
to Users/echolalie/Desktop/Sage-6.9.app for some reason? E.g. ~/.bashrc
~/.bash_profile, ...,
Also, the "-bash: PS1: command not found" is suspicious. Not a Sage
problem, but most likely an issue with your init files. What is $PS1?
On Thursday, March
Hi, after installation of Sage-6.9 which did not work (unknow signal at
startup), I installed
Sage 7-1. osX-10-11.3-x86-64
IT aborts with the following message :
Last login: Thu Mar 31 19:20:44 on ttys000
-bash: PS1: command not found
sagemanifolds compiles well usually... Just follow the install doc and
sm-install.sh :
http://sagemanifolds.obspm.fr/download.html#script_install/sm-install.sh
I prefer than git.
Le 31/03/2016 19:00, Oscar Alberto Castillo Felisola a écrit :
Hi Eric,
I finally compiled the source of sage
Hi Eric,
I finally compiled the source of sage from github, but I got a merge
conflict when I added the sagemanifolds branch. I'll post further when I
get to the office. Hope you could help me.
Cheers.
On Tuesday, 29 March 2016 15:51:53 UTC-3, Eric Gourgoulhon wrote:
>
> Hi Oscar,
>
> I'm
Hi Volker,
I discover that a git repository hosted at github. I was able to compile
the source from that repository, which is by the way more updated that the
repository advertised at the documentation.
Nonetheless, I'm still having problems when trying to compile the
sagemanifolds branch...
Jeroen Demeyer wrote:
> I don't get what you mean. What I am saying is that the following two
> should return the same answer:
>
> p.mod([q])
> p.quo_rem(q)[1]
I was mixing up several things, sorry. Yes, that makes sense. I guess
quo_rem() for multivariate polynomials must predate the
On 2016-03-31 11:06, Marc Mezzarobba wrote:
Jeroen Demeyer wrote:
Is there any reason that quo_rem is not consistent with .mod()? That
is no longer arbitrary and would also extend the Euclidean division of
univariate polynomials.
Not quite: you'd have to return a tuple of quotients.
I don't
Jeroen Demeyer wrote:
> Is there any reason that quo_rem is not consistent with .mod()? That
> is no longer arbitrary and would also extend the Euclidean division of
> univariate polynomials.
Not quite: you'd have to return a tuple of quotients.
--
Marc Mezzarobba
--
You received this message
Hi Saad,
On 2016-03-31, saad khalid wrote:
> Oh wow... so there's a possibility that the calculation might take million
> of years for what I'm trying to do? Or there some easy way to approximate
> how long it will take based off of how many variables I have? Thank you!
On 2016-03-30 16:08, Marc Mezzarobba wrote:
I think it is just a more or less arbitrary function that satisfies
quo*q + rem == p and extends the Euclidean division of univariate
polynomials. (But // can still be useful for exact divisions or
divisions by monomials...)
Is there any reason that
14 matches
Mail list logo