On Thu, Sep 17, 2015 at 6:05 PM, Vincent Delecroix
<20100.delecr...@gmail.com> wrote:
>
>
> On 17/09/15 17:10, William Stein wrote:
>>
>> On Thu, Sep 17, 2015 at 1:04 PM, kcrisman wrote:
> it would be useful to revive the discussion of a
> true SageMath Foundation, separate from
On 17/09/15 17:10, William Stein wrote:
On Thu, Sep 17, 2015 at 1:04 PM, kcrisman wrote:
it would be useful to revive the discussion of a
true SageMath Foundation, separate from SMCI of course, whether
incorporated
in the US or Europe (or elsewhere), but it sounds like there wasn't
currentl
Before starting a build myself I checked your logs. It looks like for ecm the
problem was not new but only gave a warning before:
/bin/sh ../libtool --mode=compile gcc -march=corei7 -mtune=corei7-avx -g -O3
-fPIC -c -o mulredc1.lo mulredc1.s
libtool: compile: gcc -march=corei7 -mtune=corei7-a
I just updated my command-line tools and Xcode to version 7.0 (released
today, I think). When I tried to build the latest beta of Sage from
scratch, the following packages did not build:
- ecm: log file http://www.math.washington.edu/~palmieri/Sage/ecm-6.4.4.log
- gsl: log file http://www.math.w
On Thu, Sep 17, 2015 at 1:04 PM, kcrisman wrote:
>>
>> > it would be useful to revive the discussion of a
>> > true SageMath Foundation, separate from SMCI of course, whether
>> > incorporated
>> > in the US or Europe (or elsewhere), but it sounds like there wasn't
>> > currently enough interest i
>
>
> > it would be useful to revive the discussion of a
> > true SageMath Foundation, separate from SMCI of course, whether
> incorporated
> > in the US or Europe (or elsewhere), but it sounds like there wasn't
> > currently enough interest in helping with the substantial paperwork
> involve
On 2015-09-17 17:47, John Cremona wrote:
I think so: I noticed that the optional package
database_cremona_ellcurve has no dependencies file (after I pulled in
the beta7 edition of the develop branch).
Let me first explain the two kinds of dependencies that "make" supports:
there are normal de
Hey John,
> Is the non-existence of a dependencies file valid for a package with
> none? I think so: I noticed that the optional package
> database_cremona_ellcurve has no dependencies file (after I pulled in
> the beta7 edition of the develop branch). But I also tried "sage -i
> database_
On 17 September 2015 at 16:16, William Stein wrote:
> On Thu, Sep 17, 2015 at 7:48 AM, Jeroen Demeyer
> wrote:
>> Hello,
>>
>> the logic for installing packages in Sage has changed recently. Let me
>> explain what changed:
>>
>> The command "sage -i PKGNAME" now only supports new-style packages.
I'm not an expert with configuring a cluster, but I've read good things
about "Ansible". Do we have any ansible "experts" among us? I think, this
tool is a good fit because it describes "goals" and it's extensible with
custom modules (written in Python). My uneducated feeling is that we should
real
Same problem, nobody find a solution ? If yes, please can you tell me how !
Charles
Le vendredi 11 septembre 2015 04:48:25 UTC+2, François a écrit :
>
> Hum, that symbol is in libpython2.7.dylib, operator.so is not linked to
> that library.
> I am guessing it is supposed to be dlopen-ed from py
On Thu, Sep 17, 2015 at 7:48 AM, Jeroen Demeyer wrote:
> Hello,
>
> the logic for installing packages in Sage has changed recently. Let me
> explain what changed:
>
> The command "sage -i PKGNAME" now only supports new-style packages. The
> PKGNAME should be a bare package name (no version numbers
On Thu, Sep 17, 2015 at 8:00 AM, Nils Bruin wrote:
> On Thursday, September 17, 2015 at 2:54:15 AM UTC-7, Simon King wrote:
>>
>> The real problem here is that *conversion* gives rise to an error
>> that mentions *coercion*.
>>
>> sage: K. = GF(25)
>> sage: L. = GF(25)
>> sage: K(y)
>> Tra
On Thursday, September 17, 2015 at 2:54:15 AM UTC-7, Simon King wrote:
>
> The real problem here is that *conversion* gives rise to an error
> that mentions *coercion*.
>
> sage: K. = GF(25)
> sage: L. = GF(25)
> sage: K(y)
> Traceback (most recent call last):
> ...
> TypeError:
On Thu, Sep 17, 2015 at 2:53 AM, Simon King wrote:
> Hi!
>
> On 2015-09-17, Jeroen Demeyer wrote:
>> On 2015-09-16 16:43, Jean-Pierre Flori wrote:
>>> Hi,
>>>
>>> I guess one of the issue is that there is no canonical map between two
>>> different representations of the same finite field (so no c
Equals is not transitive in Sage. Addition (of floating point
numbers) is not commutative either. And many, many other things that
are different from our perfect abstractions when you try to model
infinite objects in a finite machine. I definitely do not consider
this a bug:
sage: K1 = GF(8,'x
Hello,
the logic for installing packages in Sage has changed recently. Let me
explain what changed:
The command "sage -i PKGNAME" now only supports new-style packages. The
PKGNAME should be a bare package name (no version numbers or URLs or
whatever).
Packages are now installed *with* depe
On Thu, Sep 17, 2015 at 7:34 AM, kcrisman wrote:
>>
>> What the hell. You too? It's even worse than I thought, basically
>> everybody here has had a share of ODK's money and is thankful for it.
>>
>
> Ahem - definitely not getting ODK money here :) nor are probably 95% (?) of
> Sage developers. B
>
>
> What the hell. You too? It's even worse than I thought, basically
> everybody here has had a share of ODK's money and is thankful for it.
>
>
Ahem - definitely not getting ODK money here :) nor are probably 95% (?) of
Sage developers. But given that there seem to be few or no strings
at
This one is also fun:
sage: K = GF(8, 'a')
sage: K(1) == ZZ(1) == QQ(1)
True
sage: K(1) == QQ(1)
False
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+
Another instance of our non-transitive equality
sage: K1 = GF(8,'x')
sage: K2 = GF(8,'y')
sage: K1.one() == 1 == K2.one()
True
On 17/09/15 07:19, Nathann Cohen wrote:
Here is another discovery after 15 minutes of debugging:
sage: K1 = GF(8,'x')
sage: K2 = GF(8,'y')
sage: K1(1) == K2(1)
False
On 2015-09-17 12:32, Jean-Pierre Flori wrote:
Don't we have a random keyword as well?
Not a random keyword, but a modulus="random" argument (there are several
more algorithms to choose a modulus)
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
On Thursday, September 17, 2015 at 12:24:07 PM UTC+2, Jeroen Demeyer wrote:
>
> On 2015-09-17 11:56, Volker Braun wrote:
> > Two comments:
> >
> > A) There is no such thing as "different finite fields of the same size
> > with the same generator name"
>
> Of course there is:
>
> sage: GF(8,
On 2015-09-17 11:56, Volker Braun wrote:
Two comments:
A) There is no such thing as "different finite fields of the same size
with the same generator name"
Of course there is:
sage: GF(8, 'a') is GF(8, 'a', modulus="adleman-lenstra")
False
--
You received this message because you are subscri
Here is another discovery after 15 minutes of debugging:
sage: K1 = GF(8,'x')
sage: K2 = GF(8,'y')
sage: K1(1) == K2(1)
False
Nathann
On 17 September 2015 at 12:15, Vincent Delecroix
<20100.delecr...@gmail.com> wrote:
>
>
> On 17/09/15 06:53, Simon King wrote:
>>
>> Hi!
>>
>> On 2015-09-17, Jero
On 17/09/15 06:53, Simon King wrote:
Hi!
On 2015-09-17, Jeroen Demeyer wrote:
On 2015-09-16 16:43, Jean-Pierre Flori wrote:
Hi,
I guess one of the issue is that there is no canonical map between two
different representations of the same finite field (so no coercion).
The question is real
Two comments:
A) There is no such thing as "different finite fields of the same size with
the same generator name"
sage: GF(4, 'a') is GF(4, 'a')
True
sage: GF(4, 'a') is GF(4, 'b')
False
There is no way to cast finite field elements to other finite field
elements apart from the prime subfiel
Hi!
On 2015-09-17, Jeroen Demeyer wrote:
> On 2015-09-16 16:43, Jean-Pierre Flori wrote:
>> Hi,
>>
>> I guess one of the issue is that there is no canonical map between two
>> different representations of the same finite field (so no coercion).
>
> The question is really: is the map between repre
> The question is really: is the map between representations of the same
> finite field, which differ only in variable name, "canonical"?
I would say that there is no big risk to do that, though I am not at
all knowledgeable on those parts of the code. If it can be dangerous
but can be detected, h
On 17 September 2015 at 10:26, Nathann Cohen wrote:
>> that grant (e.g. for me, 3 person-months over 4 years which translates
>> into about 2 days per week) are required to keep time sheets so that
That should read: 2 days per month (it is 1/16).
>
> What the hell. You too? It's even worse than
> that grant (e.g. for me, 3 person-months over 4 years which translates
> into about 2 days per week) are required to keep time sheets so that
What the hell. You too? It's even worse than I thought, basically
everybody here has had a share of ODK's money and is thankful for it.
Nathann
--
You
On 2015-09-14 22:18, Volker Braun wrote:
will be in the next beta
...if somebody reviews #19182.
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsub
On 2015-09-16 16:43, Jean-Pierre Flori wrote:
Hi,
I guess one of the issue is that there is no canonical map between two
different representations of the same finite field (so no coercion).
The question is really: is the map between representations of the same
finite field, which differ only
On 16 September 2015 at 19:03, Dima Pasechnik wrote:
> On 16 September 2015 at 10:36, Nathann Cohen wrote:
>> Dima,
>>
>>> E.g. as far as I am concerned, it's thanks to ODK, which pays 50% of my
>>> salary, that I can set aside time for this.
>>
>> You are of course welcome (and probably bound) t
34 matches
Mail list logo
