(cross posting to fricas-devel, maybe others want to make things more
precise. Eg., I won't touch the difference between coercion and
conversion here, although I probably should...)
"Nicolas M. Thiery" writes:
> > > Do you foresee any occasion to meet physically all three of us?
> >
> > Well,
> > Do you foresee any occasion to meet physically all three of us?
>
> Well, at least two of us are at FPSAC 09 at RISC.
>
> (I love all these abbreviations, it feels so french :-)
:-)
> (3) The interpreter makes a heuristic choice which signatures to
> prefer over others. This algorithm
"Nicolas M. Thiery" writes:
> On Sat, Mar 14, 2009 at 03:51:36PM +0100, Martin Rubey wrote:
> >
> > "Nicolas M. Thiery" writes:
> >
> > > Well, maybe we could join forces, and write a paper "coercion and
> > > dispatch in Sage and MuPAD". Having more than one implementation of
> > > the conce
On Sat, Mar 14, 2009 at 02:27:34AM -0700, William Stein wrote:
>
> On Fri, Mar 13, 2009 at 1:26 AM, Nicolas M. Thiery
> wrote:
> >
> > On Thu, Mar 12, 2009 at 09:10:43PM -0700, Robert Bradshaw wrote:
> >> > - I see 10*bla as (potentially) involving two independent things:
> >> > coercion and
On Sat, Mar 14, 2009 at 03:51:36PM +0100, Martin Rubey wrote:
>
> "Nicolas M. Thiery" writes:
>
> > Well, maybe we could join forces, and write a paper "coercion and
> > dispatch in Sage and MuPAD". Having more than one implementation of
> > the concept would even make it a standard :-)
>
> Ma
On Mar 14, 2009, at 2:27 AM, William Stein wrote:
> On Fri, Mar 13, 2009 at 1:26 AM, Nicolas M. Thiery
> wrote:
>>
>> On Thu, Mar 12, 2009 at 09:10:43PM -0700, Robert Bradshaw wrote:
- I see 10*bla as (potentially) involving two independent things:
coercion and multiple dispatch
>>
"Nicolas M. Thiery" writes:
> Well, maybe we could join forces, and write a paper "coercion and
> dispatch in Sage and MuPAD". Having more than one implementation of
> the concept would even make it a standard :-)
Maybe it's even possible to include the FriCAS coercion system, too?
It has some
On Fri, Mar 13, 2009 at 1:26 AM, Nicolas M. Thiery
wrote:
>
> On Thu, Mar 12, 2009 at 09:10:43PM -0700, Robert Bradshaw wrote:
>> > - I see 10*bla as (potentially) involving two independent things:
>> > coercion and multiple dispatch
>>
>> Yep, though in my mind they're a bit more intertwined
On Thu, Mar 12, 2009 at 09:10:43PM -0700, Robert Bradshaw wrote:
> > - I see 10*bla as (potentially) involving two independent things:
> >coercion and multiple dispatch
>
> Yep, though in my mind they're a bit more intertwined (e.g. for a \in
> Z, b \in QQ[x], one can do a*b by doing a coe
On Mar 12, 2009, at 8:47 PM, Nicolas M. Thiery wrote:
> Dear Robert,
>
> Hmmm. Quite an interesting discussion. Could anyone try to make some
> sort of synthesis of the different opinions expressed in this thread?
>
> On Thu, Mar 12, 2009 at 12:18:45PM -0700, Robert Bradshaw wrote:
>> As me
Dear Robert,
Hmmm. Quite an interesting discussion. Could anyone try to make some
sort of synthesis of the different opinions expressed in this thread?
On Thu, Mar 12, 2009 at 12:18:45PM -0700, Robert Bradshaw wrote:
> As mentioned, everything can be seen as a Z-module. This would mean
>
> And note that if the answer to the former question is yes, you lose
> this notational convenience:
>
> sage: K. = GF(5)[]
> sage: 2*x^2 + 3*x + 4
> 2*x^2 + 3*x + 4
>
> You would instead have to type 2*x^2 + 3*x + GF(5)(4).
There are languages that still allow that to work without coercion.
W
On Thu, Mar 12, 2009 at 3:53 PM, Robert Bradshaw wrote:
> ...
> But what I'm saying is that
>
> sage: GF(5)(3) == 3
> True
>
> Seems just as natural.
>
The reason that this seems natural is that it is a rather special case
involving a simple "literal".
Does the following
sage: a = 11
sage: GF(
On Thu, Mar 12, 2009 at 12:18 PM, Robert Bradshaw
wrote:
> So, to rephrase the question, does this mean that GF(5)(3) + 1 and RR
> (pi) + 1 should fail?
And note that if the answer to the former question is yes, you lose
this notational convenience:
sage: K. = GF(5)[]
sage: 2*x^2 + 3*x + 4
2*x^
On Thu, Mar 12, 2009 at 12:47 PM, Robert Bradshaw
wrote:
>
> On Mar 12, 2009, at 11:23 AM, Carl Witty wrote:
>> My suggestion in that thread of using "cmp" for sysorder is possible,
>> but I doubt if it's a good idea... it makes it easy to make
>> implementation mistakes, because by default cmp()
On Mar 12, 2009, at 12:44 PM, Florent Hivert wrote:
>> I guess "safe" is a matter of personal taste. I find
>>
>> sage: GF(5)(0) == 0
>> True
>> sage: GF(5)(1) == 1
>> True
>> sage: GF(5)(-1) == -1
>> True
>>
>> to be "safe," but it seems some people are really bothered by this
>> idea and would
On Mar 12, 2009, at 11:23 AM, Carl Witty wrote:
> On Thu, Mar 12, 2009 at 12:57 AM, Florent Hivert
> wrote:
>>
>> Dear Robert,
>>
>>> The issue here is that comparison is useful outside of the purely
>>> mathematical context--for example if one wants to sort a list (for
>>> printing or sear
> I guess "safe" is a matter of personal taste. I find
>
> sage: GF(5)(0) == 0
> True
> sage: GF(5)(1) == 1
> True
> sage: GF(5)(-1) == -1
> True
>
> to be "safe," but it seems some people are really bothered by this
> idea and would rather have to write "a == a.parent().coerce(1)"
I'd rath
On Mar 11, 2009, at 10:23 PM, Carl Witty wrote:
> On Wed, Mar 11, 2009 at 9:35 PM, Robert Bradshaw
> wrote:
>>> Here's some examples to hopefully clarify:
>>
>>
>>> RealField(20) -> RealField(50)
>>> RealField(20) -> RealIntervalField(20)
>>
>> I would call these dangerous,
I should clarify, it
On Mar 12, 2009, at 7:26 AM, Bill Page wrote:
> On Thu, Mar 12, 2009 at 12:35 AM, Robert Bradshaw wrote:
>>
>> OK, my last post on this tread for a while, I promise :).
>
> I hope no one is asking you to not post on this subject (priorities
> and time constraints notwithstanding)... :-(
No...it
> I do not understand this claim. As Ralf pointed out, there are good
> (i.e. "mathematical") reasons why it makes sense to multiply elements
> of GF(5) directly by integers. This has nothing to do with coercions
> or any other kind of type conversion per se. It makes sense to have
> this property
On Thu, Mar 12, 2009 at 12:57 AM, Florent Hivert
wrote:
>
> Dear Robert,
>
>> The issue here is that comparison is useful outside of the purely
>> mathematical context--for example if one wants to sort a list (for
>> printing or searching) or use elements in sets or as keys in
>> dictionarie
Dear Robert,
> The issue here is that comparison is useful outside of the purely
> mathematical context--for example if one wants to sort a list (for
> printing or searching) or use elements in sets or as keys in
> dictionaries or simply throw an error on an illegal value like 0.
Su
On Thu, Mar 12, 2009 at 7:26 AM, Bill Page wrote:
>> +10. Otherwise every element has huge if-else lists in every
>> __add__, __sub__, __mul__, etc. corresponding to the fixed list
>> various possibilities that the programer original programmer thought
>> of at the time, and then those who've add
On Thu, Mar 12, 2009 at 3:33 AM, Ralf Hemmecke wrote:
>>> Do I do something wrong or is autocoercion doing something strange
>>> here?
>>> In fact, I would have expected an error telling me that I cannot
>>> compare
>>> an element of K with any other thing.
>
>> This is nothing to do with coercio
On Thu, Mar 12, 2009 at 12:35 AM, Robert Bradshaw wrote:
>
> OK, my last post on this tread for a while, I promise :).
>
I hope no one is asking you to not post on this subject (priorities
and time constraints notwithstanding)... :-(
> On Mar 11, 2009, at 7:19 PM, Bill Page wrote:
>
>> On Wed, M
On 03/12/2009 04:34 AM, Robert Bradshaw wrote:
> Wow, this thread has generated a lot of discussion! :)
I am sorry for having started this. :-)
> On Mar 11, 2009, at 12:29 PM, Ralf Hemmecke wrote:
>
>> Some more oil for the fire...
>>
>> sage: K=NumberField(x^2+1, 'a'); K
>> Number Field in a w
>> Hmm. I have to think about it. For the moment, the only think I am
>> sure of: coercions should *always* be safe.
> Does this mean you want GF(5)(3)*2 and RR(pi)*2 to fail? These
> currently work due to coercions that would be unsafe according to my
> definition.
For R(3)*2 it seems reasonab
On Wed, Mar 11, 2009 at 9:35 PM, Robert Bradshaw
wrote:
>> Here's some examples to hopefully clarify:
>
>
>> RealField(20) -> RealField(50)
>> RealField(20) -> RealIntervalField(20)
>
> I would call these dangerous, as the latter implicitly has more
> "information" than the former.
No they don't
OK, my last post on this tread for a while, I promise :).
On Mar 11, 2009, at 7:19 PM, Bill Page wrote:
> On Wed, Mar 11, 2009 at 10:13 PM, David Roe wrote:
>> On Wed, Mar 11, 2009 at 9:53 PM, Bill Page wrote:
>>>
>>> On Wed, Mar 11, 2009 at 9:08 PM, Carl Witty wrote:
...
Does this mea
On Mar 11, 2009, at 5:47 PM, Nicolas M. Thiery wrote:
> On Wed, Mar 11, 2009 at 10:07:35AM -0800, Carl Witty wrote:
>>
>> On Tue, Mar 10, 2009 at 11:05 PM, Nicolas M. Thiery
>> wrote:
>>> I guess it all boils down to what are the convention for membership
>>> testing, and how much freedom one ha
On Mar 11, 2009, at 9:38 AM, Bill Page wrote:
>
> On Wed, Mar 11, 2009 at 12:15 PM, Georg S. Weber wrote:
>> On 11 Mrz., 14:06, Bill Page wrote:
>>
>>> I think the new coercion model in Sage is much too aggressive -
>>> especially as applied when coding. As Ralf said: perhaps it makes
>>> sense
On Mar 11, 2009, at 3:07 PM, Florent Hivert wrote:
> Dear Carl,
>
>> The paragraph you quoted was part of a very rough proposal for a way
>> that Sage's coercion might be changed in the future; it's definitely
>> not how it works now.
>
> My apologies for missing this.
>
>> Also, the way co
Wow, this thread has generated a lot of discussion! :)
On Mar 11, 2009, at 12:29 PM, Ralf Hemmecke wrote:
> Some more oil for the fire...
>
> sage: K=NumberField(x^2+1, 'a'); K
> Number Field in a with defining polynomial x^2 + 1
> sage: a = K.0
> sage: a
> a
> sage: a*a
> -1
> sage: a<1
> False
On Wed, Mar 11, 2009 at 10:13 PM, David Roe wrote:
> On Wed, Mar 11, 2009 at 9:53 PM, Bill Page wrote:
>>
>> On Wed, Mar 11, 2009 at 9:08 PM, Carl Witty wrote:
>> > ...
>> > Does this mean you want GF(5)(3)*2 and RR(pi)*2 to fail? These
>> > currently work due to coercions that would be unsafe ac
On Wed, Mar 11, 2009 at 9:53 PM, Bill Page wrote:
>
> On Wed, Mar 11, 2009 at 9:08 PM, Carl Witty wrote:
> > ...
> > Does this mean you want GF(5)(3)*2 and RR(pi)*2 to fail? These
> > currently work due to coercions that would be unsafe according to my
> > definition.
> >
>
> The __mul__ method e
On Wed, Mar 11, 2009 at 9:08 PM, Carl Witty wrote:
> ...
> Does this mean you want GF(5)(3)*2 and RR(pi)*2 to fail? These
> currently work due to coercions that would be unsafe according to my
> definition.
>
The __mul__ method exported by GF(5) could accept integers as well as
elements of GF(5)
On Wed, Mar 11, 2009 at 5:47 PM, Nicolas M. Thiery
wrote:
>
> On Wed, Mar 11, 2009 at 10:07:35AM -0800, Carl Witty wrote:
>> If you want (4), I think you should just write x.parent() == P (or if
>> you know that P is unique, x.parent() is P).
>
> Yup. The question is: am I allowed to do it?
I'm
On Wed, Mar 11, 2009 at 10:07:35AM -0800, Carl Witty wrote:
>
> On Tue, Mar 10, 2009 at 11:05 PM, Nicolas M. Thiery
> wrote:
> > I guess it all boils down to what are the convention for membership
> > testing, and how much freedom one has in implementing it.
> >
> > Here are some typical options
On Wed, Mar 11, 2009 at 01:52:31PM -0800, Carl Witty wrote:
>
> On Wed, Mar 11, 2009 at 1:42 PM, Georg S. Weber
> wrote:
> > But would you find it helpful to have the possibility to let it act
> > either "as gracefully as possible", or to "print out verbose
> > warnings" (coercions have costs, s
On Wed, Mar 11, 2009 at 2:08 PM, Bill Page wrote:
>
> On Wed, Mar 11, 2009 at 5:52 PM, Carl Witty wrote:
>> This sounds potentially very useful; but option 3 ("do a strict subset
>> of coercions/conversions, and stop otherwise") is also tricky to
>> implement. For instance, if you had a mode whe
On Wed, Mar 11, 2009 at 5:52 PM, Carl Witty wrote:
>
> On Wed, Mar 11, 2009 at 1:42 PM, Georg S. Weber
> wrote:
>> But would you find it helpful to have the possibility to let it act
>> either "as gracefully as possible", or to "print out verbose
>> warnings" (coercions have costs, so if the cost
Dear Carl,
> The paragraph you quoted was part of a very rough proposal for a way
> that Sage's coercion might be changed in the future; it's definitely
> not how it works now.
My apologies for missing this.
> Also, the way coercion is implemented now, int(2) does have a parent;
> it's
On Wed, Mar 11, 2009 at 1:42 PM, Georg S. Weber
wrote:
> But would you find it helpful to have the possibility to let it act
> either "as gracefully as possible", or to "print out verbose
> warnings" (coercions have costs, so if the costs are higher than a
> specific amount, this could trigger an
Hi all,
we do not seem to understand each other well enough (especially Bill
and me). Yet. :-) Let's try an analogy. When compiling C code, you can
tell the compiler to "silently skip over warnings"; or to "print out
verbose warnings, but to continue"; or to "treat all warnings like
errors and st
On Wed, Mar 11, 2009 at 12:11 PM, Florent Hivert
wrote:
>> Then "x in P" means that there is a safe conversion from the parent of
>> x to P. If this is actually a coercion, then you don't even have to
>> run it; if it's a conversion, then you do have to run it, to test that
>> the conversion is
Dear Carl.
> > I definitely see your point. Well, without introducing a hierarchy,
> > there is this natural notion of invertible coercions (strongly
> > connected components in the conversion graph). But that would not have
> > helped anyway for 4/2 in ZZ. Here it's more about a notion of
On Wed, Mar 11, 2009 at 11:29 AM, Ralf Hemmecke wrote:
>
> Some more oil for the fire...
>
> sage: K=NumberField(x^2+1, 'a'); K
> Number Field in a with defining polynomial x^2 + 1
> sage: a = K.0
> sage: a
> a
> sage: a*a
> -1
> sage: a<1
> False
> sage: a>1
> True
> sage: 1 False
> sage: 1>a
>
Some more oil for the fire...
sage: K=NumberField(x^2+1, 'a'); K
Number Field in a with defining polynomial x^2 + 1
sage: a = K.0
sage: a
a
sage: a*a
-1
sage: a<1
False
sage: a>1
True
sage: 1a
True
sage: version()
'Sage Version 3.3, Release Date: 2009-02-21'
Do I do something wrong or is autocoe
On Tue, Mar 10, 2009 at 11:05 PM, Nicolas M. Thiery
wrote:
> I guess it all boils down to what are the convention for membership
> testing, and how much freedom one has in implementing it.
>
> Here are some typical options:
>
> (1) x is in P if there is an element of P that is equal to x under ==
On Wed, Mar 11, 2009 at 12:15 PM, Georg S. Weber wrote:
> On 11 Mrz., 14:06, Bill Page wrote:
>
>> I think the new coercion model in Sage is much too aggressive -
>> especially as applied when coding. As Ralf said: perhaps it makes
>> sense for interactive use. Would it be possible to enable/disa
On 11 Mrz., 14:06, Bill Page wrote:
> Nicolas M. Thiéry wrote:
> > In short: for < = in, if it was just me, I would only use the most
> > absolutely trivial coercions. And in particular avoid there all the
> > coercions that involve projections and not embedding (like Z -> Z/nZ)
>
> +1
>
-1
>
Nicolas M. Thiéry wrote:
> In short: for < = in, if it was just me, I would only use the most
> absolutely trivial coercions. And in particular avoid there all the
> coercions that involve projections and not embedding (like Z -> Z/nZ)
+1
I think the new coercion model in Sage is much too aggre
On Wed, Mar 11, 2009 at 08:27:14AM +0100, Ralf Hemmecke wrote:
>
> > In short: for < = in, if it was just me, I would only use the most
> > absolutely trivial coercions. And in particular avoid there all the
> > coercions that involve projections and not embedding (like Z -> Z/nZ)
>
> > Just my
> In short: for < = in, if it was just me, I would only use the most
> absolutely trivial coercions. And in particular avoid there all the
> coercions that involve projections and not embedding (like Z -> Z/nZ)
> Just my own feeling ...
And mine.
Ralf
--~--~-~--~~~-
On Tue, Mar 10, 2009 at 06:27:41PM -0700, Robert Bradshaw wrote:
> Currently the rule is that if you can do arithmetic between two
> elements, you can compare them.
Ok, I am not used to it, but this seems fair enough.
> Membership code is something entirely different.
>
> > I typically write
> Currently the rule is that if you can do arithmetic between two
> elements, you can compare them. Membership code is something entirely
> different.
Very mathematical... Is the imaginary i bigger or smaller than 1?
[snip]
> Membership is much more lenient than coercion, for example, I wou
On 03/11/2009 12:49 AM, Nicolas M. Thiery wrote:
[snip]
> In short: for < = in, if it was just me, I would only use the most
> absolutely trivial coercions. And in particular avoid there all the
> coercions that involve projections and not embedding (like Z -> Z/nZ)
>
> Just my own feeling ...
On Mar 10, 2009, at 4:49 PM, Nicolas M. Thiery wrote:
>> Because it's really inconvenient to always have to manually cast to
>> the same parent. Imagine I have a loop.
>>
>> while a < 1:
>> [do stuff to a to make it smaller]
>>
>> Would this fail if a was not an integer. What if it started o
> Because it's really inconvenient to always have to manually cast to
> the same parent. Imagine I have a loop.
>
> while a < 1:
> [do stuff to a to make it smaller]
>
> Would this fail if a was not an integer. What if it started out as an
> integer but then I divided it by something an
Hi,
the notions "parent" and "element" are programmer's notions rather
than mathematical ones. They are natural if you look through the
object-oriented glasses.
Mathematically, one could build "everything" purely out of set-theory,
and would have sets, power-sets, power-power-sets and their powe
On Mar 10, 2009, at 11:36 AM, Ralf Hemmecke wrote:
> And the reason is...?
Because it's really inconvenient to always have to manually cast to
the same parent. Imagine I have a loop.
while a < 1:
[do stuff to a to make it smaller]
Would this fail if a was not an integer. What if it star
And the reason is...?
Ralf
On 03/10/2009 07:34 PM, Robert Bradshaw wrote:
> For the same reason that
>
> sage: z = ZZ(2)
> sage: parent(z)
> Integer Ring
> sage: q = QQ(2)
> sage: parent(q)
> Rational Field
> sage: z == q
> True
> sage: p = ZZ['x'](2)
> sage: p == z
> True
>
>
> On Mar 10, 20
For the same reason that
sage: z = ZZ(2)
sage: parent(z)
Integer Ring
sage: q = QQ(2)
sage: parent(q)
Rational Field
sage: z == q
True
sage: p = ZZ['x'](2)
sage: p == z
True
On Mar 10, 2009, at 11:23 AM, Ralf Hemmecke wrote:
>
> Can somebody give me a convincing reason why I see True in the
64 matches
Mail list logo
