I've posted a new patch at http://trac.sagemath.org/sage_trac/ticket/13393,
if anyone wants to help review.
On Wednesday, 19 September 2012 11:55:24 UTC-7, Chris wrote:
>
> It was pointed out to me that vector normalization in Sage is not doing
> what most people would think it should do. Rather
On Dec 1, 12:08 pm, John Cremona wrote:
> This makes it hard to see why projective coordinates are normalised
> sage: ProjectiveSpace(QQ,2)(list(v))
> (2/5 : 3/5 : 1)
I think this has its roots in mathematical tradition. Taking
coordinates (x,y) on affine space and homogenizing via (x,y)=(X/Z,Y/Z
On 1 December 2012 19:29, Eviatar wrote:
> Hmm, I think I agree.
>
> Why does leading_coefficient() behave backwards anyway?
>
Here's a plausible guess: think of polynomials which are determined
by a list of coefficients in which te i'th element of the list,
starting at 0, gives the coefficient
Hmm, I think I agree.
Why does leading_coefficient() behave backwards anyway?
On Saturday, 1 December 2012 04:44:10 UTC-8, John Cremona wrote:
>
> I don't think "monicize" is a word. For polynomials, the function in
> Sage is called .monic():
>
> sage: x=polygen(QQ)
> sage: p=3*x+1
> sage: p
I don't think "monicize" is a word. For polynomials, the function in
Sage is called .monic():
sage: x=polygen(QQ)
sage: p=3*x+1
sage: p.monic()
x + 1/3
but I have also never heard of the use of monic for vectors. In any
case, there are (at least) two possible normalizations, depending on
whethe
Kannappan Sampath writes:
> Perhaps, I should explain my rationale for the terms I chose, my
> first preference is `echelonize(v)` (although I wrote it second)
> because, what the function returns amounts to its reduced row echelon
> form, if you think of it as 1 x n matrix.
My rationale for "m
On Fri, Nov 30, 2012 at 3:57 PM, Eviatar wrote:
> I think echelonize is a bit misleading, because it's not really doing
> Gaussian elimination. Besides, I think it would have to be rref to be
> consistent with matrices (it's reduced row echelon form, not simply row
> echelon form):
>
> sage: matr
I think echelonize is a bit misleading, because it's not really doing
Gaussian elimination. Besides, I think it would have to be rref to be
consistent with matrices (it's reduced row echelon form, not simply row
echelon form):
sage: matrix([0,3,4]).echelon_form()
[0 3 4]
sage: matrix([0,3,4]).r
On Fri, Nov 30, 2012 at 1:36 PM, Eviatar wrote:
> Hello,
>
> I was planning to work on the patch for this; however, is "normal form"
> known terminology for dividing a vector by the leading entry? A Google
> search returns no such use. Wouldn't it be better for it to be named
> something like div
Perhaps, I should explain my rationale for the terms I chose, my first
preference is `echelonize(v)` (although I wrote it second) because, what
the function returns amounts to its reduced row echelon form, if you think
of it as 1 x n matrix.
~KnS.
On Sat, Dec 1, 2012 at 3:47 AM, Keshav Kini wr
On 11/30/12 3:36 PM, Eviatar wrote:
I was planning to work on the patch for this; however, is "normal form"
known terminology for dividing a vector by the leading entry? A Google
search returns no such use. Wouldn't it be better for it to be named
something like divided_by_leading, to remove ambi
Kannappan Sampath writes:
> Here's a "natural" place where I can see this is helpful:
>
> To carry out, Gauss-Jordan like row reductions, where you'd like the
> first non-zero entry in a row (the so-called pivot) to be 1, I think
> this is very helpful.
>
> So, I'd be **for** keeping this, perhap
Here's a "natural" place where I can see this is helpful:
To carry out, Gauss-Jordan like row reductions, where you'd like the first
non-zero entry in a row (the so-called pivot) to be 1, I think this is very
helpful.
So, I'd be **for** keeping this, perhaps in a different name, that would
reflec
Hello,
I was planning to work on the patch for this; however, is "normal form"
known terminology for dividing a vector by the leading entry? A Google
search returns no such use. Wouldn't it be better for it to be named
something like divided_by_leading, to remove ambiguity and potential
confus
+1
Travis
On Saturday, September 22, 2012 8:16:57 PM UTC-7, jason wrote:
>
> On 9/22/12 4:31 AM, Volker Braun wrote:
> > 1) deprecate normalize() and point to normalization() and normal_form()
> > 2) normalization() is division by L2-norm
> > 3) normal_form() is the old normalize()
>
> How a
On Sunday, September 23, 2012 4:16:57 AM UTC+1, jason wrote:
> On 9/22/12 4:31 AM, Volker Braun wrote:
> > 1) deprecate normalize() and point to normalization() and normal_form()
> > 2) normalization() is division by L2-norm
> > 3) normal_form() is the old normalize()
>
> How about normalized(
On 9/22/12 4:31 AM, Volker Braun wrote:
1) deprecate normalize() and point to normalization() and normal_form()
2) normalization() is division by L2-norm
3) normal_form() is the old normalize()
How about normalized() instead of normalization(). That is more like
the sorted builtin that is the
On Saturday, September 22, 2012 5:31:01 AM UTC-4, Volker Braun wrote:
>
> On Saturday, September 22, 2012 10:16:30 AM UTC+1, Charles Bouillaguet
> wrote:
>
>> Isn't v.norm() supposed to denote the… norm of v ?
>
>
> Good point, I knew that at one point ;-)
>
> So I'm actually proposing:
>
> 1)
On Saturday, September 22, 2012 10:16:30 AM UTC+1, Charles Bouillaguet
wrote:
> Isn't v.norm() supposed to denote the… norm of v ?
Good point, I knew that at one point ;-)
So I'm actually proposing:
1) deprecate normalize() and point to normalization() and normal_form()
2) normalization() is
On Sep 22, 2012, at 11:12 AM, Volker Braun wrote:
> On Saturday, September 22, 2012 2:11:08 AM UTC+1, Travis Scrimshaw wrote:
> normal_form() is good, and to be standard with the other code packages I've
> seen, dividing by the L2-norm should be normalize().
>
> As Robert pointed out, normalize
On Saturday, September 22, 2012 2:11:08 AM UTC+1, Travis Scrimshaw wrote:
> normal_form() is good, and to be standard with the other code packages
> I've seen, dividing by the L2-norm should be normalize().
As Robert pointed out, normalize() is bad because the name implies that the
vector is m
On Wednesday, September 19, 2012 12:09:34 PM UTC-7, Volker Braun wrote:
>
> +1 to:
>
> * rename v.normalization() -> v.normal_form() unless somebody has a better
> name
> * replace v.normalization() with he usual division by L2-norm.
>
normal_form() is good, and to be standard with the other co
On Wed, Sep 19, 2012 at 8:31 PM, Rob Beezer wrote:
> On Wednesday, September 19, 2012 1:52:24 PM UTC-7, Robert Bradshaw wrote:
>>
>> There is the issue that norm(v) does not always (often?) live in v for
>> exact v. Dropping to SR can be really slow, as can dropping to
>> QQ[sqrt(norm(v))], especi
On Wednesday, September 19, 2012 1:52:24 PM UTC-7, Robert Bradshaw wrote:
> There is the issue that norm(v) does not always (often?) live in v for
> exact v. Dropping to SR can be really slow, as can dropping to
> QQ[sqrt(norm(v))], especially if several vectors are normalized then
> used toget
On Wed, Sep 19, 2012 at 2:02 PM, Jason Grout
wrote:
> On 9/19/12 3:51 PM, Robert Bradshaw wrote:
>>
>> Even better if we can avoid re-using the name.
>
>
> So you mean permanently deprecating .normalize? Or do you mean leaving
> .normalize() and also having .normal_form() and .normalization()? O
On 9/19/12 3:51 PM, Robert Bradshaw wrote:
Even better if we can avoid re-using the name.
So you mean permanently deprecating .normalize? Or do you mean leaving
.normalize() and also having .normal_form() and .normalization()? Or do
you mean something different?
This is similar to .kernel
On Wed, Sep 19, 2012 at 1:39 PM, Jason Grout
wrote:
> On 9/19/12 2:09 PM, Volker Braun wrote:
>>
>> +1 to:
>>
>> * rename v.normalization() -> v.normal_form() unless somebody has a
>> better name
>> * replace v.normalization() with he usual division by L2-norm.
>>
>
> +1, except I think it's v.nor
On 9/19/12 2:09 PM, Volker Braun wrote:
+1 to:
* rename v.normalization() -> v.normal_form() unless somebody has a
better name
* replace v.normalization() with he usual division by L2-norm.
+1, except I think it's v.normalize(), not v.normalization().
Thanks,
Jason
--
You received this
On Wednesday, September 19, 2012 8:50:17 PM UTC+1, Robert Bradshaw wrote:
> would we have a period where it gives a warning
>
I think the deprecation warnings should be a help to the user and not a
sacrifice to the gods of backwards compatibility. If the method name
changed and is now something
+1, though it's difficult to change the meaning of an existing
function (would we have a period where it gives a warning?).
On Wed, Sep 19, 2012 at 12:09 PM, Volker Braun wrote:
> +1 to:
>
> * rename v.normalization() -> v.normal_form() unless somebody has a better
> name
> * replace v.normalizat
On Wednesday, September 19, 2012 3:09:34 PM UTC-4, Volker Braun wrote:
>
> +1 to:
>
> * rename v.normalization() -> v.normal_form() unless somebody has a better
> name
> * replace v.normalization() with he usual division by L2-norm.
>
And perhaps have a warning to be printed for the next 12 mon
+1 to:
* rename v.normalization() -> v.normal_form() unless somebody has a better
name
* replace v.normalization() with he usual division by L2-norm.
You can't deprecate the change gradually, but sometimes things have to
change to improve.
On Wednesday, September 19, 2012 7:55:24 PM UTC+1, C
32 matches
Mail list logo
