[sage-devel] Re: Coercion and categories in SAGE
Interestingly enough, William and I were just talking about the coercion model today. The issue came up when deciding how to apply the sqrt() operator to, say, the rational number 2. Currently it returns a decimal approximation, and as of 2.5 it returns an element of the symbolic expressions ring. Both have serious drawbacks. Ideally one would get something in a number field, but then the issue comes up how to handle all the coercions. A couple of points on square root. First, sqrt() and square_root() can have different behavior. I think there are three possible behaviours one might want: 1. Return a real approximation. The main plus on this option is that this is what many users will want if they ask for sqrt(2). 2. Return an element of a quadratic extension. We can then have one of the completions (or one of the pair of complex embeddings) be distinguished. This just means that there's an automatic coercion from QQ[sqrt(2)] to RR given by choosing the positive square root. While not really canonical mathematically, it's sufficiently standard that we should put it in. Users who want the other embedding will be able to get it fairly easily. 3. Return an integer (or rational) if n is a perfect square or throw and error otherwise. This kind of behavior currently exists for finite fields for example. My inclination would be to have sqrt do the first, and square_root the second. Since 2 makes sense for pretty much every integral domain (return x in the ring R[x]/(x^2 - a) if a does not have a square root in R), maybe have square_root do that, and sqrt() return an element of an algebraic completion for fields, and have behavior 3 for rings? Essentially, what we came up with is that (extra) implicit coercion morphisms could be specified at ring (object) creation time, which would be extra data attached to that specific ring, and the coercion model would detect and use those. I think I like using commutative diagrams better. Also, one could implement a ambient_parent() method who would (if possible) return a new parent together with injections from each of the original rings. The lattice of number fields stuff would be used here. Yeah: an ambient_parent method could make sense in a CoercionEnvironment (the minimal element among things mapped to from both, if such exists, or error if there this element doesn't exist or is not unique). I like the idea of being able to use python contexts. I don't know how efficient one could make it though. In terms of efficiency, for elements with the same parent, there will be no performance hit. After that, I don't think a context would slow stuff down much if you did it right. I think the inner context would take precedence. Agreed. I really like the idea of having a commutative diagram graph too. How would it get created? Would every ring, on creation time, try and update the commutative diagram to include itself? The more I think about it, the more having the (cached) has_coerce_map_from() function return an actual homomorphism (or None) seems to make sense. Thus one would traverse the graph only once. Yeah, I was thinking that too. I'd like to center the discussion on categories for a bit. Since implicit coercion maps are supposed to be morphisms, they properly have a category attached to them. So really, we should be asking: If R and S are objects of a category C, we want to pick a distinguished element of $Hom_C(R, S)$. So, given two parents R and S, we choose a category C with a forgetful functor to the category of parents and return a morphism in $Hom_C(R, S)$. So how do we implement CoercionEnvironments? Every parent object implements a function called _coercion_categories() which returns a list of categories that parent belongs to. It doesn't have to be all categories that that parent belongs to (clearly), but these categories will be the only ones considered by the coercion code. The default implementation is to just return the category of Parents (is this the same category as the category Sets? I'm not sure...), and every implementation should return Parents as one of the members of the list. By a descendant of a category C I mean a category D such that there is a forgetful functor from D to C. By an entry point of a commutative diagram L in a category D I mean a morphism f in Hom_C(A, B) where B is an object in L and D is a descendant of C. Exit point is defined analogously. By an extended commutative diagram I mean a commutative diagram with a list of entry and exit points. Each CoercionEnvironment has the following fields: * an enclosing environment encl (another CoercionEnvironment) * a dictionary diagrams, with keys some collection of categories, and diagrams[cat] an extended commutative diagram in the category cat. * a dictionary coerce_maps so that we don't have to find coercion maps more than once. and a function find_coerce_map(R, S) that does the following: (note that the code below
[sage-devel] Re: Coercion and categories in SAGE
On Apr 27, 2007, at 12:50 AM, David Roe wrote:
A couple of points on square root. First, sqrt() and square_root()
can have different behavior. I think there are three possible
behaviours one might want:
1. Return a real approximation. The main plus on this option is
that this is what many users will want if they ask for sqrt(2).
2. Return an element of a quadratic extension. We can then have
one of the completions (or one of the pair of complex embeddings)
be distinguished. This just means that there's an automatic
coercion from QQ[sqrt(2)] to RR given by choosing the positive
square root. While not really canonical mathematically, it's
sufficiently standard that we should put it in. Users who want the
other embedding will be able to get it fairly easily.
3. Return an integer (or rational) if n is a perfect square or
throw and error otherwise. This kind of behavior currently exists
for finite fields for example.
Exactly what we were thinking.
My inclination would be to have sqrt do the first, and square_root
the second. Since 2 makes sense for pretty much every integral
domain (return x in the ring R[x]/(x^2 - a) if a does not have a
square root in R), maybe have square_root do that, and sqrt()
return an element of an algebraic completion for fields, and have
behavior 3 for rings?
In terms of square roots (or nth roots, though (2) gets a bit more
complicated), sqrt != square_root is probably going away (I guess too
many other users found this confusing). I think the square_root
function should take a parameter to distinguish between the three
types (with default 2? One can always do sqrt(2.0) or RR(sqrt(2)),
etc. and I don't think causal users would be confused by \sqrt{2} as
an answer). One could have actual functions for the types too. E.g.
sqrt_approx, sqrt_extend, sqrt_exact(?).
Essentially, what we came up with is that (extra) implicit coercion
morphisms could be specified at ring (object) creation time, which
would be extra data attached to that specific ring, and the coercion
model would detect and use those.
I think I like using commutative diagrams better.
I think they're complimentary. For natural (or conventional)
morphisms I prefer commutative diagrams, but I think this would be
useful for creating, say, a number field with a specific embedding
into C. The commutative diagram itself should be immutable (in the
sense that adjacent edges are only added (deleted) as rings are
created (garbage collected).
As a specific example, what should sqrt(2) return? If the result lies
in a number field (or Z[\sqrt(2] or whatever) we would want to equip
this field with the extra information that the returned generator, by
convention, gets sent to the positive square root of two (for use if
one coerces into the symbolic ring or reals). The generic quadratic
extension should not come with this kind of a map.
Also, one could implement a
ambient_parent() method who would (if possible) return a new parent
together with injections from each of the original rings. The lattice
of number fields stuff would be used here.
Yeah: an ambient_parent method could make sense in a
CoercionEnvironment (the minimal element among things mapped to
from both, if such exists, or error if there this element doesn't
exist or is not unique).
Possibly one could be created too (like your number field examples).
I like the idea of being able to use python contexts. I don't know
how efficient one could make it though.
In terms of efficiency, for elements with the same parent, there
will be no performance hit. After that, I don't think a context
would slow stuff down much if you did it right.
After looking into the python context stuff more, I think I agree.
All the expensive stuff could be handled at context enter/exit. All
the (cached) information in the enclosing environment should be
merged into the current environment to avoid traveling up the tree
(as most coercions will probably still be defined at the outermost
level, and every hashtable lookup can be expensive compared to the
arithmetic itself.)
I think I understand your proposal below. What I'm not clear on is
how the entry/exit points do more than connect each separate category
graph into one large graph with edges for each (natural(ish))
homomorphism A - B in some suitably refined (wrt A and B) category.
This may not be well defined, but I think it is the best a computer
algebra system can do without forcing the user to do explicit
coercions all over.
(There is one advantage I see, namely that it favors coercions that
remain within the category, but I believe this could be done anyway
if there are several paths.) One can always extract the subgraph
corresponding to a specific category, but we're already mixing
categories with our objects (e.g. there is one object QQ that is used
for as an object in
[sage-devel] Re: Coercion and categories in SAGE
On 4/27/07, Robert Bradshaw [EMAIL PROTECTED] wrote:
A couple of points on square root. First, sqrt() and square_root()
can have different behavior.
After getting extensive user feedback, especially from younger
people, I've decided that having square_root and sqrt do different
things is very very confusing.
I think there are three possible
behaviours one might want:
1. Return a real approximation. The main plus on this option is
that this is what many users will want if they ask for sqrt(2).
It really depends. I would say that most normal users want
something symbolic when they type sqrt(2) and most engineers want
sqrt(2) as a floating point number.
2. Return an element of a quadratic extension. We can then have
one of the completions (or one of the pair of complex embeddings)
be distinguished. This just means that there's an automatic
coercion from QQ[sqrt(2)] to RR given by choosing the positive
square root. While not really canonical mathematically, it's
sufficiently standard that we should put it in. Users who want the
other embedding will be able to get it fairly easily.
Good.
3. Return an integer (or rational) if n is a perfect square or
throw and error otherwise. This kind of behavior currently exists
for finite fields for example.
Exactly what we were thinking.
My inclination would be to have sqrt do the first, and square_root
the second.
The fact we are even having this discussion illustrates that
square_root versus sqrt being different is confusing. Instead
we should have something like:
sqrt --- does number 2 above, or whatever the analogue is in
general, i.e., it tries to compute the square root as
exactly as possible. For lazy p-adics, it would be lazy,
for integers it would probably start by giving something
symbolic, then two weeks later, when number fields
improve, it would return a number field element exactly
as you suggest.
sqrt_exact -- tries to compute sqrt and raises an exception on
failure
sqrt_approx -- always returns a floating point square root.
This should be pushed throughout the system, and there should
also be functional notation for calling the above three. What do
you think?
Since 2 makes sense for pretty much every integral
domain (return x in the ring R[x]/(x^2 - a) if a does not have a
square root in R), maybe have square_root do that, and sqrt()
return an element of an algebraic completion for fields, and have
behavior 3 for rings?
Yes to the first in most cases. I don't know what algebraic
completion means.
In terms of square roots (or nth roots, though (2) gets a bit more
complicated), sqrt != square_root is probably going away (I guess too
many other users found this confusing).
Yes, it is definitely going away.
I think the square_root
function should take a parameter to distinguish between the three
types (with default 2? One can always do sqrt(2.0) or RR(sqrt(2)),
etc. and I don't think causal users would be confused by \sqrt{2} as
an answer). One could have actual functions for the types too. E.g.
sqrt_approx, sqrt_extend, sqrt_exact(?).
Yes. That's almost exactly what I proposed above. I prefer
different function names, since the return results are so
different, and since there are three options. If it were just
one could have
def sqrt(self, exact=True, extend=True):
...
but it gets complicated because if exact=False, you also need
to be able to pass in an optional precision parameter. I think
I prefer three separate functions:
sqrt_approx, sqrt, sqrt_exact.
Essentially, what we came up with is that (extra) implicit coercion
morphisms could be specified at ring (object) creation time, which
would be extra data attached to that specific ring, and the coercion
model would detect and use those.
I think I like using commutative diagrams better.
I think they're complimentary. For natural (or conventional)
morphisms I prefer commutative diagrams, but I think this would be
useful for creating, say, a number field with a specific embedding
into C. The commutative diagram itself should be immutable (in the
sense that adjacent edges are only added (deleted) as rings are
created (garbage collected).
Our idea was more that this diagram gets created at
runtime as references between objects. Having a separate
object (derived from graph) is more powerful though, since you
can compute the transitive closure, etc., and ensure that
various axiom are satisfied.
As a specific example, what should sqrt(2) return? If the result lies
in a number field (or Z[\sqrt(2] or whatever) we would want to equip
this field with the extra information that the returned generator, by
convention, gets sent to the positive square root of two (for use if
one coerces into the symbolic ring or reals). The generic quadratic
extension should not come with this kind of a map.
sqrt(2) could be an
[sage-devel] elliptic curve height bounds
Hi, John Cremona has implemented a wide range of height bounds for elliptic curves in this magma program: http://www.maths.nott.ac.uk/personal/jec/ftp/progs/magma/nfhtbound.m Upon my request he GPL'd this program. Thus we can legally port it line-by-line to SAGE. Would anybody like to volunteer to do this? I've listed this as trac ticket #360: http://www.sagemath.org:9002/sage_trac/ticket/360 william -- William Stein Associate Professor of Mathematics University of Washington http://www.williamstein.org --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Coercion and categories in SAGE
On Apr 27, 2007, at 7:32 AM, William Stein wrote:
I think the square_root
function should take a parameter to distinguish between the three
types (with default 2? One can always do sqrt(2.0) or RR(sqrt(2)),
etc. and I don't think causal users would be confused by \sqrt{2} as
an answer). One could have actual functions for the types too. E.g.
sqrt_approx, sqrt_extend, sqrt_exact(?).
Yes. That's almost exactly what I proposed above. I prefer
different function names, since the return results are so
different, and since there are three options. If it were just
one could have
def sqrt(self, exact=True, extend=True):
...
but it gets complicated because if exact=False, you also need
to be able to pass in an optional precision parameter. I think
I prefer three separate functions:
sqrt_approx, sqrt, sqrt_exact.
Having a single function with parameters means one could pass the
parameters on, e.g. in the sqrt function for power series, on needs
to take the square root of the leading coefficient. This would let
one write more generic code. Also, the global sqrt could take
parameters too. Perhaps
def sqrt(self, precision=None, extend=True):
I think this would be in addition to the named parameters.
sqrt(2) could be an element of the number field K=Q[x]/(x^2-2)
*equipped* with an embedding map K -- SR that sends x to
the symbolic ring element sqrt(2). We could also equip K with maps
to RR, CC, etc., by choosing a root to some precision (which would
choose a root to any bigger precision automatically). More generally,
at creation time one could equip any ParentWithGens object with
a list of embedding morphisms that should be used by the coercion
system automatically. This list is would be immutable. So there
would be a new number field class NumberField_with_embedding(s).
I think this should be an ability of any parent (with gens?), and one
would not necessarily have to create a new class
NumberField_with_embeddings.
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---
[sage-devel] Re: elliptic curve height bounds
On Apr 27, 2007, at 12:54 PM, David Roe wrote: I'd be happy to do it. Having just read through the code, it looks like it shouldn't be hard, with the following potential hangups: Does SAGE have Tamagawa numbers, Kodaira symbols and minimal models for elliptic curves? Yes I believe these are all supplied by PARI, and elliptic curves (at least over Q) already have methods for all of them. david --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Python Access Control module?
On 4/26/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Does anybody know of some sort of kitchen-sink type of authentication module that's commonly used in python? For the notebook, I've had to write my own, and it stinks -- any time a new feature is added, we forget to lock it down, and it isn't at all robust or configurable. It would seem that Yi is having to write his own, too (granted, it sounds like he's thought about it a lot more than I have). Can anybody suggest a pre-existing package that just works? Googling aroung, I found this: http://www.chrisarndt.de/en/software/python/#auth This Python module collection provides functions and classes for authentication purposes and user database management. Also included are some command line scripts, examples and pydoc generated API documentation. I don't know if it works though :) . More web frameworks for python can be found here: http://wiki.python.org/moin/WebFrameworks Also, doesn't Twisted have an authentication module? I haven't used it, but it's the first thing I thought about when you posted this. didier --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: elliptic curve height bounds
On 4/27/07, David Roe [EMAIL PROTECTED] wrote: I'd be happy to do it. Having just read through the code, it looks like it shouldn't be hard, with the following potential hangups: Does SAGE have Tamagawa numbers, Kodaira symbols and minimal models for elliptic curves? Over QQ, yes. Not over QQ, I think SAGE has nothing yet, which is a huge gap in functionality... This would be another good project for somebody. I've assigned trac #360 to you. Thanks for volunteering! I need to think a bit about the syntax for completions of number fields at prime ideals in SAGE. This is impacted be the ongoing discussion of augmenting the coercion model. David On 4/27/07, William Stein [EMAIL PROTECTED] wrote: Hi, John Cremona has implemented a wide range of height bounds for elliptic curves in this magma program: http://www.maths.nott.ac.uk/personal/jec/ftp/progs/magma/nfhtbound.m Upon my request he GPL'd this program. Thus we can legally port it line-by-line to SAGE. Would anybody like to volunteer to do this? I've listed this as trac ticket #360: http://www.sagemath.org:9002/sage_trac/ticket/360 william -- William Stein Associate Professor of Mathematics University of Washington http://www.williamstein.org -- William Stein Associate Professor of Mathematics University of Washington http://www.williamstein.org --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Coercion and categories in SAGE
On 4/27/07, Robert Bradshaw [EMAIL PROTECTED] wrote: Yes. That's almost exactly what I proposed above. I prefer different function names, since the return results are so different, and since there are three options. If it were just one could have def sqrt(self, exact=True, extend=True): ... but it gets complicated because if exact=False, you also need to be able to pass in an optional precision parameter. I think I prefer three separate functions: sqrt_approx, sqrt, sqrt_exact. Having a single function with parameters means one could pass the parameters on, e.g. in the sqrt function for power series, on needs to take the square root of the leading coefficient. This would let one write more generic code. Also, the global sqrt could take parameters too. Perhaps def sqrt(self, precision=None, extend=True): I think this would be in addition to the named parameters. That's a very very good point. I'm convinced. Thanks for counter-argiing this point. sqrt(2) could be an element of the number field K=Q[x]/(x^2-2) *equipped* with an embedding map K -- SR that sends x to the symbolic ring element sqrt(2). We could also equip K with maps to RR, CC, etc., by choosing a root to some precision (which would choose a root to any bigger precision automatically). More generally, at creation time one could equip any ParentWithGens object with a list of embedding morphisms that should be used by the coercion system automatically. This list is would be immutable. So there would be a new number field class NumberField_with_embedding(s). I think this should be an ability of any parent (with gens?), and one would not necessarily have to create a new class NumberField_with_embeddings. -- William Stein Associate Professor of Mathematics University of Washington http://www.williamstein.org --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: elliptic curve height bounds
On 4/27/07, Prof. J. E. Cremona [EMAIL PROTECTED] wrote: I think you (we) need to work out a sensible order for doing these things. As far as I know the functionality for elliptic curves over Q in SAGE comes from my C++ code -- what if anything has been written in native SAGE code? A lot of functionality comes from the PARI C library, but there's also a lot written in native SAGE code, e.g., the group law, invariants of curves, computation of p-adic regulators and p-adic L-series, and computation of complex L-series. However, there's nothing nontrivial along the lines of Tate's algorithm etc. over number fields yet. For elliptic curves over number fields, I implemented Tate's algorithm in Magma and can provide the code for that too (it is now in the standard Magma release) as I did for the heights. Excellent -- many thanks! This gives conductors, Tamagawa numbers, local minimal models, ... It does not use local fields, as instead of using completions at primes it uses localization instead. In practice all that means is that when finding a minimal model for a curve at a prime ideal P which may not be principal, it needs to be provided with a uniformiser pi at P, which is an element with valuation 1 at P (but which may have nonzero valuation at other primes if P is not principal). While I remember, the builtin Magma function for that always gives an integral element pi, which is actually not the most convenient; for then, pi may have positive valuations at other primes, and then at the stage in the akgorithm where the coefficient a_i is divided by pi^i the model becomes nonintegral (even if it was originally integral). Better would be to take pi to have negative valuations at other primes if necessary (let I be an ideal in the same class as P and coprime to P and take pi to be a generator of the fractional ideal P/I). This is why the output of Magma's LocalMinimalModel function is nonintegral for nonprincipal primes, in case anyone is interested! I will fix that before sending the code (+GPL) to William. Excellent. Thanks. William --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: elliptic curve height bounds
On Apr 27, 2007, at 09:16 , William Stein wrote: Hi, John Cremona has implemented a wide range of height bounds for elliptic curves in this magma program: http://www.maths.nott.ac.uk/personal/jec/ftp/progs/magma/ nfhtbound.m Upon my request he GPL'd this program. Thus we can legally port it line-by-line to SAGE. Would anybody like to volunteer to do this? I've listed this as trac ticket #360: http://www.sagemath.org:9002/sage_trac/ticket/360 I'd like to take a crack at it (as long as I'm not getting in someone else's way). Justin -- Justin C. Walker, Curmudgeon-At-Large Institute for the Enhancement of the Director's Income Experience is what you get when you don't get what you want. --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: elliptic curve height bounds
On Apr 27, 2007, at 15:50 , Justin C. Walker wrote: On Apr 27, 2007, at 09:16 , William Stein wrote: [snip] I'd like to take a crack at it (as long as I'm not getting in someone else's way). Rats. Mac OS's Mail has a bolluxed threading scheme, so I didn't see the trail of mail following William's request. Never mind. Justin -- They said it couldn't be done but sometimes it doesn't work out that way. - Casey Stengel -- --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Repent, Completely trust in God only and, Love Him with all of your heart.
This poster has been banned and the post deleted but for some reason google's report post as spam feature is not working. On 4/27/07, Secret [EMAIL PROTECTED] wrote: If you are an atheist, please read the section below with the title Why Atheism and Evolution are not good ideas. All those who have sinned deserve to suffer in Hell forever. Therefore... 1. Repent (be truly sorry for your sins and do your best to stop sinning). 2. Trust completely in the Lord only, and do not trust in your own self. 3. Love the Lord your God with all of your heart. The Lord sent His only Son (the Lord Jesus Christ), to suffer and die on the cross, to pay for the sins of those who trust in Him. His blood poured out, and it can clean away our sins. He was buried, then lived again after three days. Human works and Human efforts cannot save your soul. The gift of God is eternal life to those who completely trust in Him. Human beings are totally corrupt, but thankfully the Lord owns and controls all things. If He did not decide to save us from our sins, we will all be in Hell. Thank the Lord if He has chosen you unto salvation, and if His Spirit has transformed your heart so that you can trust in Him. By the way, Spontaneous Generation is impossible. Therefore, God created the heaven and the earth, including all living things. Those who do not believe in God must also repent. Repent, Trust, and Love. The Lord's will be done. You may distribute or share this article for the glory of the Lord. --- Why Atheism and Evolution are not good ideas: A. Spontaneous generation is impossible. B. Science cannot create nor totally destroy energy/matter. All honest physicists know that the universe is not permanent, and it surely had a beginning. C. Science cannot resurrect the clinically dead. D. There is order in the universe, not random chaos nor chances. Also, there is only one universe. E. All those who have sinned deserve to suffer in Hell forever. Atheism is terribly risky. F. Humans have a conscience, morals, and advanced intelligence, different from animals or beasts. G. Mutations are harmful and deadly, not useful as evolution requires. Cancer is an example of a mutation. H. There is strong evidence of a global flood in the past, when layers were formed quickly and catastrophically. There are also polystrata fossils. I. Living things are amazingly complex, including cells, many of which appear more advanced than modern space shuttles. Either the aliens designed humans, or a super-natural God did. J. Scientists cannot agree on the age of the Earth. There is strong evidence that the Earth is only thousands of years old. K. Archaeology and history prove that humanity has been here for only thousands of years (4000-6000 years). L. Fossils reveal large versions of modern-day creatures. There were dragonfiles with wing spans 3 feet long, which lived in the past. M. Evolution is highly questionable, and is a myth. The evolutionary ideas that fishes grew legs, and mice grew wings sound mythical. Also, the theory must include other creatures such as the centaur (human-horse), mermaids (fish-women), chimeras, fire-breathing comodo dragons, and gryphons (lion-like eagles). N. Scientists can use fraudulent or biased data. They cannot be trusted. O. DNA is a language. Languages require Intelligence. Therefore, an Intelligent Being made the DNA (language). P. Other reasons. --- Someone asked, Why is there evil and suffering in the world? If God made the living things, then why aren't we perfect? The answer is simple: Humans have sinned and are therefore under a curse. There is absolutely NO REASON why a happy and intelligent Theist (believer in God) should abandon his faith in the Lord. If an atheist refuses to trust in the Lord, it's NOT God's loss and it's NOT the Theist's loss. The Lord and the true believers live happily together whether people believe in them or not. --- Definitions: 1. Atheist - a person who believes that there is no God. 2. Agnostic - a person who is not sure if God exists or not. 3. Theist - believer in God. 4. Infidel, Unfaithful theist or a Doubter - A theist who is disloyal or disobedient, or has doubts about the Lord's actions. Atheists and theists are fundamentalists. They are sure of what they believe in. Since there is the strong possibility that God exists, atheism is nonsense. Repent. --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: [EMAIL PROTECTED]
My goal, come hell or high water: Notebook version 1. On Fri, 27 Apr 2007, David Joyner wrote: Hello SAGE people: This is proposal for 4th SAGE days 2007, to be held the week of June 11-16, 2007 (a Monday thru Saturday) in the Mathematics Department of the University of Washington in scenic Seattle. The focus will be on coding sprints, rather than talks on various SAGE-related topics. Namely, it is planned to be a developers workshop, with fewer general audience talks. If you think you can make it and are interested in attending, please email me ([EMAIL PROTECTED]) or this list. If there is sufficient interest, then we will try to get funding and take it from there. - David Joyner and William Stein --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: [EMAIL PROTECTED]
I'm interested. On 4/27/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: My goal, come hell or high water: Notebook version 1. On Fri, 27 Apr 2007, David Joyner wrote: Hello SAGE people: This is proposal for 4th SAGE days 2007, to be held the week of June 11-16, 2007 (a Monday thru Saturday) in the Mathematics Department of the University of Washington in scenic Seattle. The focus will be on coding sprints, rather than talks on various SAGE-related topics. Namely, it is planned to be a developers workshop, with fewer general audience talks. If you think you can make it and are interested in attending, please email me ([EMAIL PROTECTED]) or this list. If there is sufficient interest, then we will try to get funding and take it from there. - David Joyner and William Stein --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Coercion and categories in SAGE
On 4/27/07, David Roe [EMAIL PROTECTED] wrote: Having a single function with parameters means one could pass the parameters on, e.g. in the sqrt function for power series, on needs to take the square root of the leading coefficient. This would let one write more generic code. Also, the global sqrt could take parameters too. Perhaps def sqrt(self, precision=None, extend=True): I think this would be in addition to the named parameters. As with William, I agree that this is a good idea. We can have aliases sqrt_exact and sqrt_approx when they make sense (for example, rationals would have both, reals would have both, where sqrt_exact throws an error given a negative real while sqrt_approx returns a complex, Z/NZ would only have sqrt_exact and normal sqrt). Another issue with square roots for general rings is the following: what do we do when there is no commonly accepted choice of square root? Worse, what do we do when there are more than two choices (sqrt(mod(17, 32)) could return 7, 9, 23 or 25)? Pari's solution is to raise an error, GAP's solution is to return a list of all of them, and I bet there's some system out there that picks one. Why don't we have another flag, e.g., def sqrt(self, precision=None, extend=True, all=False): If all == True, return a list of all square roots. Otherwise just return 1, where we choose some documented convention in each case. sqrt(2) could be an element of the number field K=Q[x]/(x^2-2) *equipped* with an embedding map K -- SR that sends x to the symbolic ring element sqrt(2). We could also equip K with maps to RR, CC, etc., by choosing a root to some precision (which would choose a root to any bigger precision automatically). More generally, at creation time one could equip any ParentWithGens object with a list of embedding morphisms that should be used by the coercion system automatically. This list is would be immutable. So there would be a new number field class NumberField_with_embedding(s). I think this should be an ability of any parent (with gens?), and one would not necessarily have to create a new class NumberField_with_embeddings. This would be pretty easy to implement with a system like I described. Excellent. William --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
