Hi Willem Jan, Ronald,
I'm putting this on my todo list. About half a year ago I did some
work adding doctests and fixing/reorganising things with scheme
morphisms, but I didn't get a chance to finish. I'll try to have a
look at your patch soon.
And: thanks for working on this!
Best,
Alex
Jason Grout wrote:
> Dr. David Kirkby wrote:
>> 1) N/A - Not an upstream bug
>> 2) Not yet reported upstream; Will do shortly.
>> 3) Reported upstream. Little or no feedback.
>> 4) Reported upstream. Developers acknowledge bug.
>> 5) Reported upstream. Developers deny it's a bug.
>> 6) Fixed upstr
On Wed, Nov 4, 2009 at 2:43 PM, William Stein wrote:
> sage: Integers(7)(3) in ZZ
> True
I found this one funny:
sage: a = Integers(7)(3)
sage: a in ZZ
True
sage: a in QQ
False
In the same vein:
sage: b = Integers(11)(3)
sage: a in ZZ
True
sage: b in ZZ
True
sage: a + b
Dr. David Kirkby wrote:
> That would give up 9 options. I think there might always be something which
> does
> not fall into a nice category, so perhaps a 10th 'catch all' is needed too.
>
> 1) N/A - Not an upstream bug
> 2) Not yet reported upstream; Will do shortly.
> 3) Reported upstream. L
Dr. David Kirkby wrote:
>
> 1) N/A - Not an upstream bug
> 2) Not yet reported upstream; Will do shortly.
> 3) Reported upstream. Little or no feedback.
> 4) Reported upstream. Developers acknowledge bug.
> 5) Reported upstream. Developers deny it's a bug.
> 6) Fixed upstream, in a later stable r
>
> If one finds a workaround for a bug, IMHO one has a moral duty to let the
> upstream developer know of the bug. Tell them you have found a workaround, but
> it should still be reported upstream. So perhaps a
>
> * Workaround found; Bug reported upstream
>
> would be useful.
Yes, of course -
kcrisman wrote:
>
>
> On Nov 4, 2:22 pm, "ma...@mendelu.cz" wrote:
>>> We might also have an option for "fixed in our version", as many times
>>> we will patch an spkg and simultaneously report it upstream. When we
>>> eventually get the upstream fix in an update, we delete our patch.
>> In ot
Hi all,
Ronald van Luijk encountered the following problem:
sage: S. = QQ[]
sage: A1. = AffineSpace(QQ,1)
sage: A1_emb = Curve(p-2)
sage: type(A1_emb)
sage: g = A1.hom([2,r],A1_emb)
TypeError: _point_morphism_class() takes exactly 1 non-keyword argument (3
given)
We browsed through the scheme
Hi all,
I just tried the solution of removing MPIR and ATLAS and recompiling Sage
and took about 27 minutes
in my Pentium D 3.4 GHz, 3 GB RAM.
I wonder if it makes sense to apply this solution every time the LiveCD
runs, for older computers or alike in
order to make them run Sage without the "Il
Thanks a lot William, that solved it.
Greetings,
Lucio
On Wed, Nov 4, 2009 at 4:56 PM, William Stein wrote:
>
> On Wed, Nov 4, 2009 at 10:51 AM, Lucio Lastra
> wrote:
> > Hi all,
> >
> > I was trying to fix the Illegal instruction error as described here:
> >
> > http://wiki.sagemath.org/faq#
On Nov 4, 2:22 pm, "ma...@mendelu.cz" wrote:
> > We might also have an option for "fixed in our version", as many times
> > we will patch an spkg and simultaneously report it upstream. When we
> > eventually get the upstream fix in an update, we delete our patch.
>
> In other words, is this pr
Jason Grout wrote:
> Dr. David Kirkby wrote:
>> It's clear that Sage, unlike most other projects, makes extensive use of
>> software not written by Sage developers. As such, when bugs are found in
>> that
>> software, they should ideally be reported upstream.
>>
>> I would suggest a pull-down o
> We might also have an option for "fixed in our version", as many times
> we will patch an spkg and simultaneously report it upstream. When we
> eventually get the upstream fix in an update, we delete our patch.
>
In other words, is this preferred way to fix broken Maxima commands?
1. Fix in m
Is the goal to produce portable i686 packages or portable i686
packages that use extended vector instructions on machines that
support them? Shouldn't packages built without using those
instructions work on all i686 compat architectures?
On Nov 4, 10:38 am, William Stein wrote:
> On Wed, Nov 4,
On 2009-Nov-04 01:28:45 +, "Dr. David Kirkby"
wrote:
>William said the other day the way around this is to build the OpenSSL
>libraries
>first. Then I looked and see that the OpenSSL libraries were at one time
>included in Sage, but were removed since they are not GPL. This was done in
>t
On Nov 4, 10:38 am, William Stein wrote:
> It would be really, really awesome in anybody could figure out how to
> produce i686 binaries that work on all machines. Nobody has ever
> done so successfully. The only two packages in the Sage that cause
> problems are MPIR (fork of GMP) and ATLAS
On Wed, Nov 4, 2009 at 10:51 AM, Lucio Lastra wrote:
> Hi all,
>
> I was trying to fix the Illegal instruction error as described here:
>
> http://wiki.sagemath.org/faq#Otherquestions
>
> typing:
>
> rm spkg/installed/mpir* spkg/installed/atlas*
> make
>
> but got an error and attached the log.
>
On Wed, Nov 4, 2009 at 10:22 AM, Eric Drechsel wrote:
>
> So regarding a sage personal package archive, I see another advantage
> that has perhaps been discussed elsewhere: over time, dependencies
> could be moved from a monolithic package -> a dependent package in the
> PPA, likely just a versio
So regarding a sage personal package archive, I see another advantage
that has perhaps been discussed elsewhere: over time, dependencies
could be moved from a monolithic package -> a dependent package in the
PPA, likely just a version bump of the official Ubuntu package ->
eliminated from the PPA
Perfect, since the instructions to build a LiveCD from scratch from
Karmic don't work right yet. There have been some changes in Grub
and squashfs among others.
So I can keep with my script still, since now I'll release each time Sage
comes out (i.e 4.2.1 etc) and not just in major releases. Hopef
Dr. David Kirkby wrote:
> It's clear that Sage, unlike most other projects, makes extensive use of
> software not written by Sage developers. As such, when bugs are found in that
> software, they should ideally be reported upstream.
>
> I would suggest a pull-down on the track where one could s
On Wed, Nov 4, 2009 at 8:35 AM, Vincent D <20100.delecr...@gmail.com> wrote:
>
> I understand now (and agree on) the design: sqrt(2) is symbolic and
> any sage expression containing a symbolic expression is also symbolic.
> But, considering the non comparison, it seems to give a set theoritic
> co
I understand now (and agree on) the design: sqrt(2) is symbolic and
any sage expression containing a symbolic expression is also symbolic.
But, considering the non comparison, it seems to give a set theoritic
contradiction:
sage: sqrt(2) in RR
True
And RR is an ordered field.
I think it goes in
On Wed, Nov 4, 2009 at 7:10 AM, Lucio Lastra wrote:
> Hi all,
>
> Is there any difference if the Sage 4.2 Karmic release runs on Ubuntu
> Jaunty?
>
> I mean, do certain features fail or something alike or everything should run
> fine as always?
Sage should work perfectly on both 9.04 and 9.10.
+1 from me. This will be useful to give back to upstream.
- Tim Joseph Dumol
On Wed, Nov 4, 2009 at 9:39 PM, Dr. David Kirkby wrote:
>
> Peter Jeremy wrote:
> > On 2009-Nov-02 13:35:05 +, "Dr. David Kirkby" <
> david.kir...@onetel.net> wrote:
> >> I would suggest a pull-down on the track w
On Nov 3, 7:55 pm, Nils Bruin wrote:
> It is just a separate python module, not explicitly placed in the sage
> tree. It depends on two tickets that are ready for review. Kcrisman
> has already looked at them, but they could use some attention from
> someone familiar with lisp.
> http://trac.sage
Hi all,
Is there any difference if the Sage 4.2 Karmic release runs on Ubuntu
Jaunty?
I mean, do certain features fail or something alike or everything should run
fine as always?
Greetings,
Lucio
--~--~-~--~~~---~--~~
To post to this group, send an email to sage
Peter Jeremy wrote:
> On 2009-Nov-02 13:35:05 +, "Dr. David Kirkby"
> wrote:
>> I would suggest a pull-down on the track where one could select from
>>
>> 1) N/A - Not an upstream bug.
>> 2) Not yet reported upstream, but should be.
>> 3) Reported upstream.
>> 4) Fixed upstream
>
> Sounds g
I think this is a good idea too. It would help William and others compile
statistics about how Sage is helping/interacting with other projects in the open
course math software community.
On Mon, Nov 2, 2009 at 9:35 AM, Dr. David Kirkby
wrote:
>
> It's clear that Sage, unlike most other projects
> Should I expect
>
> sage: SR(1) + SR(2)
> 1 + 2
>
> just because
>
> sage: SR(x) + SR(2)
> x + 2
And why would "1 + 2" be wrong/bad or whatever?
Can you give a suggestion what I must input to sage to exacly get an
expression 1+2 in sage, i.e. an expression tree
+
/ \
1 2
?
It all
30 matches
Mail list logo
