Recently I made a patch to improve the handling of colormap, which has
been merged in 3.3 (http://trac.sagemath.org/sage_trac/ticket/4884)
There was some discussion on the ticket (read the comments) which may
have confused everybody.
I proposed adding a function to the global namespace called
cm
Whoops, you didn't mention assembly language. I think I got that mixed
up with another conversation.
On 23 Jan, 22:48, Bill Hart wrote:
> Somehow I screwed up and put the wrong times for the Opteron for giac.
> Here are all the 1-d times again:
>
> FLINT (2.4Ghz Opteron):
>
> 1d: 0.00018s, 0.005
Here are the times for the other GCD's on Magma on the Opteron 2.4Ghz:
2D:
0.00089s
0.00374s
0.0256s
0.08549s
3D:
0.00185s
0.0069s
0.05491s
4D:
0.006s
0.028s
0.071s
I don't have giac times on the Opteron to compare. It would be
interesting to see the times.
Bill.
On 23 Jan, 22:48, Bill Ha
On Fri, Jan 23, 2009 at 1:03 PM, Robert Bradshaw
wrote:
>
> On Jan 23, 2009, at 12:41 PM, William Stein wrote:
>
>> On Fri, Jan 23, 2009 at 9:24 AM, Martin Albrecht
>> wrote:
>>> On Friday 23 January 2009, you wrote:
Hi Martin,
I don't like the hash doctest changes you introduced
On Jan 23, 2:58 pm, Jaap Spies wrote:
Hi Jaap,
> Alex Ghitza wrote:
> > Upgrading from sage-3.3.alpha0 went smoothly and passed all tests except the
> > known toy_d_basis.py, on:
>
> Same here on Fedora 9, Fedora 10 and Ubuntu 8.10 32 bits.
Good. Was that an update or a build from scratch?
On Jan 23, 1:51 pm, John Cremona wrote:
Hi John,
> I tried sage-upgarde from a successful build from source of
> 3.3.alpha0. Seemed to work ok but the banner and version() still say
> 3.3.alpha0. Same after applying the suggested fix
> athttp://wiki.sagemath.org/faq.
>
> I don't mind the b
On Jan 23, 1:03 pm, Robert Bradshaw
wrote:
> On Jan 23, 2009, at 12:41 PM, William Stein wrote:
> > I think we are both wrong. Doctesting of __hash__ should be done by
> > a function:
>
> > sage: test.hash(GF(3^4, 'a'))
> > 'ok' # or not raise exception
>
> > The advantages of doing thi
Alex Ghitza wrote:
> Upgrading from sage-3.3.alpha0 went smoothly and passed all tests except the
> known toy_d_basis.py, on:
>
Same here on Fedora 9, Fedora 10 and Ubuntu 8.10 32 bits.
Jaap
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@g
All tests pass on my Opteron 64-bit RHEL5 box.
Kiran
On Jan 23, 1:55 pm, mabshoff wrote:
> On Jan 23, 10:11 am, Nick Alexander wrote:
>
> Hi,
>
> > This credit is incorrect. The patch was reviewed by Martin Albrecht.
>
> > #2789: Nick Alexander: multivariate polynomials over residue fields of
We ripped the longlong.h out of GMP which has assembly code for this
sort of thing. We use precomputed inverses for the modular reduction.
On 23 Jan, 19:01, parisse wrote:
> > No, in my case the maximum modulus is 2^63 for now on a 64 bit
> > machine.
>
> How do you make multiplication followed
Somehow I screwed up and put the wrong times for the Opteron for giac.
Here are all the 1-d times again:
FLINT (2.4Ghz Opteron):
1d: 0.00018s, 0.0055s, 0.021s
mod-1d: 0.00046s, 0.00419s, 0.00979
Magma (2.4Ghz Opteron):
1d: 0.00168s, 0.01692s and 0.0453s
mod-1d: 0.00067s, 0.00981s, 0.0244s
Gia
I tried sage-upgarde from a successful build from source of
3.3.alpha0. Seemed to work ok but the banner and version() still say
3.3.alpha0. Same after applying the suggested fix at
http://wiki.sagemath.org/faq.
I don't mind the banner being wrong as this is only a test build, but
how do I know
Is this C++? If so, one needs a language="c++" in the Extension line.
At this point I might see if you can write a simple C program that
can call your cdd library which will expose wether or not the issue
is with Cython/distutils or the cdd library you're using.
- Robert
On Jan 23, 2009,
On Jan 23, 2009, at 12:41 PM, William Stein wrote:
> On Fri, Jan 23, 2009 at 9:24 AM, Martin Albrecht
> wrote:
>> On Friday 23 January 2009, you wrote:
>>> Hi Martin,
>>>
>>> I don't like the hash doctest changes you introduced in #4965.
>>> They should be
>>>
>>> sage: hash(GF(3^4),'a')
>>>
>>
On Fri, Jan 23, 2009 at 9:24 AM, Martin Albrecht
wrote:
> On Friday 23 January 2009, you wrote:
>> Hi Martin,
>>
>> I don't like the hash doctest changes you introduced in #4965.
>> They should be
>>
>> sage: hash(GF(3^4),'a')
>>
>> or
>>
>> sage: h = hash(GF(3^4),'a')
>>
>> instead of
>>
>>
Nice debate. I did not know this was there, but now that I do I think
I'll start to use it!
John
On 23 Jan, 19:13, Craig Citro wrote:
> > -1 to removing it. I've used it several times and see no reason at
> > all to remove it.
> > I use it! Actually in my first notebook. Please don't remove.
> -1 to removing it. I've used it several times and see no reason at
> all to remove it.
> I use it! Actually in my first notebook. Please don't remove.
>
Wow, ok. I had no idea people really used it -- I thought it just sat untouched.
In that case, I rescind my '+1'.
-cc
--~--~-~--
> No, in my case the maximum modulus is 2^63 for now on a 64 bit
> machine.
>
How do you make multiplication followed by modular reduction? I don't
know how to to that in C (I mean there is no quadruple long or
int128_t in gcc?)
--~--~-~--~~~---~--~~
To post to thi
On Jan 23, 10:11 am, Nick Alexander wrote:
Hi,
> This credit is incorrect. The patch was reviewed by Martin Albrecht.
>
> #2789: Nick Alexander: multivariate polynomials over residue fields of
> number fields are broken [Reviewed by Nick Alexander]
Oops, which idiot wrote that in the releas
On 23-Jan-09, at 7:33 AM, William Stein wrote:
>
> On Fri, Jan 23, 2009 at 7:26 AM, Robert Miller
> wrote:
>>
>>> I've used it several times and see no reason at
>>> all to remove it.
>>
>> Redundancy is one reason I can think of. Is there any functionality
>> you can get out of this that you
This credit is incorrect. The patch was reviewed by Martin Albrecht.
#2789: Nick Alexander: multivariate polynomials over residue fields of
number fields are broken [Reviewed by Nick Alexander]
Nick
On 23-Jan-09, at 3:00 AM, mabshoff wrote:
>
> Hello folks,
>
> here goes alpha1 with another m
Upgrading from sage-3.3.alpha0 went smoothly and passed all tests except the
known toy_d_basis.py, on:
[ghi...@artin sage]$ uname -a
Linux artin 2.6.28-ARCH #1 SMP PREEMPT Sun Jan 18 20:17:17 UTC 2009 i686
Intel(R) Core(TM)2 Duo CPU T9300 @ 2.50GHz GenuineIntel GNU/Linux
Cheers,
Alex
--
Al
On Jan 22, 6:26 pm, mhampton wrote:
...
> A python/
> cython/javascript spreadsheet for the Sage notebook would be great -
> unfortunately I'm not going to write one. I think it would be hard to
> do it right.
>
> -M. Hampton
I have heard that the major competition for Mathematica is not Mapl
On 23 Jan, 07:44, parisse wrote:
> > Your timings are surprisingly low. Can you tell me which files perform
> > the Z/pZ[x] GCD? I'd be very interested to see your code.
>
> The division code in Z/pZ is in the file modpoly.cc, lines 1621->1723.
> It depends on invmod(int,int) for modular invers
On Jan 23, 3:47 pm, Alfredo Portes wrote:
> By the way you may consider using JNA to access native libraries.
thx, didn't know about that!
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send e
I use it! Actually in my first notebook. Please don't remove.
On Jan 23, 1:43 pm, Robert Miller wrote:
> Does anyone use this module anymore? It seems, well, a little silly...
>
> sage: P = Primes()
> sage: P
> Set of all prime numbers: 2, 3, 5, 7, ...
> sage: 3 in P
> True
> sage: 4 in P
> Fals
On Fri, Jan 23, 2009 at 7:26 AM, Robert Miller wrote:
>
>> I've used it several times and see no reason at
>> all to remove it.
>
> Redundancy is one reason I can think of. Is there any functionality
> you can get out of this that you can't just get out of is_prime,
> primes, or prime_range?
If
> I've used it several times and see no reason at
> all to remove it.
Redundancy is one reason I can think of. Is there any functionality
you can get out of this that you can't just get out of is_prime,
primes, or prime_range?
--~--~-~--~~~---~--~~
To post to this
On Fri, Jan 23, 2009 at 5:37 AM, Harald Schilly
wrote:
> For everything else you should consider JNI (that's the mechanism to
> call native C code and how all basic java language features are
> implemented)
By the way you may consider using JNA to access native libraries. I
have used it to
acce
On Fri, Jan 23, 2009 at 5:46 AM, Craig Citro wrote:
>
>> Does anyone use this module anymore? It seems, well, a little silly...
>>
>> sage: P = Primes()
>
> +1 to removing this.
-1 to removing it. I've used it several times and see no reason at
all to remove it.
William
--~--~-~--~---
> Does anyone use this module anymore? It seems, well, a little silly...
>
> sage: P = Primes()
+1 to removing this.
-cc
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
sage-dev
Does anyone use this module anymore? It seems, well, a little silly...
sage: P = Primes()
sage: P
Set of all prime numbers: 2, 3, 5, 7, ...
sage: 3 in P
True
sage: 4 in P
False
sage: P.cardinality()
+Infinity
sage: for p in P:
: print p
: if p > 20: break
:
2
3
5
7
11
13
17
19
>> The example is attached as a patch against sage 3.2.3.
I forgot it, sorry.
>> As burcin pointed on IRC, this might have something to do with the
>> fact that dd_set_global_constant is mangled:
>> nm local/lib/libcdd.a | grep dd_set_global_constants
>> 0185 T _Z23dd_set_global_constantsv
>
On Fri, Jan 23, 2009 at 4:19 AM, Sebastien Barthelemy
wrote:
>
> Hello,
>
> as discussed with sleep deprived guys on IRC, I'm having trouble
> binding libcdd.a. I designed a minimalistic example that show my
> problem. It builds fine, but fails at sage startup (during import)
> with the following
Hello,
as discussed with sleep deprived guys on IRC, I'm having trouble
binding libcdd.a. I designed a minimalistic example that show my
problem. It builds fine, but fails at sage startup (during import)
with the following error:
ImportError:
/usr/local/sage/local/lib/python2.5/site-packages/sag
Hello folks,
here goes alpha1 with another massive amount of fixes. No details from
me since I need to get some sleep, but overall 113 tickets have been
fixed in 3.3 for now. Tomorrow's SD12 seesion will concentrate on
reviews, so expect another alpha in the next 24 hours. Various build
issues ar
On Jan 23, 10:09 am, ahmet alper parker wrote:
> Is there someone who has
> experience with compiling a java code to native code on an operating
> system?
the standard java virtual machine by sun already compiles java
bytecode to native machine code. this is called "hotspot" compiler and
picks t
What about the compiled java and python benchmarks? Is there someone who has
experience with compiling a java code to native code on an operating
system?
On Fri, Jan 23, 2009 at 4:26 AM, mhampton wrote:
>
>
> On Jan 22, 4:35 pm, Robert Bradshaw
> wrote:
>
> > I pity those who find themselves try
38 matches
Mail list logo
