2014-06-10 1:16 UTC+02:00, Nils Bruin :
> On Monday, June 9, 2014 3:50:06 PM UTC-7, Volker Braun wrote:
>>
>> This seems like it would be a good solution in Sage, namely provide
>> associative containers that participate in coercion and ensure that all
>> elements have the same type. E.g.
>>
>> sag
Yup, gcc has built, & it was the command below that did it. Thanks for the
help (in this thread & elsewhere).
john perry
On Tuesday, June 10, 2014 12:42:16 AM UTC-5, john_perry_usm wrote:
>
> ARGH. I spent forever searching for a solution to the limits.h issue &
> concluded (hopefully not wrong
Well, it seems there is a fix indicated, which I found once I actually
searched for it:
https://groups.google.com/d/msg/sage-devel/5gmv88_Mvgs/8qOpVS17eYIJ
...but by then I had already trashed Xcode, which fulfilled a long-standing
desire, anyway. :-) This isn't the first software package it's
On 10/06/2014, at 1738, john_perry_usm wrote:
>
> Mavericks is up-to-date; extra packages installed. I'm not finding an option
> for "command-line tools" in Preferences->Downloads as per the README,
Here's your problem - you're reading the readme in the wrong place (this is the
ML instructions
On 10/06/2014, at 1738, john_perry_usm wrote:
>
> Right now I'm reinstalling Xcode from scratch, in the hope that this will fix
> it (as opposed to using the Xcode upgrade made when upgrading from 10.6 to
> Mavericks). If that works, I'll report it.
That might work.
You need to get the latest
ARGH. I spent forever searching for a solution to the limits.h issue &
concluded (hopefully not wrongly) that I have to rebuild Sage from source.
Now I see that the question of chefs.h *has* been posed, several times...
If it doesn't work after
xcode-select --install
then I will inquire further
Hello
I'm trying to build Sage from source on Mavericks. It quits when trying to
build gcc-4.7.3.p1, as it is unable to find cdefs.h.
Mavericks is up-to-date; extra packages installed. I'm not finding an
option for "command-line tools" in Preferences->Downloads as per the
README, but I think t
On Mon, 9 Jun 2014 15:50:06 -0700 (PDT)
Volker Braun wrote:
> On Monday, June 9, 2014 11:08:33 PM UTC+1, Nils Bruin wrote:
>
> > At any particular moment, though, an associative array has an index
> > universe, so as long as equality and hash are consistent within that
> > universe
> >
>
> Th
On Monday, June 9, 2014 3:50:06 PM UTC-7, Volker Braun wrote:
>
> This seems like it would be a good solution in Sage, namely provide
> associative containers that participate in coercion and ensure that all
> elements have the same type. E.g.
>
> sage: s = SageSet([3, 8]); s # universe = ZZ
On Monday, June 9, 2014 11:08:33 PM UTC+1, Nils Bruin wrote:
> At any particular moment, though, an associative array has an index
> universe, so as long as equality and hash are consistent within that
> universe
>
This seems like it would be a good solution in Sage, namely provide
associative
On Thu, Jun 05, 2014 at 03:37:27PM -0700, jplab wrote:
>See http://page.mi.fu-berlin.de/labbe/Gallery.html for a few drawing
>examples.
I like your custom Sage logo with a *real( polyhedron plot much better
than the current official logo. And vote for making it the official logo!
Other th
On Monday, June 9, 2014 2:19:32 PM UTC-7, William wrote:
> I wanted to understand what you just claimed, so in Magma [1] I typed
> this:
>
> 5 eq GF(7)!5
>
> but it output "true".So clearly I completely misunderstood your
> claim. Can you be more precise?
>
Sorry, you didn't misunde
Hi,
> and as discussed there, it's a compromise that was considered the least
> bad. The main problem is that if you want, for all integers a,b and
> distinct primes p,q, that
>
> GF(p)(a) == GF(p)(b) implies a == GF(p)(b) and
> GF(q)(a) == GF(q)(b) implies a == GF(q)(b)
I do not want that! Consi
On Mon, Jun 9, 2014 at 2:14 PM, Nils Bruin wrote:
> The consistent solution, and one that is mathematically defendable, would be
> to have a != GF(p)(a) for integers a (i.e., always force explicit coercion
> for equality to hold). So that is making "==" strict enough to allow hash to
> meet its re
On Monday, June 9, 2014 1:44:41 PM UTC-7, Erik Massop wrote:
>
> On Mon, 09 Jun 2014 16:48:09 +0200
> leif > wrote:
>
> > Volker Braun wrote:
> > > On Monday, June 9, 2014 12:54:56 AM UTC+1, vdelecroix wrote:
> > >
> > > sage: {3, AA(3)}
> > > {3, 3}
> > >
> > >
> > > IMHO you shou
On Monday, June 9, 2014 9:44:41 PM UTC+1, Erik Massop wrote:
>
> IMHO this should be disallowed. All objects that implement __hash__
> should live up to contract of __hash__, which is that a==b implies
> hash(a)==hash(b)
I totally agree that the situation is currently unsatisfactory, but the
s
On Mon, 09 Jun 2014 16:48:09 +0200
leif wrote:
> Volker Braun wrote:
> > On Monday, June 9, 2014 12:54:56 AM UTC+1, vdelecroix wrote:
> >
> > sage: {3, AA(3)}
> > {3, 3}
> >
> >
> > IMHO you should never put sage objects with different parents into an
> > associative container.
>
> Altho
Volker Braun wrote:
On Monday, June 9, 2014 12:54:56 AM UTC+1, vdelecroix wrote:
sage: {3, AA(3)}
{3, 3}
IMHO you should never put sage objects with different parents into an
associative container.
Although that's presumably an anti-pythonic attitude, +1. (Provided
they *won't* hav
bump
On Friday, June 6, 2014 12:09:22 PM UTC+1, Volker Braun wrote:
>
> Bump
>
> Note that ticket is now about Python 2.7.7 update
>
> On Tuesday, June 3, 2014 10:32:57 PM UTC+1, François wrote:
>>
>> I am sorry, I don't think I have the foo for #16415 otherwise it would
>> have been done sometim
The problem is not only having a is_prime method or not. It is also which
should be the output of that method. 3 is a unit in AA, but not in ZZ. The
factorization is different deppending on where you consider it, the gcd
too... there are so many mathematically relevant properties for a number
t
I don't have an answer, but want to point out that making the hash equal
also means that they are considered identical for caching purposes. Whereas
with different hashes they are only identical if a hash collision happens
(unlikely, but not exceedingly so).
On Monday, June 9, 2014 12:54:56 AM
On Mon, 9 Jun 2014 01:54:53 +0200
Vincent Delecroix <20100.delecr...@gmail.com> wrote:
...
> I guess we could try to make the hash compatible between the standard
> sets of numbers ZZ, QQ, AA, QQbar.
The hashes of the following are compatible, since they are basically
casting to python complex thr
22 matches
Mail list logo
