On Mon, Aug 17, 2009 at 5:31 AM, William Stein wrote:
>
> On Mon, Aug 17, 2009 at 3:20 AM, Ondrej Certik wrote:
>>
>> On Mon, Aug 17, 2009 at 4:09 AM, Ondrej Certik wrote:
>>> On Mon, Aug 17, 2009 at 3:51 AM, William Stein wrote:
On Mon, Aug 17, 2009 at 2:40 AM, Ondrej Certik wrote:
Maurizio wrote:
>
> Another feature I'd LOVE to get is the conversion to "engineering"
> notation (which is similar to scientific notation), when dealing with
> quantities associated with a unit of measurement. The "engineering"
> notation as I know it, basically represents each number in scient
On Aug 17, 2:00 pm, gsw wrote:
> > 7. I have no problem with summer-of-code high school or college or ...
> > students writing programs. Relying on this code as part of the core of
> > a system is however not such a great plan.
>
> > RJF
>
> I allowed myself to answer to this point ("7.") on sa
Hello sage-devel,
I feel a bit guilty asking this after having assigned reviews to
people (the response has been great btw, thanks!), but I realise that
my Sage development education has a significant flaw: I don't know the
proper way to review an spkg.
There is good documentation in the develop
On Tue, Aug 11, 2009 at 03:29:29PM -0700, William Stein wrote:
>Hi,
>
>I just wanted to let people know that David Ackerman -- a UW student who
>took my course on Sage last quarter -- is working (funded by NSF) on
>creating a "units package" for Sage right _now_. If anybody has a
Whilst working through issues with porting Sage to FreeBSD, I've run
into a lack of complex trig/exponential functions - which Sage
(specifically sage-x.x.x/sage/ext/interpreters/wrapper_cdf.pyx)
expects.
BTW, how is wrapper_cdf.pyx generated? There's an 'auto-generated'
header but I can't find a
> 7. I have no problem with summer-of-code high school or college or ...
> students writing programs. Relying on this code as part of the core of
> a system is however not such a great plan.
>
> RJF
I allowed myself to answer to this point ("7.") on sage-flame.
Cheers,
Georg
--~--~-~--
Hi all,
I just wanted to add that I wrote a wiki page some time ago about this
topic:
http://wiki.sagemath.org/Unit%20of%20Measurement
It was mainly about previously existing packages, but I still think
there are some valuable information there.
My other comment is that, my ideal units package
Hi,
On Wed, Aug 5, 2009 at 7:25 AM, Burcin Erocal wrote:
> IIRC, you wrote that your implementation can coexist with the current
> one in Sage. Why don't you submit your changes so people can try out
> both approaches?
Here goes the patches for Sage-4.1.1. I am seeking review from both
pynac an
I have now put the most recent version of my code online. It would be
great if people could look it over and tell me whether they think it
could be an official Sage package, or what changes I'd need to
implement to get it there.
The code is at http://www.inference.phy.cam.ac.uk/dimpy/dimpy-0.2.1.
People discussing the merits of languages based on statistical
popularity should note how many newspapers publish astrology columns.
The language shootouts are not entirely relevant, since the question
here has to do with suitability of a language for implementation of
a computer algebra framewor
Biopython 1.51 has been released, and I have a spkg up at
http://sage.math.washington.edu/home/mhampton/biopython-1.51.spkg
which I also posted on the ticket:
http://trac.sagemath.org/sage_trac/ticket/6634
Since the biopython-1.51b spkg never got reviewed, and biopython-1.49b
is broken, it wou
Hi
I've obsoleted then MPIR function
int mpz_probab_prime_p (mpz_t N, int REPS)
The reasons for this are mainly that the random state used in the above
algorithm is reset on every function call. So two consecutive calls to this
function are NOT independent. The other reason is that the parame
rjf wrote:
> Well, I don't know about there being no "decent compiler"; Sage has
> not
> chosen Lisps based on technical merit, and may have encountered ones
> without decent compilers.
>
>> It would be a much more productive use of time to implement macros in
>> Python. Of course that is being
Yes, we test MPIR with the Sun compiler, however fat binary support
may not work.
Bill.
On 17 Aug, 13:05, "Dr. David Kirkby" wrote:
> Dr. David Kirkby wrote:
> > I've no idea why givaro should find gmp when it was build with the GNU
> > compiler, but not the GNU one. (Actually, it is mpir used
Dr. David Kirkby wrote:
> I've no idea why givaro should find gmp when it was build with the GNU
> compiler, but not the GNU one. (Actually, it is mpir used in Sage, not
> GMP.)
I mean to say I don't know why this find the gmp library when gmp and
givaro are build with the GNU compiler, but n
Probably the only problem is this, in flint.h
#if defined(__GNUC__)
#if FLINT_BITS == 64
#define count_lead_zeros(a,b) \
a = __builtin_clzll(b);
#define count_trail_zeros(a,b) \
a = __builtin_ctzll(b);
#else
#define count_lead_zeros(a,b) \
a = __builtin_clzl(b);
#define count_trail_zeros
Bill Hart wrote:
> The FLINT svn is not set up to use eolnative, and this is unlikely to
> change. And I edit using Windows exclusively.
>
> I could add dos2unix to my list of things to do for a FLINT release.
That would be good. It is a bit annoying if the Sun compiler is used. I
realise later
Hi,
I just tried to build 'Sage' with the Sun compiler. A few packages will
not build, one of which is givaro-3.2.13rc2
It fails with:
checking for GMP >= 3.1.1... not found
***
ERROR: GMP not found!
GMP version
On Mon, Aug 17, 2009 at 3:20 AM, Ondrej Certik wrote:
>
> On Mon, Aug 17, 2009 at 4:09 AM, Ondrej Certik wrote:
>> On Mon, Aug 17, 2009 at 3:51 AM, William Stein wrote:
>>>
>>> On Mon, Aug 17, 2009 at 2:40 AM, Ondrej Certik wrote:
On Mon, Aug 17, 2009 at 2:26 AM, William Stein wrote:
>>>
This is an ID10T error. The following assertion from the bug report is
false:
> The prime 83 splits as PQ, where
> P, Q have N(P)=83^5.
sage: [P.residue_class_degree() for P in M.primes_above(83)]
[1, 1, 1, 1, 1, 1, 1, 1, 1, 1]
So the output is correct.
David
On Aug 17, 10:41 am, Harald Schi
On Mon, Aug 17, 2009 at 3:37 AM, Juan Jose
Garcia-Ripoll wrote:
>
> On Mon, Aug 17, 2009 at 12:20 PM, Bill Hart
> wrote:
>> So it seems Lisp is actually a bit mpz_add heavy. I'd write to the
>> authors and complain about that.
>
> Sorry to sound rude, but I am afraid you have no idea what you are
On Mon, Aug 17, 2009 at 12:20 PM, Bill Hart wrote:
> So it seems Lisp is actually a bit mpz_add heavy. I'd write to the
> authors and complain about that.
Sorry to sound rude, but I am afraid you have no idea what you are
talking about. Common Lisp does not support destructive operations on
integ
The FLINT svn is not set up to use eolnative, and this is unlikely to
change. And I edit using Windows exclusively.
I could add dos2unix to my list of things to do for a FLINT release.
This is certainly not at all a problem with zn_poly by the way. I'm
pretty sure most of the FLINT files will ha
Hmm, wait a minute, there is a good chance there's a lot of duplicate
files there, due to HG or something. Perhaps there's only 300K of
python and cython lines of code.
So maybe 111 occurrences is actually a bit high based on this (silly) metric.
Bill.
2009/8/17 Bill Hart :
> Well ECL uses mpz_
Well ECL uses mpz_add 11 times in 73783 lines of Lisp code *not*
including system header files, which I removed, compared to 111
occurrences in Sage's 1.66M lines of Python code (to be honest I am
not sure if it counted the Cython files or not, but what's another
300K lines between friends). Now
On Mon, Aug 17, 2009 at 4:09 AM, Ondrej Certik wrote:
> On Mon, Aug 17, 2009 at 3:51 AM, William Stein wrote:
>>
>> On Mon, Aug 17, 2009 at 2:40 AM, Ondrej Certik wrote:
>>>
>>> On Mon, Aug 17, 2009 at 2:26 AM, William Stein wrote:
On Mon, Aug 17, 2009 at 1:14 AM, Ondrej Certik wrote:
>>
On Mon, Aug 17, 2009 at 3:51 AM, William Stein wrote:
>
> On Mon, Aug 17, 2009 at 2:40 AM, Ondrej Certik wrote:
>>
>> On Mon, Aug 17, 2009 at 2:26 AM, William Stein wrote:
>>>
>>> On Mon, Aug 17, 2009 at 1:14 AM, Ondrej Certik wrote:
Hi,
at the scipy 09 conference I am going to
On Mon, Aug 17, 2009 at 6:29 AM, Harald Schilly wrote:
>
> From the notebook's "report a problem" bugtracker:
>
> The conversion of a sage expression to maxima depends of the argument
> order of previous defined functions. For example:
>
> var('x y t')
> L=function('L', t, x, y)
> m1=maxima(diff(L
On Mon, Aug 17, 2009 at 2:40 AM, Ondrej Certik wrote:
>
> On Mon, Aug 17, 2009 at 2:26 AM, William Stein wrote:
>>
>> On Mon, Aug 17, 2009 at 1:14 AM, Ondrej Certik wrote:
>>>
>>> Hi,
>>>
>>> at the scipy 09 conference I am going to compare Sage and sympy
>>> approaches to factoring (and timings)
I'm trying to build flint with the Sun compiler, but it gives numerous
warnings like this:
"zn_poly/src/zn_poly_internal.h", line 35: warning: invalid white space
character in directive
"zn_poly/src/zn_poly_internal.h", line 36: warning: invalid white space
character in directive
Looking at
>From the notebook's report a problem bugtracker:
Problem Computing Artin Symbol
problem description
The command artin_symbol(P) doesn't compute the Artin Symbol in a
specific case. Below is the code. The prime 83 splits as PQ, where
P, Q have N(P)=83^5. There is an Artin symbol
On Mon, Aug 17, 2009 at 2:26 AM, William Stein wrote:
>
> On Mon, Aug 17, 2009 at 1:14 AM, Ondrej Certik wrote:
>>
>> Hi,
>>
>> at the scipy 09 conference I am going to compare Sage and sympy
>> approaches to factoring (and timings) and longer term approaches, so I
>> have a few questions about it
On Mon, Aug 17, 2009 at 11:28 AM, William Stein wrote:
>> Ah, that makes sense. It never occurred to me to check if any of the
>> lisp implementations actually used GMP or MPIR. Now I just recalled
>> that you recently encouraged ECL to switch from GMP to MPIR. Did they
>> do so? I recall PHP did
Another one from the notebook's report a problem bugtracker about ODEs:
assume(n, 'integer') causes desolve to fail
Here is the code that fails :
var('t n')
assume(n, 'integer')
f = function('f',t)
ode = diff(f,t) + (-1)^n*f == 0
desolve(ode, f, [0,1], t)
It should do the same as :
var('t n')
>From the notebook's "report a problem" bugtracker:
The conversion of a sage expression to maxima depends of the argument
order of previous defined functions. For example:
var('x y t')
L=function('L', t, x, y)
m1=maxima(diff(L,t))
L=function('L', x, y, t)
m2=maxima(diff(L,t))
m2 delivers the wro
On Mon, Aug 17, 2009 at 2:10 AM, Bill Hart wrote:
>
> 2009/8/17 William Stein :
>>
>> On Mon, Aug 17, 2009 at 1:17 AM, Bill Hart
>> wrote:
>>> Actually Python is often vastly slower than Lisp. It is very rarely
>>> faster. The point of python is most certainly not its speed. It is
>>> ease of use
2009/8/17 William Stein :
>
> On Mon, Aug 17, 2009 at 1:17 AM, Bill Hart wrote:
>> Actually Python is often vastly slower than Lisp. It is very rarely
>> faster. The point of python is most certainly not its speed. It is
>> ease of use, through and through. The whole language was designed with
>>
On Mon, 17 Aug 2009, John Cremona wrote:
> 2009/8/17 Dr. David Kirkby :
> > I'm trying to work out exactly how the makefiles in ntl are generated,
> > The flags to add shared library support are gcc specific. I'd like to
> > try to make them configurable, so they can work with other compilers,
> >
On Mon, Aug 17, 2009 at 1:17 AM, Bill Hart wrote:
> Actually Python is often vastly slower than Lisp. It is very rarely
> faster. The point of python is most certainly not its speed. It is
> ease of use, through and through. The whole language was designed with
> that in mind.
>
> Of course the sp
On Mon, Aug 17, 2009 at 1:14 AM, Ondrej Certik wrote:
>
> Hi,
>
> at the scipy 09 conference I am going to compare Sage and sympy
> approaches to factoring (and timings) and longer term approaches, so I
> have a few questions about it, so that I understand things correctly.
> If I do:
>
> sage: va
-- Forwarded message --
From: Jason Moxham
Date: 2009/8/17
Subject: [mpir-devel] mpz_nextprime
To: mpir-de...@googlegroups.com
I've obsoleted the function
void mpz_nextprime(mpz_t ROP ,mpz_t OP)
so any code using this function should be converted to use the new function if
y
2009/8/17 Dr. David Kirkby :
>
> I'm trying to work out exactly how the makefiles in ntl are generated,
> The flags to add shared library support are gcc specific. I'd like to
> try to make them configurable, so they can work with other compilers,
> but I'm having a struggle with this.
>
> Trying
2009/8/17 William Stein :
>
> On Sun, Aug 16, 2009 at 10:54 PM, rjf wrote:
>>> > I agree with you entirely, which is why I asked about the 5000 lines
>>> > with mpz.
>>> > One possible answer is, "#...@#$%$, Python doesn't have macros."
>
> That is not why the Sage library uses the GMP C library i
Hi,
at the scipy 09 conference I am going to compare Sage and sympy
approaches to factoring (and timings) and longer term approaches, so I
have a few questions about it, so that I understand things correctly.
If I do:
sage: var("x y z")
(x, y, z)
sage: a = (x+y+z)**20
sage: b = a.expand()
sage:
On Sat, Aug 15, 2009 at 9:57 PM, Fredrik
Johansson wrote:
> On Sat, Aug 15, 2009 at 4:40 PM, Minh Nguyen wrote:
>>
>> Hi folks,
>>
>> I noticed the following thread from the Maxima mailing list.
>>
>> --
>> Regards
>> Minh Van Nguyen
>>
>>
>> -- Forwarded message --
>> From: Richar
On Sun, Aug 16, 2009 at 11:18 PM, rjf wrote:
>> Look, I agree that it would be a nice language feature. Even the C++
>> preprocessor doesn't have enough macro expansion for my liking, and C+
>> + is one of the languages used in Sage. This is definitely a nice
>> feature in Lisp. But it isn't going
I'm trying to work out exactly how the makefiles in ntl are generated,
The flags to add shared library support are gcc specific. I'd like to
try to make them configurable, so they can work with other compilers,
but I'm having a struggle with this.
Trying to work out the interaction of makefile
On Sun, Aug 16, 2009 at 10:54 PM, rjf wrote:
>> > I agree with you entirely, which is why I asked about the 5000 lines
>> > with mpz.
>> > One possible answer is, "#...@#$%$, Python doesn't have macros."
That is not why the Sage library uses the GMP C library interface in
some places. The Sage l
49 matches
Mail list logo
