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
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
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
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
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, 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
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
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
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
> 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
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
16 matches
Mail list logo
