True. (There is a natural coercion into rings of lower precision, and
in RDF (real double field = 53 bits of precision) they are equal.)
On Mar 21, 2007, at 8:04 PM, Nick Alexander wrote:
> Excellent, very good. I just have one change, noted below. The
> output of "a == RDF(1)" is needed, be
Excellent, very good. I just have one change, noted below. The
output of "a == RDF(1)" is needed, because I don't know what is
supposed to happen.
Nick
On Mar 21, 9:00 am, "William Stein" <[EMAIL PROTECTED]> wrote:
> FYI, I've added the following discussion of hashing to the programming
> guid
FYI, I've added the following discussion of hashing to the programming
guide for the next version of SAGE:
> \section{The {\tt \_\_hash\_\_} Special Method}
> Here's the definition of \code{__hash__}
> from the Python reference manual.
>
> \begin{quote}
> Called for the key object for dictionar
It should be noted that hashing should ideally be a very quick
operation. Also, it's not possible to have x == y => hash(x) == hash
(y) for a useful hash function. (For example, the equalities z == mod
(z, 2) and z == mod(z, 3) would force hash() to be constant on the
integers.) I think the
So I've read this thread twice, and I can't understand what should
happen next. Can someone sketch how algebraic extensions (say L/K/Q)
should hash? I suggest:
Q.__hash__ tries to __call__ to Z, and if that fails, hashes how it
does now.
K.__hash__ tries to __call__ to Q, and if that fails, ha
On Mar 21, 2007, at 1:02 AM, Nick Alexander wrote:
> Are RealField(100) and RealField(200) the same ring? To me, they
> aren't, but there is a canonical coercion in one direction. And you
> can expect __call__ to map between both.
>
> Is that right?
> Nick
No, they are not the same ring. Every
On Mar 20, 2007, at 11:04 PM, David Harvey wrote:
> On Mar 21, 2007, at 1:37 AM, Robert Bradshaw wrote:
>
>> One could also force all keys of a
>> hashtable to live in a given ring.
>
> I don't think you'd want to do that. First, it wouldn't even solve
> the problem (e.g. because of the precision
On Mar 20, 11:04 pm, David Harvey <[EMAIL PROTECTED]> wrote:
> On Mar 21, 2007, at 1:37 AM, Robert Bradshaw wrote:
>
> > One could also force all keys of a
> > hashtable to live in a given ring.
>
> I don't think you'd want to do that. First, it wouldn't even solve
> the problem (e.g. because of
On Mar 21, 2007, at 1:37 AM, Robert Bradshaw wrote:
> One could also force all keys of a
> hashtable to live in a given ring.
I don't think you'd want to do that. First, it wouldn't even solve
the problem (e.g. because of the precision issues you raised before
-- you can have two elements o
On Mar 21, 2007, at 1:38 AM, William Stein wrote:
> That said, we simply can't require
> (*) "a == b ==> hash(a) == hash(b)"
> in SAGE, because mathematics is simply too complicated for this sort
> of rule. So what is done in SAGE is to _attempt_ to satisfy (*)
> when it
> is reasonably eas
On 3/20/07, David Harvey <[EMAIL PROTECTED]> wrote:
> On Mar 21, 2007, at 1:19 AM, Nick Alexander wrote:
> > On Mar 20, 4:12 pm, William Stein <[EMAIL PROTECTED]> wrote:
> >> On Tuesday 20 March 2007 4:00 pm, Nick Alexander wrote:
> >>> For some reason, google won't let me grab your patch. Anyway
On Mar 20, 2007, at 10:27 PM, David Harvey wrote:
> On Mar 21, 2007, at 1:19 AM, Nick Alexander wrote:
>
>> On Mar 20, 4:12 pm, William Stein <[EMAIL PROTECTED]> wrote:
>>> On Tuesday 20 March 2007 4:00 pm, Nick Alexander wrote:
>>>
For some reason, google won't let me grab your patch. Anyw
On Mar 21, 2007, at 1:19 AM, Nick Alexander wrote:
> On Mar 20, 4:12 pm, William Stein <[EMAIL PROTECTED]> wrote:
>> On Tuesday 20 March 2007 4:00 pm, Nick Alexander wrote:
>>
>>> For some reason, google won't let me grab your patch. Anyway,
>>> converting to string is not a good idea. Better
On Mar 20, 4:12 pm, William Stein <[EMAIL PROTECTED]> wrote:
> On Tuesday 20 March 2007 4:00 pm, Nick Alexander wrote:
>
> > For some reason, google won't let me grab your patch. Anyway,
> > converting to string is not a good idea. Better to hash a tuple of
> > real, imag I think. (Maybe you
On Tuesday 20 March 2007 4:00 pm, Nick Alexander wrote:
> For some reason, google won't let me grab your patch. Anyway,
> converting to string is not a good idea. Better to hash a tuple of
> real, imag I think. (Maybe you did this already?)
You have to be really careful, since if a == b,
then
For some reason, google won't let me grab your patch. Anyway,
converting to string is not a good idea. Better to hash a tuple of
real, imag I think. (Maybe you did this already?)
I don't seem able to send in a key function sorted; I'll try
sort(cmp=) in a moment. I wonder if I hit a Pyrex bug
On 3/19/07, Mike Hansen <[EMAIL PROTECTED]> wrote:
> > : unhashable type:
> > 'sage.rings.complex_number.ComplexNumber'
>
> You should be able to just add the following to the ComplexNumber class:
>
> def __hash__(self):
> return str(self).__hash__()
>
> That should work so long as the complex
> While working on the patch, I came across another problem, one that I
> don't want to fix.
>
> sage: D = {} ; D[CC(0)] = 1
> ---
> Traceback (most recent call
> last)
>
> /Users/nalexand/emacs/sage/ in ()
>
> :
While working on the patch, I came across another problem, one that I
don't want to fix.
sage: D = {} ; D[CC(0)] = 1
---
Traceback (most recent call
last)
/Users/nalexand/emacs/sage/ in ()
: unhashable type:
's
On 3/16/07, didier deshommes <[EMAIL PROTECTED]> wrote:
>
> On Mar 16, 2:23 pm, "Nick Alexander" <[EMAIL PROTECTED]> wrote:
> > Do you agree that the current behaviour is brain-dead? 'cuz I'll
> > patch it!
Please send me a patch, so that it returns multiplicities in all cases.
-- William
-
On Mar 16, 2:23 pm, "Nick Alexander" <[EMAIL PROTECTED]> wrote:
> Do you agree that the current behaviour is brain-dead? 'cuz I'll
> patch it!
Agreed! roots() should always return multiplicity when asked to.
didier
>
> Nick
--~--~-~--~~~---~--~~
To post to this
On Mar 15, 11:53 pm, "didier deshommes" <[EMAIL PROTECTED]> wrote:
> On Mar 16, 2:37 am, "didier deshommes" <[EMAIL PROTECTED]> wrote:
>
> > On Mar 16, 2:23 am, "Nick Alexander" <[EMAIL PROTECTED]> wrote:
>
> > > Is this because of precision issues? In that case, I still think this
> > > should
On Mar 16, 2:37 am, "didier deshommes" <[EMAIL PROTECTED]> wrote:
> On Mar 16, 2:23 am, "Nick Alexander" <[EMAIL PROTECTED]> wrote:
>
> > Is this because of precision issues? In that case, I still think this
> > should return [(1...., 1), (1., 1)] and be documented as
> > such.
>
>
On Mar 16, 2:23 am, "Nick Alexander" <[EMAIL PROTECTED]> wrote:
> Is this because of precision issues? In that case, I still think this
> should return [(1...., 1), (1., 1)] and be documented as
> such.
>
> sage: (CC(1)*(x-1)**2).roots()
> [1.00, 1.00]
>
> sag
24 matches
Mail list logo
