On Thu, Nov 5, 2009 at 10:31 AM, Michael Orlitzky wrote:
>
> Jason Grout wrote:
>>
>> Interesting. I consider a brief discussion of numerical instability an
>> essential feature of a first-semester linear algebra course. These
>> students will most likely be using numerical linear algebra in re
On Nov 4, 2009, at 3:01 PM, Michael Orlitzky wrote:
> Simon King wrote:
>> Hi Michael!
>>
>> On 4 Nov., 20:55, Michael Orlitzky wrote:
>> [...]
it starts using floating point numbers internally.
>>> I didn't tell it to do that.
>>
>> You did. 0.5 is a floating point number.
>
> I guess it c
Michael Orlitzky wrote:
> Jason Grout wrote:
>> I think there are several points here:
>>
>> 1. The moment Sage sees a decimal, it starts using approximate, floating
>> point arithmetic. If you don't want that, then don't use decimals; use
>> fractions. This is consistent with most mathematica
Simon King wrote:
> Hi Michael!
>
> On 4 Nov., 20:55, Michael Orlitzky wrote:
> [...]
>>> it starts using floating point numbers internally.
>> I didn't tell it to do that.
>
> You did. 0.5 is a floating point number.
I guess it comes down to that, when I say 0.3 I mean 0.3, and SAGE
assumes
Hi Michael!
On 4 Nov., 20:55, Michael Orlitzky wrote:
[...]
> > it starts using floating point numbers internally.
>
> I didn't tell it to do that.
You did. 0.5 is a floating point number.
> Ok, but (assuming it can be done) how do you propose I convert my
> problem to an exact field? By hand?
Jason Grout wrote:
>
> I think there are several points here:
>
> 1. The moment Sage sees a decimal, it starts using approximate, floating
> point arithmetic. If you don't want that, then don't use decimals; use
> fractions. This is consistent with most mathematical software (though
> other
Michael Orlitzky wrote:
>> It's messy the instant you type it in with decimal points
>
> Not the end user's fault.
>
>
>> it starts using floating point numbers internally.
>
> I didn't tell it to do that.
>
I think there are several points here:
1. The moment Sage sees a decimal, it star
On Nov 4, 2009, at 11:25 AM, Michael Orlitzky wrote:
> Robert Bradshaw wrote:
>>
>> I'd also like to point out that we don't just want to fall back and
>> do
>> everything over the rationals (even though any finite decimal
>> expansion is rational) as things get much slower due to coefficient
>
Robert Bradshaw wrote:
>
>
> Technically, your matrix does not contain integer multiples of 0.1, it
> contains approximations to integer multiples of 0.1, represented base
> 2, truncated to 53 bits of precision.
>
> sage: (0.1).exact_rational()
> 3602879701896397/36028797018963968
>
> As yo
On Nov 4, 2009, at 11:08 AM, Michael Orlitzky wrote:
>
> Jason Grout wrote:
>>
>> I don't think it's an issue of irrational versus rational. It's
>> numerical precision and inexact floating point numbers. This
>> matrix is
>> terribly ill-conditioned. It is right on the border line between
Robert Bradshaw wrote:
>
> I'd also like to point out that we don't just want to fall back and do
> everything over the rationals (even though any finite decimal
> expansion is rational) as things get much slower due to coefficient
> explosion. For example
Who cares about speed when the ans
Jason Grout wrote:
>
> I don't think it's an issue of irrational versus rational. It's
> numerical precision and inexact floating point numbers. This matrix is
> terribly ill-conditioned. It is right on the border line between being
> invertible or not, numerically speaking:
No, it isn't.
On Nov 3, 2009, at 8:13 PM, Jason Grout wrote:
> Michael Orlitzky wrote:
>> Jason Grout wrote:
>>
>>> The problem here is that no one has really implemented a numerically
>>> stable version of echelon_form for RR. I thought we called scipy
>>> for
>>> rank calculations over RDF, but apparently
Michael Orlitzky wrote:
> Jason Grout wrote:
>
>> The problem here is that no one has really implemented a numerically
>> stable version of echelon_form for RR. I thought we called scipy for
>> rank calculations over RDF, but apparently we don't even do that! Scipy
>> answers correctly:
>>
>
Jason Grout wrote:
> The problem here is that no one has really implemented a numerically
> stable version of echelon_form for RR. I thought we called scipy for
> rank calculations over RDF, but apparently we don't even do that! Scipy
> answers correctly:
>
> sage: import scipy
> sage: scip
William Stein wrote:
>
> This is really no different than:
>
> sage: n = 5; m = Mod(5, 19)
> sage: n == m
> True
> sage: n.additive_order()
> +Infinity
> sage: m.additive_order()
> 19
>
> I don't consider this a bug. The original poster's issues might stem
> from misunderstanding about how flo
Michael Orlitzky wrote:
>
> You're going to have a rather hard time convincing me that, upon
> encountering a decimal point, any other math software is going to flip
> out and silently return incorrect results for basic matrix operations.
>
> Recall:
>
> sage: m = matrix([ [-0.3, 0.2, 0.1],
>
On Mon, Nov 2, 2009 at 2:18 AM, John Cremona wrote:
>
>
>
> On Nov 1, 5:34 pm, Michael Orlitzky wrote:
>> This one had me stumped for a while. I'm using 4.1.1 here, but found the
>> same results in a 4.1.2 notebook. The solve_foo() methods are broken,
>> too; probably as a consequence.
>>
>> # G
On Nov 1, 5:34 pm, Michael Orlitzky wrote:
> This one had me stumped for a while. I'm using 4.1.1 here, but found the
> same results in a 4.1.2 notebook. The solve_foo() methods are broken,
> too; probably as a consequence.
>
> # Good
>
> sage: m = matrix([ [(-3/10), (1/5), (1/10)],
>
19 matches
Mail list logo
