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 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 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
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
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
> On 3/20/07, Kyle Schalm <[EMAIL PROTECTED]> wrote:
>> there is trouble with the determinant method on a matrix over a funky ring
>> (yes, the same funky ring causing all my other problems). in its simplest
>> form:
>>
>> In [43]: W.=QQ['w']
>> In [44]: WZ.=W['z']
>> In [45]: matrix(WZ,2,2,[1,z
Here's a patch that resolves the underlying issue, namely that
elements of the fraction field over a generic polynomial ring
couldn't be cast back into the original ring despite having
denominator 0. This came up because the Hessenberg form calculation
involved passing to the field of fract
From the maxima mailing list: [EMAIL PROTECTED]
Kostas Oikonomou wrote:
> Your comment on R prompts me to mention another system for
> data analysis and graphics which I've used, and which is
> mature, actively developed, and very well supported: it is
> called ROOT, and it is being developed
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
On 3/21/07, Robert Bradshaw <[EMAIL PROTECTED]> wrote:
> I agree with Kyle that small cases should default to the naive
> algorithm, 2x2 at least, especially if working in the fraction field
> is expensive in comparison. Should I change this?
Yes, definitely.
I think the generic Hessenberg form
On 3/21/07, Kyle Schalm <[EMAIL PROTECTED]> wrote:
> btw, i did have trouble applying the patch. it said,
> "abort: outstanding uncommitted changes".
> any idea what that means?
It means it's a text-only patch that was taken "out of context"
from my tree to yours. You can get around though -- do
On 3/21/07, Jaap Spies <[EMAIL PROTECTED]> wrote:
[...]
> >
> > I am not aware of any other public-domain data analysis
> > system that has these graphics capabilities. There is work
> > in R to add a GUI to it, but, as far as I know, it is
> > nowhere near where ROOT is right now.
> >
> > I lik
I've noticed that sage has problems with the integrity of sage-
packages.
Supose that you have patially donwload a file, but for whatever reason
it gets truncated.
Then sage won't check its integrity before installing.
I would sugest adding to each file an md5 sum (or perhaps better a gpg
signta
I reported this here:
http://www.sagemath.org:9002/sage_trac/ticket/328
I then fixed it for sage-2.4. The fixed involved re-enabling killing of
maxima variables when the corresponding SAGE object
goes out of scope.
On 3/10/07, Gregory Vanuxem <[EMAIL PROTECTED]> wrote:
>
> Hello,
>
> Here is
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
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
16 matches
Mail list logo
