>I'm not sure how allowing partial coercions would help the situation.
>The problems are (1) given a and b in different rings, how to quickly
>find a' and b' so that a' + b' makes sense and dispatch to that
>operation and (2) whether or not sqrt(2) should start out as a SR
>object, or some
On Jun 3, 2008, at 12:22 PM, Henryk Trappmann wrote:
> On 31 Mai, 15:59, "William Stein" <[EMAIL PROTECTED]> wrote:
>> At a bare minimum there is never a canonical (automatic)
>> coercion from elements of R to elements of S unless that coercion
>> is defined (as a homomorphism) on all of R.
>
> I
On 31 Mai, 15:59, "William Stein" <[EMAIL PROTECTED]> wrote:
> At a bare minimum there is never a canonical (automatic)
> coercion from elements of R to elements of S unless that coercion
> is defined (as a homomorphism) on all of R.
I dont want to be heretical by why is it so important that coer
When I personally use Mathematica etc, I often don't expand
expressions x^20+20*x^19+. doesn't tell me much about where an
expression comes from. (x+5)^20 tells me a bunch. Expanding
expressions generally causes information loss for many calculus and
physics problems and going overboard
On Tue, Jun 3, 2008 at 3:09 AM, Gary Furnish <[EMAIL PROTECTED]> wrote:
> Your going to have a hard time convincing me that the default behavior
> in Mathematica and Maple is wrong. This makes sense for number theory
> but not for people using calculus.
Hmm, I must say from using maple on expr
On Mon, Jun 2, 2008 at 11:41 PM, Robert Bradshaw
<[EMAIL PROTECTED]> wrote:
>
> On Jun 2, 2008, at 12:55 PM, William Stein wrote:
>
>> On Mon, Jun 2, 2008 at 12:53 PM, Gary Furnish
>> <[EMAIL PROTECTED]> wrote:
>>>
>>> -1. First, everything cwitty said is correct.
>
> More on this below.
>
>>> Sec
On Jun 2, 2008, at 12:55 PM, William Stein wrote:
> On Mon, Jun 2, 2008 at 12:53 PM, Gary Furnish
> <[EMAIL PROTECTED]> wrote:
>>
>> -1. First, everything cwitty said is correct.
More on this below.
>> Second, if we start
>> using ZZ[sqrt(2)] and ZZ[sqrt(3)], then sqrt(2)+sqrt(3) requires
>
On 6/2/08, William Stein <[EMAIL PROTECTED]> wrote:
> > sage: a = e - 1
> > sage: for i in range(2,200):
> > : a = (a-1)*i
> > :
> > sage: float(a)
> > -inf
>
>
> Oh my god, floating point numbers are just broken!
>
:-)
> Seriously, floating point numbers are what they are
On Mon, Jun 2, 2008 at 5:15 PM, Gonzalo Tornaria
<[EMAIL PROTECTED]> wrote:
>
> On 6/2/08, William Stein <[EMAIL PROTECTED]> wrote:
>> Doing that sum works fine now. It's even fun. That
>> all the following work fine even with our current system
>> says something...
>>
>> sage: a = sum([sqr
BTW, if I change the iteration limit to 250 or more, I get a : maximum recursion depth exceeded
when evaluating float(a)... (sage 3.0)
Gonzalo
On 6/2/08, Gonzalo Tornaria <[EMAIL PROTECTED]> wrote:
> On 6/2/08, William Stein <[EMAIL PROTECTED]> wrote:
> > Doing that sum works fine now. It's
On 6/2/08, William Stein <[EMAIL PROTECTED]> wrote:
> Doing that sum works fine now. It's even fun. That
> all the following work fine even with our current system
> says something...
>
> sage: a = sum([sqrt(p) for p in primes(1000)])
> sage: float(a)
> 3307.7690992952139
> sage: RDF(a)
On Mon, Jun 2, 2008 at 3:19 PM, John Cremona <[EMAIL PROTECTED]> wrote:
>
> 2008/6/2 William Stein <[EMAIL PROTECTED]>:
>>
>> On Mon, Jun 2, 2008 at 12:53 PM, Gary Furnish <[EMAIL PROTECTED]> wrote:
>>>
>>> -1. First, everything cwitty said is correct. Second, if we start
>>> using ZZ[sqrt(2)] an
2008/6/2 William Stein <[EMAIL PROTECTED]>:
>
> On Mon, Jun 2, 2008 at 12:53 PM, Gary Furnish <[EMAIL PROTECTED]> wrote:
>>
>> -1. First, everything cwitty said is correct. Second, if we start
>> using ZZ[sqrt(2)] and ZZ[sqrt(3)], then sqrt(2)+sqrt(3) requires going
>> through the coercion system
On Mon, Jun 2, 2008 at 12:53 PM, Gary Furnish <[EMAIL PROTECTED]> wrote:
>
> -1. First, everything cwitty said is correct. Second, if we start
> using ZZ[sqrt(2)] and ZZ[sqrt(3)], then sqrt(2)+sqrt(3) requires going
> through the coercion system which was designed to be elegant instead
> of fast,
-1. First, everything cwitty said is correct. Second, if we start
using ZZ[sqrt(2)] and ZZ[sqrt(3)], then sqrt(2)+sqrt(3) requires going
through the coercion system which was designed to be elegant instead
of fast, so this becomes insanely slow for any serious use. Finally,
this is going to requ
On Jun 2, 2008, at 9:47 AM, William Stein wrote:
> On Mon, Jun 2, 2008 at 9:45 AM, Carl Witty <[EMAIL PROTECTED]>
> wrote:
>>
>> On Jun 2, 9:17 am, "William Stein" <[EMAIL PROTECTED]> wrote:
>>> On Mon, Jun 2, 2008 at 1:30 AM, Henryk Trappmann
But back to SymbolicRing and SymbolicConstant.
On Mon, Jun 2, 2008 at 9:45 AM, Carl Witty <[EMAIL PROTECTED]> wrote:
>
> On Jun 2, 9:17 am, "William Stein" <[EMAIL PROTECTED]> wrote:
>> On Mon, Jun 2, 2008 at 1:30 AM, Henryk Trappmann
>> > But back to SymbolicRing and SymbolicConstant.
>> > I have the following improvement
>> > SUGGESTION: whe
On Jun 2, 9:17 am, "William Stein" <[EMAIL PROTECTED]> wrote:
> On Mon, Jun 2, 2008 at 1:30 AM, Henryk Trappmann
> > But back to SymbolicRing and SymbolicConstant.
> > I have the following improvement
> > SUGGESTION: when creating sqrt(2) or other roots from integers, then
> > assign to them the p
On Mon, Jun 2, 2008 at 1:30 AM, Henryk Trappmann
<[EMAIL PROTECTED]> wrote:
>
> On 1 Jun., 18:56, Carl Witty <[EMAIL PROTECTED]> wrote:
>> Sage has such a decision procedure built in to its implementation of
>> QQbar, the algebraic numbers.
>
> But I have to say they are quite hidden in the refere
On 1 Jun., 18:56, Carl Witty <[EMAIL PROTECTED]> wrote:
> Sage has such a decision procedure built in to its implementation of
> QQbar, the algebraic numbers.
But I have to say they are quite hidden in the reference manual.
Thank you for this hint. I also found AA the algebraic reals if your
comp
On Jun 1, 6:08 am, Henryk Trappmann <[EMAIL PROTECTED]> wrote:
> > there is an "obvious" convention that by default we mean the positive
> > root.
>
> We have to distinguish between solutions of polynomials and roots.
> Roots are clearly defined mono-valued functions:
> z.nth_root(n)=e^(log(z)/n)
PS e.g. see http://portal.acm.org/citation.cfm?id=800204.806298 (found
using Google Scholar): "Algebraic simplification a guide for the
perplexed" 1971, has references back to 1960 at least -- and also
mentioned Axiom.
2008/6/1 John Cremona <[EMAIL PROTECTED]>:
> 2008/6/1 Henryk Trappmann <[EMAIL
2008/6/1 Henryk Trappmann <[EMAIL PROTECTED]>:
>
>> there is an "obvious" convention that by default we mean the positive
>> root.
>
> We have to distinguish between solutions of polynomials and roots.
> Roots are clearly defined mono-valued functions:
> z.nth_root(n)=e^(log(z)/n)
> however this f
> there is an "obvious" convention that by default we mean the positive
> root.
We have to distinguish between solutions of polynomials and roots.
Roots are clearly defined mono-valued functions:
z.nth_root(n)=e^(log(z)/n)
however this function is not continuous in z, as log is not continuous
at
There was a thread on this issue a few months ago, just on the
simplication of algebraic expressions, and I don't want to repeat all
that. Briefly, people tend to think this is easy when they look at
examples which only involve square roots of positive reals, since
there is an "obvious" conventio
> But coercing symbolic constants into RR or CC is not a simple, (or
> even well-defined?) matter. Just think of many-valued nested
> radicals; or if a=sqrt(2), b=sqrt(3), c=sqrt(6), would a*b-c
> simplify/coerce to 0? This is not stratightforward at all.
Is it?
I just would evaluate the expr
2008/6/1 William Stein <[EMAIL PROTECTED]>:
>
> On Sat, May 31, 2008 at 3:33 PM, Jason Grout
> <[EMAIL PROTECTED]> wrote:
>>
>> Henryk Trappmann wrote:
>>> On May 31, 10:55 pm, Carl Witty <[EMAIL PROTECTED]> wrote:
Actually, there's no homomorphism either way;
RR(R2(2)+R2(3)) != RR(R2(2)
-1 To this idea. Better to try to improve the coercion system to
support something that interacts with symbolics better.
On Sat, May 31, 2008 at 5:23 PM, William Stein <[EMAIL PROTECTED]> wrote:
>
> On Sat, May 31, 2008 at 3:33 PM, Jason Grout
> <[EMAIL PROTECTED]> wrote:
>>
>> Henryk Trappmann
On May 31, 2:56 pm, Henryk Trappmann <[EMAIL PROTECTED]> wrote:
> On May 31, 10:55 pm, Carl Witty <[EMAIL PROTECTED]> wrote:
> > IMHO, giving a+b the precision of the less-precise operand is better
> > than using the more-precise operand, because the latter has too much
> > chance of confusing peo
On Sat, May 31, 2008 at 3:33 PM, Jason Grout
<[EMAIL PROTECTED]> wrote:
>
> Henryk Trappmann wrote:
>> On May 31, 10:55 pm, Carl Witty <[EMAIL PROTECTED]> wrote:
>>> Actually, there's no homomorphism either way;
>>> RR(R2(2)+R2(3)) != RR(R2(2)) + RR(R2(3))
>>
>> Hm, thats an argument. I somehow th
>
> But if so then I want to have something like SymbolicNumber which is
> the subset of SymbolicRing that does not contain variables. And that
> this SymbolicNumber is coerced automatically down when used with
> RealField.
There are really, really severe issues with coercion out of the
SymbolicR
Henryk Trappmann wrote:
> On May 31, 10:55 pm, Carl Witty <[EMAIL PROTECTED]> wrote:
>> Actually, there's no homomorphism either way;
>> RR(R2(2)+R2(3)) != RR(R2(2)) + RR(R2(3))
>
> Hm, thats an argument. I somehow thought that it is closer to a
> homomorphism but perhaps this reasoning has no ba
On May 31, 10:55 pm, Carl Witty <[EMAIL PROTECTED]> wrote:
> Actually, there's no homomorphism either way;
> RR(R2(2)+R2(3)) != RR(R2(2)) + RR(R2(3))
Hm, thats an argument. I somehow thought that it is closer to a
homomorphism but perhaps this reasoning has no base.
> IMHO, giving a+b the precis
> > Wouldnt it then be more consistent coerce RealFields to higher
> > precision?
>
> Suppose you write down an expression involving various digits of precision,
> and in order to evaluate it Sage makes a sequence of *automatic*
> coercions and outputs the result. Do you want an answer that has
>
On May 31, 11:14 am, Henryk Trappmann <[EMAIL PROTECTED]> wrote:
> On May 31, 3:59 pm, "William Stein" <[EMAIL PROTECTED]> wrote:
>
> > However, there is a natural homomorphism from
> > RR to the symbolic ring.
>
> Hm, if this is the precondition then the coercion of say RealField(52)
> to RealFie
On Sat, May 31, 2008 at 11:14 AM, Henryk Trappmann
<[EMAIL PROTECTED]> wrote:
>
> On May 31, 3:59 pm, "William Stein" <[EMAIL PROTECTED]> wrote:
>> However, there is a natural homomorphism from
>> RR to the symbolic ring.
>
> Hm, if this is the precondition then the coercion of say RealField(52)
>
On May 31, 3:59 pm, "William Stein" <[EMAIL PROTECTED]> wrote:
> However, there is a natural homomorphism from
> RR to the symbolic ring.
Hm, if this is the precondition then the coercion of say RealField(52)
to RealField(2) is not valid, because it is no homomorphism at all.
For example let R2 =
On Sat, May 31, 2008 at 5:21 AM, Henryk Trappmann
<[EMAIL PROTECTED]> wrote:
>
> Hello,
>
> while the general rule of coercing in binary operations seems to be
> towards the most unprecise,
> for example
> RealField(100)(1)*2 == RealField(100)(2) or
> RealField(100)(1)*RealField(50)(1) == RealFiel
I think log(2) is an element of the symbolic ring SR. There is no
canonical
morphism SR-->RR. So perhaps coercion is not expected to work?
Michel
On May 31, 2:21 pm, Henryk Trappmann <[EMAIL PROTECTED]> wrote:
> Hello,
>
> while the general rule of coercing in binary operations seems to be
> tow
39 matches
Mail list logo
