Re: [sage-devel] Re: Re: Reviewing without dependencies

[Robert Bradshaw]

On Sat, Jan 4, 2014 at 6:04 AM, John Cremona  wrote:
> On 4 January 2014 13:24, Nathann Cohen  wrote:
>> Hellooo !!
>>
>>> Btw, I'm still not convinced by Volker's explanations,
>>
>> Well, by the look of that thread I don't think anybody but Volker was
>> actually convinced :-P
>>
>>> and the policy I
>>> was suggesting at the beginning of that thread still makes more sense to
>>> me. In summary, here's what I was suggesting:
>>>
>>> 1. The default diff/commits view of a ticket T linked from its trac page
>>>should be something like
>>>
>>>  git log --graph commit ^trac/develop ^dep1 ^dep2 ...
>>
>> Yes. A big "YES"
>>
>>
>>>where commit is the contents of T's Commit field and dep1, dep2...
>>>are the contents of the Commit fields of the tickets D1, D2... listed
>>>in T's Dependencies field.
>>>
>>>Setting T to positive_review means that the set of commits described
>>>by the above "git log" command has been reviewed.
>>
>> Indeed. Actually, now that I understand GIt better, it really feels like we
>> should not be reviewing branches but rewieving *COMMITS*. This way we would
>> know which commits we can use. Reviewing branches does not seem to make any
>> sense in a git workflow. I mean, it's the source of all problems we have
>> right now.
>
> This is quite logical, since a branch is a pointer to a commit and not
> some fixed thing, so if I say "I have reviewed branch u/x/y/z then it
> tells you absolutely nothing, while if I say that I am happy with
> commit a1b2c3d4... then it does refer to a specific snapshot of the
> code.  With the hg model we were reviewing patches, or sequences of
> patches considered as a single unit, and "positive review" meant
> something like "I approve of the combined effect of applying these
> patches".
>
> One difficulty with reviewing individual commits is that many of them
> are snapshots along the way to a finished piece of work.  For example,
> I am about to make a commit of some work I was in the middle of
> yesterday, so that I can come back to it later, while in the meantime
> I want to be able to change branches so that I can review some other
> tickets.  It would not make sense for that half-way commit to ever be
> reviewed in isolation.

I don't think commits need to be reviewed in isolation; if the ticket
is A+B+C I can just look at the diff master..C and give my +1 to the
set. This is actually more flexible than patches because I can look at
master...B and then B..C if that makes it easier.

> Of course, the half-way commit only exists on
> my own computer so I could rewrite local history later, but why should
> I bother?

Of course it's nice for history to be somewhat clean, but that's not a
requirement.

> Does it make sense for us to mark a specific commit as "ready for
> review" rather than a branch?  Working back through that commit's
> history one might pass by what I called half-way commits above, which
> could be ignored, until reaching either (1) a commit which has already
> been merged -- in which case the changes to be reviewed are the ones
> between that one and the current one;  or (2) a commit which is also
> tagged "ready for review"; or (3) a commit which has a positive
> review, which could be treated as in case (0).  Ok, I know that the
> number of cases here is more than the ones described;  but I have
> already found that when reviewing a ticket it has been necessary to
> say in the comment on trac exactly which commit I was looking at, and
> also when marking a ticket as ready for review I intend to always say
> which commit it is which I would like reviewed.  It would not be hard
> for trac to have fields showing that information?  You might think it
> redundant, but yesterday someone with initials JD made a new commit to
> a branch after I had started reviewing a ticket tagged "ready for
> review"!

Whenever the commit changes, that should result in a message on trac.
I suppose in the (rare?) case that two people are working on a ticket
at the same time like this, you could refer to the commit manually in
your comment, otherwise it is assumed that you're referring to the
commit that was active at that time. (Even better of course is in-line
comments.)

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sage-devel] Re: Re: Reviewing without dependencies

[Robert Bradshaw]

On Sat, Jan 4, 2014 at 10:00 AM, Volker Braun  wrote:
> On Saturday, January 4, 2014 3:16:08 AM UTC-10, Marc Mezzarobba wrote:
>>
>> 2. Any change to that set of commits (any change to T's Commit field,
>>any change to one of the D's Commit fields that modifies its most
>>recent common ancestor with T's Commit) automatically reverts T to
>>needs_review.
>
> And any non-fast-forwardable change to the dependencies of the dependencies
> reverts T to needs_review. And any subtraction from the list of dependencies
> (direct or indirect).

This would change the commit set. I would also say that if A+B+C was
given a positive review, that doesn't mean A+B is a positive review.

- Robert

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sage-devel] numbers in numpy fight sage

[Nils Bruin]

It's an odd confluence of circumstances that makes numpy.float64 behave 
this way. The code that causes the problem is this:

sage/structure/coerce.pyx:965 (cpdef canonical_coercion)
elif y_numeric:
try:
sage_parent = py_scalar_parent(type(y))
if sage_parent is None or 
sage_parent.has_coerce_map_from(xp):
return y.__class__(x), y
else:
return self.canonical_coercion(x, sage_parent(y))
except (TypeError, ValueError):
self._record_exception()

Some of the relevant facts:

sage: sage.structure.coerce.py_scalar_parent(type(np.float(1)))
Real Double Field
sage: sage.structure.coerce.py_scalar_parent(type(np.float64(1)))
None

but on the other hand, with  cython("def isnum(a): return PY_IS_NUMERIC(a)")

sage: isnum(np.float(1))
True
sage: isnum(np.float32(1))
False
sage: isnum(np.float64(1))
True
sage: isnum(np.float128(1))
False

So it seems to be the combination of "float64" being "numeric" but having 
no corresponding "sage scalar parent" defined for it. We have

#define PY_IS_NUMERIC(zzz_obj) \
 (PyInt_Check(zzz_obj) ||  PyBool_Check(zzz_obj) || 
PyLong_Check(zzz_obj) || \
   PyFloat_Check(zzz_obj) || PyComplex_Check(zzz_obj))

Indeed:

sage: isinstance(np.float64(1),float)
True
sage: isinstance(np.float32(1),float)
False
sage: isinstance(np.float128(1),float)
False
sage: isinstance(np.float(1),float)
True
sage: type(np.float(1))


so the problem is that float64 (at least on most machines) inherits from 
float but isn't exactly a float.

We can probably solve the problem by changing py_scalar_parent to check 
types via "isinstance" rather than comparison by "is". In the process, you 
can also type the argument "py_type" to be a "type". That will cause cython 
to generate more efficient code for "isinstance".

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sage-devel] Guys, it takes one minute to load every single page of trac. We have to do something about it.

[R. Andrew Ohana]

Ok, I just deployed the rewritten sage plugin, and removed all usage of the
trac git plugin. There are bound to be a few bugs, but hopefully trac will
be much faster now.


On Fri, Jan 3, 2014 at 10:26 AM, Nathann Cohen wrote:

> Yooo !
>
> > Don't thank me yet, you must have just had good luck. I'm planning on
> working on this today.
>
> Really ? You must have scared it, then. Something happened, I am sure ! :-P
>
> Nathann
>
> --
> You received this message because you are subscribed to the Google Groups
> "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sage-devel+unsubscr...@googlegroups.com.
> To post to this group, send email to sage-devel@googlegroups.com.
> Visit this group at http://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/groups/opt_out.
>



-- 
Andrew

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.

[sage-devel] Re: problems with testing sandpiles.py on 6.1b2

[Volker Braun]

This is now http://trac.sagemath.org/15631

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sage-devel] numbers in numpy fight sage

[Nils Bruin]

On Saturday, January 4, 2014 11:29:33 AM UTC-8, vdelecroix wrote:
>
> I do not see how we can make the coercion numpy int/Sage Integer works 
> if numpy is not loaded at startup time...

It seems more an issue of *ensuring* that coercion does *not* work, because 
we're communicating with a non-sage type here. An indication that there is 
probably some special case that is foiling correct behaviour comes from the 
fact that np.float32, np.float and np.float128 all do seem to work. Compare:

sage: c=get_coercion_model()
sage: import numpy as np
sage: c.canonical_coercion(1j,np.float(1))
(1.00*I, 1.00)
sage: c.canonical_coercion(1j,np.float32(1))
TypeError: no common canonical parent for objects with parents: ...
sage: c.canonical_coercion(1j,np.float64(1))
(0.0, 1.0)
sage: c.canonical_coercion(1j,np.float128(1))
TypeError: no common canonical parent for objects with parents: ...

As you can see, it's just float64 that does the bad thing:

sage: parent(1j+np.float32(1))

sage: parent(1j+np.float128(1))

sage: parent(1j+np.float64(1))

sage: parent(1j+np.float(1))
Complex Field with 53 bits of precision

As you can see, sage does seem to know how to coerce np.float into its own 
complex field. The ones where no coercion is known end up using __radd__ on 
the numpy type. It's just that somewhere in sage, numpy.float64 apparently 
is deemed to be an appropriate parent for 1j to be coerced in. So it seems 
float64 is recognized *too much* (and in the wrong way), not too little.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sage-devel] numbers in numpy fight sage

[Vincent Delecroix]

Hi Bernhard,

First of all, the command 1j in Sage produces a Sage complex number
{{{
sage: type(1j)

}}}
In order to get a Python complex, one way is to use the suffix r (like raw)
{{{
sage: type(1jr)

}}}

I mentionned Integer whereas the thread was about float but the
problem is the same: Sage numbers do not care about numpy numbers...
In the trac ticket #13386 there is a precised identified piece of code
responsible for the weird interaction between Sage integers and numpy
integers (which is very specific to comparison).

The solution for both problems is to let Sage knows about numpy... but
we do not want to load numpy on startup and we want to load Sage
integers, reals and complexes. It looks like an unsolvable problem.
There is a partial solution at #13386 by Wilfried Huss which looks
similar to what I proposed. But it is not satisfactory.

Vincent

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sage-devel] numbers in numpy fight sage

[bspinnler]

On Saturday, January 4, 2014 8:29:33 PM UTC+1, vdelecroix wrote:
> See #13386 for a related problem.
> 
> 
> 
> I do not see how we can make the coercion numpy int/Sage Integer works
> 
> if numpy is not loaded at startup time... and it seems that we do not
> 
> want it because it takes too much time. There might be a hack using
> 
> the hash of the numpy int type. That way we can check efficiently if
> 
> an object is a numpy int. I would be happy to work on it but the best
> 
> strategy is not yet completely clear to me.
> 
> 

Vincent,

Note, that this is not restricted to integers but also occurs with reals:

1.0j / np.float64(2)

gives 0.0 as well.

Cheers,
Bernhard

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sage-devel] numbers in numpy fight sage

[bspinnler]

On Saturday, January 4, 2014 2:21:29 AM UTC+1, Thierry (sage-googlesucks@xxx) 
wrote:
> 
> On my Sage 6.0, i first get a warning (according to
> http://sourceforge.net/projects/numpy/files/NumPy/1.5.0/NOTES.txt/view
> the message comes from numpy):
> sage: 1j / np.float64(2)
> 
> /opt/sagemath/sage-6.0-i686-Linux/src/bin/sage-ipython:1:
> ComplexWarning: Casting complex values to real discards the imaginary
> part
>   #!/usr/bin/env python
> 0.0
> 
> So, this is not really a bug ;)

Issuing a warning doesn't make the result more correct. So in my eyes it is a 
bug. Actually, I don't see why a complex value should be casted to real in the 
process of the calculation above. Perhaps a real value could be casted to 
complex but not the other way round. 

Note also, that the problem does not occur in a python only environment 
(python/numpy without Sage):

>>> import numpy as np
>>> 1j / np.float64(2)
0.5j

Cheers,
Bernhard

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sage-devel] numbers in numpy fight sage

[Vincent Delecroix]

See #13386 for a related problem.

I do not see how we can make the coercion numpy int/Sage Integer works
if numpy is not loaded at startup time... and it seems that we do not
want it because it takes too much time. There might be a hack using
the hash of the numpy int type. That way we can check efficiently if
an object is a numpy int. I would be happy to work on it but the best
strategy is not yet completely clear to me.

Best,
Vincent

2014/1/4, Thierry :
> Hi,
>
> On Sat, Jan 04, 2014 at 01:03:21AM +0100, Harald Schilly wrote:
>> Here is a problem maybe somebody can help with (reported on sage-support)
>>
>> A complex number in an arithmetic operation with a numpy float gives a
>> wrong answer ... i.e. the complex part is dropped.
>>
>> import numpy as np
>> 1j / np.float64(2)
>>
>> gives 0.0
>
> On my Sage 6.0, i first get a warning (according to
> http://sourceforge.net/projects/numpy/files/NumPy/1.5.0/NOTES.txt/view
> the message comes from numpy):
>
> sage: 1j / np.float64(2)
> /opt/sagemath/sage-6.0-i686-Linux/src/bin/sage-ipython:1:
> ComplexWarning: Casting complex values to real discards the imaginary
> part
>   #!/usr/bin/env python
> 0.0
>
> So, this is not really a bug ;)
>
> How i understand it, the problem comes from a lack of good coercion
> between ComplexNumbers and np.float64, which only raises a warning and
> not an error:
>
> sage: import sage.structure.element as e
> sage: cm = e.get_coercion_model()
> sage: cm.common_parent(1j, np.float64(2))
> 
> sage: np.float64(1j)
> 0.0
>
> There is an old ticket asking to clean the relation between Sage and
> numpy: http://trac.sagemath.org/ticket/8824
>
> That said, the following symbolic works (because np.float64 are coreced
> to SR):
>
> sage: I / np.float64(2)
> 0.5*I
>
> Ciao,
> Thierry
>
>
>> 1j + np.float64(2)
>>
>> gives 2.0
>>
>> It works with float32/float though:
>>
>> 1j + np.float32(2)
>>
>> (2+1j)
>>
>> Harald
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "sage-devel" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to sage-devel+unsubscr...@googlegroups.com.
>> To post to this group, send email to sage-devel@googlegroups.com.
>> Visit this group at http://groups.google.com/group/sage-devel.
>> For more options, visit https://groups.google.com/groups/opt_out.
>
> --
> You received this message because you are subscribed to the Google Groups
> "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sage-devel+unsubscr...@googlegroups.com.
> To post to this group, send email to sage-devel@googlegroups.com.
> Visit this group at http://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.

[sage-devel] Re: About groups., designs., and the brand-new codes.

[Volker Braun]

Common language notions generally don't include higher than 3-dimensional 
objects, it should be clear that Sage is using the term "polytope" in its 
mathematical sense. 

Also, a manifold is not a "chamber or pipe with a number of inlets or 
outlets used to collect or distribute a fluid" in Sage.



On Saturday, January 4, 2014 12:31:21 AM UTC-10, Simon King wrote:
>
> Much to my surprise, I found that the English Wikipedia defines a 
> polyhedron 
> as "a solid in three dimensions with flat faces and straight edges".
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.

[sage-devel] Re: Re: Reviewing without dependencies

[Volker Braun]

On Saturday, January 4, 2014 3:16:08 AM UTC-10, Marc Mezzarobba wrote:
>
> 2. Any change to that set of commits (any change to T's Commit field, 
>any change to one of the D's Commit fields that modifies its most 
>recent common ancestor with T's Commit) automatically reverts T to 
>needs_review. 
>

And any non-fast-forwardable change to the dependencies of the dependencies 
reverts T to needs_review. And any subtraction from the list of 
dependencies (direct or indirect). 

If you want to volunteer to write such a system to store review status for 
all commits and interface with trac then please do. But just showing the 
wrong diff is NOT going to work.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.

[sage-devel] Re: [sage-combinat-devel] Re: Review needed for some combinatorial constructions

[Dima Pasechnik]

On 4 Jan 2014 21:07, "Nathann Cohen"  wrote:
>
> Hello !!!
>
>
> > I'm starting to get interested research-wise in this stuff.
>
> *Great* news (for me) :-PPP
>
> > When trac was reasonably fast, I looked them over and the
formatting/documentation looked fine.
> > It seemed like Dima has looked at them as well?
> > Now trac is so slow, and since the review system has changed from hg to
git,
> > I'd have to look up how to apply patches and test.
>
> Come n ! You'll see, Git is cool and very coherent. Plus it's cool
combinatorial stuff, I need help !
>
> > I have code code of my own testing+constructing weighted PDSs
(essentially association schemes).
>
> HM.. I don't know what those are O_o
whenever you create a graph with a vertex-transitive automorphism group,
you, unknowingly, create a (not necessarily commutative) association
scheme...

>
> Nathann

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.

[sage-devel] Re: [sage-trac] #15107: Projective Plane designs

[P Purkayastha]

On 01/04/2014 10:46 PM, Nathann Cohen wrote:


I feel better now.

Nathann


^_^ \o/

--
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sage-devel] Re: [sage-trac] #15107: Projective Plane designs

[Nathann Cohen]

Hell !!

> From what I understand, Dima is more concerned about future extendability
of
> the function.

We do not write C code. We can add new optional argument whenever we want.

> If someone comes along with a different construction two years
> from now then that person can simply set a different type and the same
> function will work. Right *now*, there is no advantage other than the
> prospect of being maintainable and extendable in the far future.

The same function will work even if we do not add it, for the reason given
above.

This being said, I know how to recognize real art when I see it. I added
the new argument and the ticket is updated.

I also ensured that nothing wrong happened :

+if type != "Desarguesian":
+raise ValueError("The value of 'type' must be 'Desarguesian'.")

And of course I double-checked this exception in a doctest :

+TESTS::
+
+sage: designs.ProjectivePlaneDesign(10, type="AnyThingElse")
+Traceback (most recent call last):
+...
+ValueError: The value of 'type' must be 'Desarguesian'.

I feel better now.

Nathann

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.

[sage-devel] Re: [sage-trac] #15107: Projective Plane designs

[P Purkayastha]

On 01/04/2014 10:20 PM, Nathann Cohen wrote:


The docstring will read :

- ``type`` -- When set to "Pappian", the method only returns Pappian
projective planes. No other value is available.


From what I understand, Dima is more concerned about future 
extendability of the function. If someone comes along with a different 
construction two years from now then that person can simply set a 
different type and the same function will work. Right *now*, there is no 
advantage other than the prospect of being maintainable and extendable 
in the far future.


--
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sage-devel] Re: [sage-trac] #15107: Projective Plane designs

[Dima Pasechnik]

On 4 Jan 2014 22:16, "Dima Pasechnik"  wrote:
>
>
> On 4 Jan 2014 22:11, "Nathann Cohen"  wrote:
> >
> > Hello !!
> >
> > > I think you have misunderstood my complaint, as it was about the
function
> > > returning much more specific thing than asked. You hijack a generic
name for
> > > something specific. I tried to explain this by an analogy with
misnamed
> > > NextPrimePower, actually returning NextPrimePower_OF_TWO, which is
obviously
> > > a better name.
> > >
> > > One unpleasant side effect of your present design is that it is
harder than
> > > necessary to extend to cover other projective planes, as you hijack
the
> > > generic name for no good reason, except your convenience :)
> >
> > So if I follow you, you agree to have this function named
> >
> > designs.ProjectivePlaneDesign() for as long as there is an argument
named type="Pappian" which does absolutely NOTHING as there is no other
implementation available ?
>
> Sure I do. The argument "Pappian" serves as documentation here, for the
time being, it's not absolutely NOTHING...
>

Perhaps even better would be to have one more level of classes, i.e.
designs.ProjectivePlaneDesign.Pappian()
designs.ProjectivePlaneDesign.Hall()
etc

Even better,
drop "Design" part

> >
> > Nathann

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sage-devel] Re: [sage-trac] #15107: Projective Plane designs

[Nathann Cohen]

> It might make sense to people who will work on that in the future.
> Think of your children's children:-)

Reminds me that I should be looking for their mother instead of writing
Sage patches. First things first :-P

Nathann

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sage-devel] Re: [sage-trac] #15107: Projective Plane designs

[David Joyner]

On Sat, Jan 4, 2014 at 9:15 AM, Nathann Cohen  wrote:
> Helloo !!
>

...

>
>> Nathann, all that is left is to make a small change to the ticket to
>> add the default argument
>> type = "Pappian" or type = "Desarguesian", say.  Does this seem reasonable
>> Nathann?
>
> Does it seem reasonable to me to have a function with an optional parameter
> which does nothing, because there is no other implementation available ?
>
> No, it does not. Could you tell me why you think it makes any sense ?


It might make sense to people who will work on that in the future.
Think of your children's children:-)


>
> Last time I saw a function with an optional argument that was never used in
> the code I deprecated it. I don't even know what the function was about.
>
> Nathann

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sage-devel] Re: [sage-trac] #15107: Projective Plane designs

[Nathann Cohen]

> Sure I do. The argument "Pappian" serves as documentation here, for the
time being, it's not absolutely NOTHING...

Okay. Then I take this as modern art.

The docstring will read :

- ``type`` -- When set to "Pappian", the method only returns Pappian
projective planes. No other value is available.

What I cannot stand is misunderstanding. I have absolutely nothing against
plainly assumed absurdity.

I will update the ticket in the next 20 minutes.

Nathann

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sage-devel] Re: [sage-trac] #15107: Projective Plane designs

[Dima Pasechnik]

On 4 Jan 2014 22:11, "Nathann Cohen"  wrote:
>
> Hello !!
>
> > I think you have misunderstood my complaint, as it was about the
function
> > returning much more specific thing than asked. You hijack a generic
name for
> > something specific. I tried to explain this by an analogy with misnamed
> > NextPrimePower, actually returning NextPrimePower_OF_TWO, which is
obviously
> > a better name.
> >
> > One unpleasant side effect of your present design is that it is harder
than
> > necessary to extend to cover other projective planes, as you hijack the
> > generic name for no good reason, except your convenience :)
>
> So if I follow you, you agree to have this function named
>
> designs.ProjectivePlaneDesign() for as long as there is an argument named
type="Pappian" which does absolutely NOTHING as there is no other
implementation available ?

Sure I do. The argument "Pappian" serves as documentation here, for the
time being, it's not absolutely NOTHING...

>
> Nathann

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sage-devel] Re: [sage-trac] #15107: Projective Plane designs

[Nathann Cohen]

Helloo !!

> Dima and Nathann: So can we please agree to drop the argument and
> swinging and punching:-)?

I expect Dima and I are of the punching type. It gets loud but it's never
very bad. I get angry 10 times a day, and I laugh as many times in between
:-P

> Nathann, all that is left is to make a small change to the ticket to
> add the default argument
> type = "Pappian" or type = "Desarguesian", say.  Does this seem reasonable
> Nathann?

Does it seem reasonable to me to have a function with an optional parameter
which does nothing, because there is no other implementation available ?

No, it does not. Could you tell me why you think it makes any sense ?

Last time I saw a function with an optional argument that was never used in
the code I deprecated it. I don't even know what the function was about.

Nathann

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sage-devel] Re: [sage-trac] #15107: Projective Plane designs

[Nathann Cohen]

Hello !!

> I think you have misunderstood my complaint, as it was about the function
> returning much more specific thing than asked. You hijack a generic name
for
> something specific. I tried to explain this by an analogy with misnamed
> NextPrimePower, actually returning NextPrimePower_OF_TWO, which is
obviously
> a better name.
>
> One unpleasant side effect of your present design is that it is harder
than
> necessary to extend to cover other projective planes, as you hijack the
> generic name for no good reason, except your convenience :)

So if I follow you, you agree to have this function named

designs.ProjectivePlaneDesign() for as long as there is an argument named
type="Pappian" which does absolutely NOTHING as there is no other
implementation available ?

Nathann

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sage-devel] Re: [sage-trac] #15107: Projective Plane designs

[David Joyner]

On Sat, Jan 4, 2014 at 9:03 AM, Nathann Cohen  wrote:
>> Thank you Dima!
>>
>> Nathann: Please relax, calm down and except this as a peace offering from 
>> Dima.
>> Okay? An argument over semantics isn't worth it when you can get the
>> syntax you want. You have won!
>
> O_o
>
> What the hell have I won ? I don't even understand what this thread is
> about ! Why would anybody call this function misnamed in the first
> place ? O_O

Dima and Nathann: So can we please agree to drop the argument and
swinging and punching:-)?

Nathann, all that is left is to make a small change to the ticket to
add the default argument
type = "Pappian" or type = "Desarguesian", say.  Does this seem reasonable
Nathann?


>
> Nathann

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sage-devel] Re: [sage-trac] #15107: Projective Plane designs

[Dima Pasechnik]

On 4 Jan 2014 21:59, "Nathann Cohen"  wrote:
>
> Dima,
>
> > Your proposal of a default parameter might actually be more flexible,
as it
> > is easy to extend, codewise.
>
> please answer the f*** question I asked ten times in a row.

I think you have misunderstood my complaint, as it was about the function
returning much more specific thing than asked. You hijack a generic name
for something specific. I tried to explain this by an analogy with misnamed
NextPrimePower, actually returning NextPrimePower_OF_TWO, which is
obviously a better name.

One unpleasant side effect of your present design is that it is harder than
necessary to extend to cover other projective planes, as you hijack the
generic name for no good reason, except your convenience :)


>
> Nathann

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sage-devel] Building on SPARC Solaris

[Jean-Pierre Flori]

I've been building Sage on Solaris recently, without too much trouble 
(except building a 64 bit gcc which I still cannot achive whatever i try).
If someone has admin rights on skynet to create acocunts (xhich was not the 
case last time I tried), I'd give it a shot with pleasere.

On Saturday, January 4, 2014 11:24:55 AM UTC+1, Jeroen Demeyer wrote:
>
> On 2014-01-04 05:11, Volker Braun wrote: 
> > I've spent the whole day trying to build Sage on mark/skynet and I can't 
> > get past the following error. I've tried to copy the buildbot 
> > configuration as far as possible (though not running buildbot, of 
> > course) and the build always fails half-way through the gcc build at: 
>
> It always worked for me, I'll have a look some day. 
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sage-devel] Re: Re: Reviewing without dependencies

[John Cremona]

On 4 January 2014 13:24, Nathann Cohen  wrote:
> Hellooo !!
>
>> Btw, I'm still not convinced by Volker's explanations,
>
> Well, by the look of that thread I don't think anybody but Volker was
> actually convinced :-P
>
>> and the policy I
>> was suggesting at the beginning of that thread still makes more sense to
>> me. In summary, here's what I was suggesting:
>>
>> 1. The default diff/commits view of a ticket T linked from its trac page
>>should be something like
>>
>>  git log --graph commit ^trac/develop ^dep1 ^dep2 ...
>
> Yes. A big "YES"
>
>
>>where commit is the contents of T's Commit field and dep1, dep2...
>>are the contents of the Commit fields of the tickets D1, D2... listed
>>in T's Dependencies field.
>>
>>Setting T to positive_review means that the set of commits described
>>by the above "git log" command has been reviewed.
>
> Indeed. Actually, now that I understand GIt better, it really feels like we
> should not be reviewing branches but rewieving *COMMITS*. This way we would
> know which commits we can use. Reviewing branches does not seem to make any
> sense in a git workflow. I mean, it's the source of all problems we have
> right now.

This is quite logical, since a branch is a pointer to a commit and not
some fixed thing, so if I say "I have reviewed branch u/x/y/z then it
tells you absolutely nothing, while if I say that I am happy with
commit a1b2c3d4... then it does refer to a specific snapshot of the
code.  With the hg model we were reviewing patches, or sequences of
patches considered as a single unit, and "positive review" meant
something like "I approve of the combined effect of applying these
patches".

One difficulty with reviewing individual commits is that many of them
are snapshots along the way to a finished piece of work.  For example,
I am about to make a commit of some work I was in the middle of
yesterday, so that I can come back to it later, while in the meantime
I want to be able to change branches so that I can review some other
tickets.  It would not make sense for that half-way commit to ever be
reviewed in isolation.  Of course, the half-way commit only exists on
my own computer so I could rewrite local history later, but why should
I bother?

Does it make sense for us to mark a specific commit as "ready for
review" rather than a branch?  Working back through that commit's
history one might pass by what I called half-way commits above, which
could be ignored, until reaching either (1) a commit which has already
been merged -- in which case the changes to be reviewed are the ones
between that one and the current one;  or (2) a commit which is also
tagged "ready for review"; or (3) a commit which has a positive
review, which could be treated as in case (0).  Ok, I know that the
number of cases here is more than the ones described;  but I have
already found that when reviewing a ticket it has been necessary to
say in the comment on trac exactly which commit I was looking at, and
also when marking a ticket as ready for review I intend to always say
which commit it is which I would like reviewed.  It would not be hard
for trac to have fields showing that information?  You might think it
redundant, but yesterday someone with initials JD made a new commit to
a branch after I had started reviewing a ticket tagged "ready for
review"!

John

>
>> If anyone can explain why "Volker's model" is safer than that, I'm very
>> interested.
>
> And if somebody agrees that this is not a good model, I would be interested
> too.
>
> Nathann
>
> --
> You received this message because you are subscribed to the Google Groups
> "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sage-devel+unsubscr...@googlegroups.com.
> To post to this group, send email to sage-devel@googlegroups.com.
> Visit this group at http://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/groups/opt_out.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sage-devel] Re: [sage-trac] #15107: Projective Plane designs

[Nathann Cohen]

> Thank you Dima!
>
> Nathann: Please relax, calm down and except this as a peace offering from 
> Dima.
> Okay? An argument over semantics isn't worth it when you can get the
> syntax you want. You have won!

O_o

What the hell have I won ? I don't even understand what this thread is
about ! Why would anybody call this function misnamed in the first
place ? O_O

Nathann

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sage-devel] Re: [sage-trac] #15107: Projective Plane designs

[David Joyner]

On Sat, Jan 4, 2014 at 8:57 AM, Dima Pasechnik  wrote:
> David,
> Your proposal of a default parameter might actually be more flexible, as it
> is easy to extend, codewise.
> Dima
>


Thank you Dima!

Nathann: Please relax, calm down and except this as a peace offering from Dima.
Okay? An argument over semantics isn't worth it when you can get the
syntax you want. You have won!

And don't forget it is almost Happy New Year!



>
> On 4 Jan 2014 21:50, "David Joyner"  wrote:
>>
>> On Sat, Jan 4, 2014 at 8:46 AM, Nathann Cohen 
>> wrote:
>> > I meant #15521, not #15482.
>> >
>> > And I meant "claims something different from what it returns", not "from
>> > what it claims".
>> >
>> > Nathann
>> >
>>
>> Nathann:
>>
>> At the risk of being punch in the face by trying to mediate this slugfest,
>>
>> 
>>
>> are you okay with the compromise Dima has offered:
>> designs.ProjectivePlanePappian ?
>>
>> 
>>
>> Seems simple enough and then everyone is hopefully happy:-)
>>
>> - David
>>
>>

...

>> > Visit this group at http://groups.google.com/group/sage-devel.
>> > For more options, visit https://groups.google.com/groups/opt_out.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.

[sage-devel] Re: [sage-trac] #15107: Projective Plane designs

[Dima Pasechnik]

On 4 Jan 2014 21:43, "Nathann Cohen"  wrote:
>
> > If you know what you are doing it is not hard to find. Unless of course
you receive all the knowledge by hitting TAB :)
> > OK, name it ProjectivePlanePappian, to satisfy your TAB-happy fingers...
> >
> > Oh well, the fact that you already put a bunch of misnamed stuff into
Sage does not mean that you should keep doing this and keep confusing other
potential users... Cf our previous disputes about LP vs Integer LP
>
> Dima, you started this thread by claiming I was writing a function which
did not return what it claims to return.
> This designs.ProjectivePlaneDesign returns a projective plane design. I
hope that is clear.
>
>
> > Oh well, the fact that you already put a bunch of misnamed stuff into
Sage does not mean that you should keep doing this and keep confusing other
potential users...
> How can you call that misnamed ? A function "steiner_triple_system" which
returns a steiner triple system ? Really ?

So what. I can also say that it returns a set system. Why don't you call it
setsystemblahblah, a name that only makes sense to you ☺
>
>
> > Cf our previous disputes about LP vs Integer LP
> Well, didn't I fix that since ? I anything, it shows I put my liking
aside when it is not natural for others. Same with #15482, that I
implemented myself, because it confused others.

So people are telling you to fix your design now, and not later...
And you start screaming at them in response.

The fact that you did misname things in the past does not mean you can keep
doing this...

"Officer, why are you booking me? You ran a red light! Huh, I did this 50
times, and nobody booked me before" kind of thing...
>
> This function called designs.ProjectivePlaneDesign returns a projective
plane design. Please answer yes/no to that or tell me again why you think
my function claims something different from what it claims.
>
> Play it fair. Then, we can discuss the matter at hand. But so far I am
the one who has NO CLUE why you would want to overspecify a method. And for
this I would like ot have explanations.
>
> Nathann

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sage-devel] Re: [sage-trac] #15107: Projective Plane designs

[Nathann Cohen]

Dima,

> Your proposal of a default parameter might actually be more flexible, as it
> is easy to extend, codewise.

please answer the f*** question I asked ten times in a row.

Nathann

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sage-devel] Re: [sage-trac] #15107: Projective Plane designs

[Dima Pasechnik]

David,
Your proposal of a default parameter might actually be more flexible, as it
is easy to extend, codewise.
Dima
On 4 Jan 2014 21:50, "David Joyner"  wrote:
>
> On Sat, Jan 4, 2014 at 8:46 AM, Nathann Cohen 
wrote:
> > I meant #15521, not #15482.
> >
> > And I meant "claims something different from what it returns", not "from
> > what it claims".
> >
> > Nathann
> >
>
> Nathann:
>
> At the risk of being punch in the face by trying to mediate this slugfest,
>
> 
>
> are you okay with the compromise Dima has offered:
> designs.ProjectivePlanePappian ?
>
> 
>
> Seems simple enough and then everyone is hopefully happy:-)
>
> - David
>
>
> >
> > On 4 January 2014 14:43, Nathann Cohen  wrote:
> >>
> >> > If you know what you are doing it is not hard to find. Unless of
course
> >> > you receive all the knowledge by hitting TAB :)
> >> > OK, name it ProjectivePlanePappian, to satisfy your TAB-happy
fingers...
> >> >
> >> > Oh well, the fact that you already put a bunch of misnamed stuff into
> >> > Sage does not mean that you should keep doing this and keep
confusing other
> >> > potential users... Cf our previous disputes about LP vs Integer
LP
> >>
> >> Dima, you started this thread by claiming I was writing a function
which
> >> did not return what it claims to return.
> >> This designs.ProjectivePlaneDesign returns a projective plane design. I
> >> hope that is clear.
> >>
> >>
> >> > Oh well, the fact that you already put a bunch of misnamed stuff into
> >> > Sage does not mean that you should keep doing this and keep
confusing other
> >> > potential users...
> >> How can you call that misnamed ? A function "steiner_triple_system"
which
> >> returns a steiner triple system ? Really ?
> >>
> >>
> >> > Cf our previous disputes about LP vs Integer LP
> >> Well, didn't I fix that since ? I anything, it shows I put my liking
aside
> >> when it is not natural for others. Same with #15482, that I implemented
> >> myself, because it confused others.
> >>
> >> This function called designs.ProjectivePlaneDesign returns a projective
> >> plane design. Please answer yes/no to that or tell me again why you
think my
> >> function claims something different from what it claims.
> >>
> >> Play it fair. Then, we can discuss the matter at hand. But so far I am
the
> >> one who has NO CLUE why you would want to overspecify a method. And
for this
> >> I would like ot have explanations.
> >>
> >> Nathann
> >
> >
> > --
> > You received this message because you are subscribed to the Google
Groups
> > "sage-devel" group.
> > To unsubscribe from this group and stop receiving emails from it, send
an
> > email to sage-devel+unsubscr...@googlegroups.com.
> > To post to this group, send email to sage-devel@googlegroups.com.
> > Visit this group at http://groups.google.com/group/sage-devel.
> > For more options, visit https://groups.google.com/groups/opt_out.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sage-devel] Re: [sage-trac] #15107: Projective Plane designs

[Nathann Cohen]

Helloo !

> At the risk of being punch in the face by trying to mediate this slugfest,
>
> 

This one was a nasty one. You did well.

> are you okay with the compromise Dima has offered:
> designs.ProjectivePlanePappian ?

It's one I will be willing to accept, it's a good compromise indeed. I
would be glad to know *WHY* I would have to accept it though, so far
the attacks have been the following : the function is misnamed,
because it does not return what it claims.

I think this is a plain lie, and so to accept a compromise I request a
valid reason why this function is called misnamed. And you can answer
this one too, as you agreed with Dima.

> Seems simple enough and then everyone is hopefully happy:-)

I don't want to change this function's name just because somebody
comes and does not like it. I would like a valid reason. If you can
provide one, I would be glad to discuss it.

Nathann

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.

[sage-devel] Re: [sage-trac] #15107: Projective Plane designs

[Nathann Cohen]

> > How can you call that misnamed ? A function "steiner_triple_system"
which returns a steiner triple system ? Really ?
>
> So what. I can also say that it returns a set system. Why don't you call
it setsystemblahblah, a name that only makes sense to you ☺

.

That comment is so dishonest I will not even answer it.

> So people are telling you to fix your design now, and not later...
> And you start screaming at them in response.

So far you haven't told me why you thought it was wrong. You told me I
claimed to do something different from what it does, and this is clearly
wrong.

So then again, because you did not answer my last question : this function
is called ProjectivePlaneDesign and returns a projective plane design. Why
do you call that misnaming ?

Nathann

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sage-devel] Re: [sage-trac] #15107: Projective Plane designs

[David Joyner]

On Sat, Jan 4, 2014 at 8:46 AM, Nathann Cohen  wrote:
> I meant #15521, not #15482.
>
> And I meant "claims something different from what it returns", not "from
> what it claims".
>
> Nathann
>

Nathann:

At the risk of being punch in the face by trying to mediate this slugfest,



are you okay with the compromise Dima has offered:
designs.ProjectivePlanePappian ?



Seems simple enough and then everyone is hopefully happy:-)

- David


>
> On 4 January 2014 14:43, Nathann Cohen  wrote:
>>
>> > If you know what you are doing it is not hard to find. Unless of course
>> > you receive all the knowledge by hitting TAB :)
>> > OK, name it ProjectivePlanePappian, to satisfy your TAB-happy fingers...
>> >
>> > Oh well, the fact that you already put a bunch of misnamed stuff into
>> > Sage does not mean that you should keep doing this and keep confusing other
>> > potential users... Cf our previous disputes about LP vs Integer LP
>>
>> Dima, you started this thread by claiming I was writing a function which
>> did not return what it claims to return.
>> This designs.ProjectivePlaneDesign returns a projective plane design. I
>> hope that is clear.
>>
>>
>> > Oh well, the fact that you already put a bunch of misnamed stuff into
>> > Sage does not mean that you should keep doing this and keep confusing other
>> > potential users...
>> How can you call that misnamed ? A function "steiner_triple_system" which
>> returns a steiner triple system ? Really ?
>>
>>
>> > Cf our previous disputes about LP vs Integer LP
>> Well, didn't I fix that since ? I anything, it shows I put my liking aside
>> when it is not natural for others. Same with #15482, that I implemented
>> myself, because it confused others.
>>
>> This function called designs.ProjectivePlaneDesign returns a projective
>> plane design. Please answer yes/no to that or tell me again why you think my
>> function claims something different from what it claims.
>>
>> Play it fair. Then, we can discuss the matter at hand. But so far I am the
>> one who has NO CLUE why you would want to overspecify a method. And for this
>> I would like ot have explanations.
>>
>> Nathann
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sage-devel+unsubscr...@googlegroups.com.
> To post to this group, send email to sage-devel@googlegroups.com.
> Visit this group at http://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/groups/opt_out.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.

[sage-devel] Re: [sage-trac] #15107: Projective Plane designs

[Nathann Cohen]

I meant #15521, not #15482.

And I meant "claims something different from what it returns", not "from
what it claims".

Nathann


On 4 January 2014 14:43, Nathann Cohen  wrote:

> > If you know what you are doing it is not hard to find. Unless of course
> you receive all the knowledge by hitting TAB :)
> > OK, name it ProjectivePlanePappian, to satisfy your TAB-happy fingers...
> >
> > Oh well, the fact that you already put a bunch of misnamed stuff into
> Sage does not mean that you should keep doing this and keep confusing other
> potential users... Cf our previous disputes about LP vs Integer LP
>
> Dima, you started this thread by claiming I was writing a function which
> did not return what it claims to return.
> This designs.ProjectivePlaneDesign returns a projective plane design. I
> hope that is clear.
>
>
> > Oh well, the fact that you already put a bunch of misnamed stuff into
> Sage does not mean that you should keep doing this and keep confusing other
> potential users...
> How can you call that misnamed ? A function "steiner_triple_system" which
> returns a steiner triple system ? Really ?
>
>
> > Cf our previous disputes about LP vs Integer LP
> Well, didn't I fix that since ? I anything, it shows I put my liking aside
> when it is not natural for others. Same with #15482, that I implemented
> myself, because it confused others.
>
> This function called designs.ProjectivePlaneDesign returns a projective
> plane design. Please answer yes/no to that or tell me again why you think
> my function claims something different from what it claims.
>
> Play it fair. Then, we can discuss the matter at hand. But so far I am the
> one who has NO CLUE why you would want to overspecify a method. And for
> this I would like ot have explanations.
>
> Nathann
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.

[sage-devel] Re: [sage-trac] #15107: Projective Plane designs

[Nathann Cohen]

> If you know what you are doing it is not hard to find. Unless of course
you receive all the knowledge by hitting TAB :)
> OK, name it ProjectivePlanePappian, to satisfy your TAB-happy fingers...
>
> Oh well, the fact that you already put a bunch of misnamed stuff into
Sage does not mean that you should keep doing this and keep confusing other
potential users... Cf our previous disputes about LP vs Integer LP

Dima, you started this thread by claiming I was writing a function which
did not return what it claims to return.
This designs.ProjectivePlaneDesign returns a projective plane design. I
hope that is clear.

> Oh well, the fact that you already put a bunch of misnamed stuff into
Sage does not mean that you should keep doing this and keep confusing other
potential users...
How can you call that misnamed ? A function "steiner_triple_system" which
returns a steiner triple system ? Really ?

> Cf our previous disputes about LP vs Integer LP
Well, didn't I fix that since ? I anything, it shows I put my liking aside
when it is not natural for others. Same with #15482, that I implemented
myself, because it confused others.

This function called designs.ProjectivePlaneDesign returns a projective
plane design. Please answer yes/no to that or tell me again why you think
my function claims something different from what it claims.

Play it fair. Then, we can discuss the matter at hand. But so far I am the
one who has NO CLUE why you would want to overspecify a method. And for
this I would like ot have explanations.

Nathann

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.

[sage-devel] Re: [sage-trac] #15107: Projective Plane designs

[Dima Pasechnik]

Nathann,
If you know what you are doing it is not hard to find. Unless of course you
receive all the knowledge by hitting TAB :)
OK, name it ProjectivePlanePappian, to satisfy your TAB-happy fingers...

Oh well, the fact that you already put a bunch of misnamed stuff into Sage
does not mean that you should keep doing this and keep confusing other
potential users... Cf our previous disputes about LP vs Integer LP

On 4 Jan 2014 21:21, "Nathann Cohen"  wrote:
>
> Hell !
>
>
> > Hi Nathann,
> > The trac seems to be down for me, so I write here.
> > What you propose is a misnaming of the object, akin to, say, creation
of a Sage function that returns for given n the next prime power,
NextPrimePower, but then you actually make it return next power of 2.
> > Your function returns a Desarguesian projective plane, and this term
and the order of the plane characterize it uniquely.
> > Then name it properly...
> > Dima
>
> Okay, so as you involve everybody, let's explain it to them :
>
> Patch #15107 adds a method named (at first)
designs.ProjectivePlaneDesign. Which returns what is known as a projective
plane, i.e. there :
http://en.wikipedia.org/wiki/Projective_plane#Finite_projective_planes
>
> Dima made comments on the tickets and thinks that it should be renamed to
one of designs.DesarguesianProjectivePlaneDesign or
designs.PappianProjectivePlaneDesign (none of which is "the obvious choice")
>
> Now Dima, you say that I am misnaming a function but I don't understand
how you can defend that : this function *does* return a Projective Plane.
It is, indeed, a specific kind of projective planes (I don't think that
there is anu other general construction), but it *IS* a projective plane.
So how could naming it "ProjectivePlaneDesign" be incorrect ?
>
> As I was saying on the other thread, we have already things like that :
> designs.steiner_triple_system
> designs.steiner_quadruple_system
>
> And of course there are *MANY* such systems for a given input. But well,
these functions are only interesting because they return such systems, so
the name fits.
>
> Plus we will soon have a design.BalancedIncompleteBlockDesign, and the
same will happen.
>
> S well.. You agree that this function returns Projective Planes, as
you want to call them Desarguesian Projective Planes, but given that the
name is not a natural choice and make it harder to find, I think it should
be called designs.ProjectivePlane. I don't claim that the function will
return anything that it should not : it returns projective planes, as we
want it to.
>
> You cannot say that it is misnamed.
>
> Nathann

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sage-devel] Re: [sage-trac] #15107: Projective Plane designs

[David Joyner]

On Sat, Jan 4, 2014 at 8:21 AM, Nathann Cohen  wrote:
> Hell !
>
>
>> Hi Nathann,
>> The trac seems to be down for me, so I write here.
>> What you propose is a misnaming of the object, akin to, say, creation of a
>> Sage function that returns for given n the next prime power, NextPrimePower,
>> but then you actually make it return next power of 2.
>> Your function returns a Desarguesian projective plane, and this term and
>> the order of the plane characterize it uniquely.
>> Then name it properly...
>> Dima
>
> Okay, so as you involve everybody, let's explain it to them :
>
> Patch #15107 adds a method named (at first) designs.ProjectivePlaneDesign.
> Which returns what is known as a projective plane, i.e. there :
> http://en.wikipedia.org/wiki/Projective_plane#Finite_projective_planes
>
> Dima made comments on the tickets and thinks that it should be renamed to
> one of designs.DesarguesianProjectivePlaneDesign or
> designs.PappianProjectivePlaneDesign (none of which is "the obvious choice")
>
> Now Dima, you say that I am misnaming a function but I don't understand how

...

>
> You cannot say that it is misnamed.
>

It seems to me there are two solutions to this argument.

(1) Leave it as designs.ProjectivePlaneDesign but have an option
type = "Desarguesian" as the default argument
(2) change it to designs.ProjectivePlaneDesignDesarguesian

(Sorry, Nathann, I sort of agree with Dima here. However, I do not like
designs.DesarguesianProjectivePlaneDesign, for the same reason that I
prefer plot_implicit to implicit_plot, but that doesn't mean it gets
implemented:-)


> Nathann
>
> --
> You received this message because you are subscribed to the Google Groups
> "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sage-devel+unsubscr...@googlegroups.com.
> To post to this group, send email to sage-devel@googlegroups.com.
> Visit this group at http://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/groups/opt_out.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sage-devel] Re: Re: Reviewing without dependencies

[Nathann Cohen]

Hellooo !!

> Btw, I'm still not convinced by Volker's explanations,

Well, by the look of that thread I don't think anybody but Volker was
actually convinced :-P

> and the policy I
> was suggesting at the beginning of that thread still makes more sense to
> me. In summary, here's what I was suggesting:
>
> 1. The default diff/commits view of a ticket T linked from its trac page
>should be something like
>
>  git log --graph commit ^trac/develop ^dep1 ^dep2 ...

Yes. A big "YES"

>where commit is the contents of T's Commit field and dep1, dep2...
>are the contents of the Commit fields of the tickets D1, D2... listed
>in T's Dependencies field.
>
>Setting T to positive_review means that the set of commits described
>by the above "git log" command has been reviewed.

Indeed. Actually, now that I understand GIt better, it really feels like we
should not be reviewing branches but rewieving *COMMITS*. This way we would
know which commits we can use. Reviewing branches does not seem to make any
sense in a git workflow. I mean, it's the source of all problems we have
right now.

> If anyone can explain why "Volker's model" is safer than that, I'm very
> interested.

And if somebody agrees that this is not a good model, I would be interested
too.

Nathann

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.

[sage-devel] Re: [sage-trac] #15107: Projective Plane designs

[Nathann Cohen]

Hell !

> Hi Nathann,
> The trac seems to be down for me, so I write here.
> What you propose is a misnaming of the object, akin to, say, creation of
a Sage function that returns for given n the next prime power,
NextPrimePower, but then you actually make it return next power of 2.
> Your function returns a Desarguesian projective plane, and this term and
the order of the plane characterize it uniquely.
> Then name it properly...
> Dima

Okay, so as you involve everybody, let's explain it to them :

Patch #15107 adds a method named (at first) designs.ProjectivePlaneDesign.
Which returns what is known as a projective plane, i.e. there :
http://en.wikipedia.org/wiki/Projective_plane#Finite_projective_planes

Dima made comments on the tickets and thinks that it should be renamed to
one of designs.DesarguesianProjectivePlaneDesign or
designs.PappianProjectivePlaneDesign (none of which is "the obvious choice")

Now Dima, you say that I am misnaming a function but I don't understand how
you can defend that : this function *does* return a Projective Plane. It
is, indeed, a specific kind of projective planes (I don't think that there
is anu other general construction), but it *IS* a projective plane. So how
could naming it "ProjectivePlaneDesign" be incorrect ?

As I was saying on the other thread, we have already things like that :
designs.steiner_triple_system
designs.steiner_quadruple_system

And of course there are *MANY* such systems for a given input. But well,
these functions are only interesting because they return such systems, so
the name fits.

Plus we will soon have a design.BalancedIncompleteBlockDesign, and the same
will happen.

S well.. You agree that this function returns Projective Planes, as you
want to call them Desarguesian Projective Planes, but given that the name
is not a natural choice and make it harder to find, I think it should be
called designs.ProjectivePlane. I don't claim that the function will return
anything that it should not : it returns projective planes, as we want it
to.

You cannot say that it is misnamed.

Nathann

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.

[sage-devel] Re: Re: Reviewing without dependencies

[Marc Mezzarobba]

Jeroen Demeyer wrote:
> OK, thanks, at least I understand the issue now. Somehow I couldn't
> find this very simple explanation on the other long thread about
> dependencies.

I'm not sure which of the threads about dependencies you are referring 
to, but Volker gave the same example (and more) in the thread starting 
at . See in particular
.

Btw, I'm still not convinced by Volker's explanations, and the policy I 
was suggesting at the beginning of that thread still makes more sense to 
me. In summary, here's what I was suggesting:

1. The default diff/commits view of a ticket T linked from its trac page
   should be something like

 git log --graph commit ^trac/develop ^dep1 ^dep2 ...

   where commit is the contents of T's Commit field and dep1, dep2...
   are the contents of the Commit fields of the tickets D1, D2... listed
   in T's Dependencies field.

   Setting T to positive_review means that the set of commits described
   by the above "git log" command has been reviewed.

2. Any change to that set of commits (any change to T's Commit field,
   any change to one of the D's Commit fields that modifies its most
   recent common ancestor with T's Commit) automatically reverts T to
   needs_review.

3. It is allowed, though discouraged, to review T without reviewing
   D1, D2...

If anyone can explain why "Volker's model" is safer than that, I'm very 
interested. In particular, Volker has given a number of examples of how 
mathematically incorrect code can end up in the mainline despite the 
reviewers having done their job. But the simple fact of reviewing 
several branches in parallel is enough to have kind of problems, even if 
there are no dependencies between the branches! And I'm still looking 
for an situation where the way of handling dependencies outlined above, 
specifically, would cause a problem.

Thanks!

-- 
Marc

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.

[sage-devel] Re: Review needed for some combinatorial constructions

[Nathann Cohen]

Helloo !!

> I did, briefly. I will have some time for this in the 2nd half of
January, after we are back to Oxford.

Well, #15107 has been in needs_review for 4 months and I really wouldn't
mind if somebody reviewed it before the end of the month.

By the way, I think we should use designs.ProjectivePlane as a name.
DesarguesianProjectivePlane is uselessly complicated, and we have currently
no way to return a "Projective Plane", even when one does not care which
kind of plane it may be.

Anyway, quite soon we will have a "BalancedIncompleteBlockDesign" function,
and whike there may be many BIBD for a given set of parameters that
function will only return one... And we currently have a
designs.steiner_triple_system and designs.steiner_quadruple_system which
already behave that way. So well, I don't see anything wrong with a
designs.ProjectivePlaneDesign, and it is definitely much easier to find.

Nathann

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.

[sage-devel] Re: [sage-trac] #15107: Projective Plane designs

[Dima Pasechnik]

Hi Nathann,
The trac seems to be down for me, so I write here.
What you propose is a misnaming of the object, akin to, say, creation of a
Sage function that returns for given n the next prime power,
NextPrimePower, but then you actually make it return next power of 2.
Your function returns a Desarguesian projective plane, and this term and
the order of the plane characterize it uniquely.
Then name it properly...
Dima
 On 4 Jan 2014 19:58, "sage-trac"  wrote:

> #15107: Projective Plane designs
> -+-
>Reporter: |Owner:
>   ncohen |   Status:  needs_review
>Type: |Milestone:  sage-6.1
>   enhancement|   Resolution:
>Priority:  major  |Merged in:
>   Component: |Reviewers:
>   combinatorics  |  Work issues:
>Keywords: |   Commit:
> Authors: |  cf71d58dedd357692ea90749090adee9ffadd629
>   Nathann Cohen  | Stopgaps:
> Report Upstream:  N/A|
>  Branch: |
>   u/ncohen/15107 |
>Dependencies: |
> -+-
>
> Comment (by ncohen):
>
>  Helloo !
>
>  Well, the purpose of this function is to return a projective plane design,
>  i.e. a `d^2+d+1, d+1` BIBD.
>
>  I agree with what you said. Actually, thinking about it again, I don't
>  agree with what Dima said above. I don't see the problem with calling this
>  `ProjectivePlaneDesign`, as I need a function which returns a projective
>  plane design. Changing the name just makes it harder to find when one
>  looks for it `>_<`
>
>  What do you think ?
>
>  I think that this alias is useful, but I personally spent quite some time
>  trying to figure out of to obtain a projective plane design with Sage.
>
>  Nathann
>
> --
> Ticket URL: 
> Sage 
> Sage: Creating a Viable Open Source Alternative to Magma, Maple,
> Mathematica, and MATLAB
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.

[sage-devel] Re: [sage-combinat-devel] Re: Review needed for some combinatorial constructions

[Nathann Cohen]

Hello !!!

> I'm starting to get interested research-wise in this stuff.

*Great* news (for me) :-PPP

> When trac was reasonably fast, I looked them over and the
formatting/documentation looked fine.
> It seemed like Dima has looked at them as well?
> Now trac is so slow, and since the review system has changed from hg to
git,
> I'd have to look up how to apply patches and test.

Come n ! You'll see, Git is cool and very coherent. Plus it's cool
combinatorial stuff, I need help !

> I have code code of my own testing+constructing weighted PDSs
(essentially association schemes).

HM.. I don't know what those are O_o

Nathann

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.

[sage-devel] Re: Review needed for some combinatorial constructions

[Dima Pasechnik]

On 4 Jan 2014 20:11, "David Joyner"  wrote:
>
>
>
> On Tuesday, December 24, 2013 6:22:27 AM UTC-5, Nathann Cohen wrote:
>>
>> Hellooo everybody !!!
>>
>> I send this email because I want to add new stuff to our
combinat/designs/ folder, and I really need some help to review patches.
These are constructions of combinatorial designs, i.e. SOoo very sexy
set systems.
>>
>
> I'm starting to get interested research-wise in this stuff.
> When trac was reasonably fast, I looked them over and the
formatting/documentation looked fine.
> It seemed like Dima has looked at them as well?

I did, briefly. I will have some time for this in the 2nd half of January,
after we are back to Oxford.

> Now trac is so slow, and since the review system has changed from hg to
git,
> I'd have to look up how to apply patches and test.
>
> I have code code of my own testing+constructing weighted PDSs
(essentially association schemes).
> It would be cool if Sage had Schur rings associated to association
schemes. Every time
> I have to deal with them, I have to construct them by hand...
>
>
>>
>> I don't think such code is available anywhere else. Those constructions
exist on paper but I don't think anybody implemented them, and it's a pity
for two reasons :
>>
>> 1) The constructions can be pretty tricky, but checking that they work
on a computer is very easy (and my code does it always, so no wrong result
can ever be returned, no fear of that)
>
>
> Nice idea, Nathann!
>
>>
>> 2) Sometimes it's even hard to just decipher the constructions from old
papers, and implementing [1] felt like saving them before it became
impossible to read it :-P
>>
>> What I try to implement these days are Balanced Incomplete Block Designs
[2], which you can see as an edge-decomposition of the complete graph K_v
into copies of K_k.
>>
>> - K_n can be decomposed into K_3 if and only if v = 1,3 [6] (
implemented there [3], examples on [4] )
>> - K_n can be decomposed into K_4 if and only if v = 1,4 [12] (several
patches waiting for a review)
>> - K_n can be decomposed into K_5 if and only if v = 1,5 [20] (on my hard
drive only, which can become a patch anytime)
>>
>> And then again I don't think that the decompositions are implemented
anywhere else for K_4 and K_5.
>>
>> I need help to review these patches. I understand the constructions are
very tricky, but then again *THEY ARE ALL CHECKED BEFORE SAGE RETURNS THEM*
so even if the whole construction code is gibberish there is nothing to
fear for as long as the code that checks it is correct. And this code is
dead simple.
>>
>> Sooo well... I need help for that, definitely. I tried to make it
*very well* documented, and if it isn't sufficient just ak me for more and
I will add them quick.
>>
>> (a shortcut, and a bugfix)
>> #15107 Projective Plane designs
>> #15285 Bug in AffineGeometryDesign
>>
>> (construction for k=4)
>> #15286 Latin squares
>> #15287 Orthogonal Arrays
>> #15288 Balanced Incomplete Block Designs with k=4
>>
>> (needed for k=5)
>> #15310 Wilson's construction of Transversal Designs/Orthogonal
Arrays/MOLS
>> #15431 Transversal Design TD(6,12)
>>
>> Sooo well... If you can help me with that, and of course if I can help
you with some of your patches tell me about it.
>>
>> Thank you very much !!!
>>
>> Nathann
>> http://www.steinertriples.fr/ncohen/
>>
>> P.S. : please don't only answer on sage-combinat
>>
>> [1]
http://www.sagemath.org/doc/reference/combinat/sage/combinat/designs/steiner_quadruple_systems.html
>> [2]
http://en.wikipedia.org/wiki/Block_design#Definition_of_a_BIBD_.28or_2-design.29
>> [3]
http://www.sagemath.org/doc/reference/combinat/sage/combinat/designs/block_design.html#sage.combinat.designs.block_design.steiner_triple_system
>> [4] http://www.steinertriples.fr/

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.

[sage-devel] Re: Review needed for some combinatorial constructions

[David Joyner]

On Tuesday, December 24, 2013 6:22:27 AM UTC-5, Nathann Cohen wrote:
>
> Hellooo everybody !!!
>
> I send this email because I want to add new stuff to our combinat/designs/ 
> folder, and I really need some help to review patches. These are 
> constructions of combinatorial designs, i.e. SOoo very sexy set systems.
>
>
I'm starting to get interested research-wise in this stuff.
When trac was reasonably fast, I looked them over and the 
formatting/documentation looked fine.
It seemed like Dima has looked at them as well?
Now trac is so slow, and since the review system has changed from hg to git,
I'd have to look up how to apply patches and test.

I have code code of my own testing+constructing weighted PDSs (essentially 
association schemes).
It would be cool if Sage had Schur rings associated to association schemes. 
Every time
I have to deal with them, I have to construct them by hand...

 

> I don't think such code is available anywhere else. Those constructions 
> exist on paper but I don't think anybody implemented them, and it's a pity 
> for two reasons :
>
> 1) The constructions can be pretty tricky, but checking that they work on 
> a computer is very easy (and my code does it always, so no wrong result can 
> ever be returned, no fear of that)
>

Nice idea, Nathann!
 

> 2) Sometimes it's even hard to just decipher the constructions from old 
> papers, and implementing [1] felt like saving them before it became 
> impossible to read it :-P
>
> What I try to implement these days are Balanced Incomplete Block Designs 
> [2], which you can see as an edge-decomposition of the complete graph K_v 
> into copies of K_k.
>
> - K_n can be decomposed into K_3 if and only if v = 1,3 [6] ( implemented 
> there [3], examples on [4] )
> - K_n can be decomposed into K_4 if and only if v = 1,4 [12] (several 
> patches waiting for a review)
> - K_n can be decomposed into K_5 if and only if v = 1,5 [20] (on my hard 
> drive only, which can become a patch anytime)
>
> And then again I don't think that the decompositions are implemented 
> anywhere else for K_4 and K_5.
>
> I need help to review these patches. I understand the constructions are 
> very tricky, but then again *THEY ARE ALL CHECKED BEFORE SAGE RETURNS THEM* 
> so even if the whole construction code is gibberish there is nothing to 
> fear for as long as the code that checks it is correct. And this code is 
> dead simple.
>
> Sooo well... I need help for that, definitely. I tried to make it 
> *very well* documented, and if it isn't sufficient just ak me for more and 
> I will add them quick.
>
> (a shortcut, and a bugfix)
> #15107 Projective Plane designs
> #15285 Bug in AffineGeometryDesign
>
> (construction for k=4)
> #15286 Latin squares
> #15287 Orthogonal Arrays
> #15288 Balanced Incomplete Block Designs with k=4
>
> (needed for k=5)
> #15310 Wilson's construction of Transversal Designs/Orthogonal Arrays/MOLS
> #15431 Transversal Design TD(6,12)
>
> Sooo well... If you can help me with that, and of course if I can help you 
> with some of your patches tell me about it.
>
> Thank you very much !!!
>
> Nathann
> http://www.steinertriples.fr/ncohen/
>
> P.S. : please don't only answer on sage-combinat
>
> [1] 
> http://www.sagemath.org/doc/reference/combinat/sage/combinat/designs/steiner_quadruple_systems.html
> [2] 
> http://en.wikipedia.org/wiki/Block_design#Definition_of_a_BIBD_.28or_2-design.29
> [3] 
> http://www.sagemath.org/doc/reference/combinat/sage/combinat/designs/block_design.html#sage.combinat.designs.block_design.steiner_triple_system
> [4] http://www.steinertriples.fr/
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sage-devel] About groups., designs., and the brand-new codes.

[Nathann Cohen]

Yooo !!!

> +1 also for "rings." and "fields.", even if we keep ZZ, QQ, AA,... in the
> global namespace as well, since they correspond to very standard objects.
> As well as with "plots.implicit", those will help the user to discover
> what is available in Sage.

Ahahahah.. Less talk, more tickets in needs_review :-P

> Some are less consistent and should be fixed:
>
>  - BlockDesign()/IncidenceStructure() designs. (note that "Design" is
>unused).

"should be fixed" ? Hey, I like it as it is right now. Plus I need help to
review actual new features in this folder. Not only for cosmetics :-P
https://groups.google.com/d/topic/sage-combinat-devel/yYtZI0xdt5o/discussion

Help ! This stuff is great, and it's rotting at
the moment :-P

Nathann

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.

[sage-devel] Re: About groups., designs., and the brand-new codes.

[Simon King]

Hi Volker,

On 2014-01-04, Volker Braun  wrote:
> On Friday, January 3, 2014 2:11:30 PM UTC-10, Thierry 
> (sage-googlesucks@xxx) wrote:
>>
>>  - Polyhedron() polytopes. (i prefer "Polytope() polytopes." over 
>>"Polyhedron() polyhedrons." since polyhedron is usually specific to 
>>dimension 3).
>
> That is not the usual notation, most authors define a polytope to be a 
> compact polyhedron. The dimension is arbitray. So the constructor should 
> always be "Polyhedron".

Much to my surprise, I found that the English Wikipedia defines a polyhedron
as "a solid in three dimensions with flat faces and straight edges". The
French Wikipedia also just states that a polyhedron is a geometric form in
three dimensions. The German Wikipedia states that in a narrower sense a
polyhedron is as in the English and French Wikipedia, but at least it mentions
that in the broader sense the mathematical notion is different.

I believe that English and French Wikipedia are totally and German Wikipedia
almost totally wrong here. Around my PhD thesis, the theory of polyhedra and
(convex) polytopes was part of my field of expertise, and I totally agree with
Volker that polyhedra are defined in arbitrary dimension and polytopes are
compact polyhedra.

Now we have to decide: Shall Sage adopt a notion that is surprisingly
widespread but is refused by experts of the field? I believe Sage is a
maths software and thus should use notions that are backed up by text
books in the relevant fields, and should not rely on folklore.

Best regards,
Simon


-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sage-devel] Building on SPARC Solaris

[Jeroen Demeyer]

On 2014-01-04 05:11, Volker Braun wrote:

I've spent the whole day trying to build Sage on mark/skynet and I can't
get past the following error. I've tried to copy the buildbot
configuration as far as possible (though not running buildbot, of
course) and the build always fails half-way through the gcc build at:


It always worked for me, I'll have a look some day.

--
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sage-devel] Building on SPARC Solaris

[Dr. David Kirkby]

It looks like a gcc bug. This should be reported to the gcc list. I suspect
it might compile if the gnu bin utile were installed, which include the
assembler, but it might cause other bits of sage to not build

I will try later and see if it buils on my sparc
On Saturday, 4 January 2014, Volker Braun wrote:

> I've spent the whole day trying to build Sage on mark/skynet and I can't
> get past the following error. I've tried to copy the buildbot configuration
> as far as possible (though not running buildbot, of course) and the build
> always fails half-way through the gcc build at:
>
> /home/vbraun/mark/local/var/tmp/sage/build/gcc-4.7.3.p1/gcc-build/./gcc/xgcc
> -B/home/vbraun/mark/local/var/tmp/sage/build/gcc-4.7.3.p1/gcc-build/./gcc/
> -B/home/vbraun/mark/local/sparc-sun-solaris2.10/bin/
> -B/home/vbraun/mark/local/sparc-sun-solaris2.10/lib/ -isystem
> /home/vbraun/mark/local/sparc-sun-solaris2.10/include -isystem
> /home/vbraun/mark/local/sparc-sun-solaris2.10/sys-include-O2 -O0 -g3
> -O2 -O2 -O0 -g3 -DIN_GCC   -W -Wall -Wno-narrowing -Wwrite-strings
> -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition
>  -isystem ./include  -I. -I. -I../.././gcc -I../../../src/libgcc
> -I../../../src/libgcc/. -I../../../src/libgcc/../gcc
> -I../../../src/libgcc/../include   -g0 -finhibit-size-directive -fno-inline
> -fno-exceptions -fno-zero-initialized-in-bss -fno-toplevel-reorder
> -fno-tree-vectorize -fno-stack-protector  -I. -I. -I../.././gcc
> -I../../../src/libgcc -I../../../src/libgcc/. -I../../../src/libgcc/../gcc
> -I../../../src/libgcc/../include  -o crt1.o -MT crt1.o -MD -MP -MF crt1.dep
> -c ../../../src/libgcc/config/sparc/sol2-c1.S
> /usr/ccs/bin/as: "/var/tmp//cci41hCF.s", line 2: error: statement syntax
> /usr/ccs/bin/as: "/var/tmp//cci41hCF.s", line 4: error: statement syntax
> /usr/ccs/bin/as: "/var/tmp//cci41hCF.s", line 6: error: statement syntax
> /usr/ccs/bin/as: "/var/tmp//cci41hCF.s", line 8: error: statement syntax
> /usr/ccs/bin/as: "/var/tmp//cci41hCF.s", line 10: error: statement syntax
> /usr/ccs/bin/as: "/var/tmp//cci41hCF.s", line 12: error: statement syntax
> /usr/ccs/bin/as: "/var/tmp//cci41hCF.s", line 14: error: statement syntax
> /usr/ccs/bin/as: "/var/tmp//cci41hCF.s", line 16: error: statement syntax
> /usr/ccs/bin/as: "/var/tmp//cci41hCF.s", line 18: error: statement syntax
> /usr/ccs/bin/as: "/var/tmp//cci41hCF.s", line 20: error: statement syntax
> /usr/ccs/bin/as: "/var/tmp//cci41hCF.s", line 22: error: statement syntax
> /usr/ccs/bin/as: "/var/tmp//cci41hCF.s", line 24: error: statement syntax
> /usr/ccs/bin/as: "/var/tmp//cci41hCF.s", line 26: error: statement syntax
> /usr/ccs/bin/as: "/var/tmp//cci41hCF.s", line 28: error: statement syntax
>
> Can anybody tell me how to build Sage on mark/skynet?
>
> vbraun@mark:~/mark$ env
> AS=/usr/ccs/bin/as
> SAGE_ATLAS_LIB=/home/buildbot/local/ATLAS/marks
> TERM=xterm-256color
> SHELL=/bin/bash
> SSH_CLIENT=192.168.2.103 45164 22
> LIBRARY_PATH=/home/vbraun/local/mark/lib
> OLDPWD=/home/vbraun
> SSH_TTY=/dev/pts/6
> SAGE_TIMEOUT_LONG=5000
> USER=vbraun
>
> LD_LIBRARY_PATH=/home/vbraun/local/mark/lib:/usr/local/gcc-4.7.0/sparc-SunOS-ultrasparc3/lib:/usr/local/gcc-4.7.0/sparc-SunOS-ultrasparc3/lib/sparcv9:/usr/local/flex-2.5.35/sparc-SunOS-ultrasparc3-gcc-4.4.3/lib
> CPATH=/home/vbraun/local/mark/include
> SAGE_TIMEOUT=2500
> PAGER=less
> MAIL=/var/mail//vbraun
>
> PATH=/home/vbraun/local/mark/bin:/home/vbraun/bin:/usr/local/bin/sparc-SunOS-ultrasparc3:/usr/bin:/usr/ccs/bin
> LD=/usr/ccs/bin/ld
> PWD=/home/vbraun/mark
> SAGE_INSTALL_GCC=yes
> LANG=C
> TZ=US/Eastern
> PS1=\[\e[10;01;31m\]\u@\h:\w\$\[\e[00m\]
> SHLVL=1
> HOME=/home/vbraun
> MAKE=make -j2
> CFLAGS=-O0 -g3
> PYTHONPATH=/usr/local/mercurial-1.5/sparc-SunOS-ultrasparc3/lib/python
> LOGNAME=vbraun
> SSH_CONNECTION=192.168.2.103 45164 192.168.2.105 22
> _=/usr/bin/env
>
>
>
>  --
> You received this message because you are subscribed to the Google Groups
> "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sage-devel+unsubscr...@googlegroups.com  'cvml', 'sage-devel%2bunsubscr...@googlegroups.com');>.
> To post to this group, send email to 
> sage-devel@googlegroups.com 'sage-devel@googlegroups.com');>
> .
> Visit this group at http://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/groups/opt_out.
>


-- 
Dr. David Kirkby G8WRB
http://www.vnacalibration.co.uk/
Economical & accurate VNA calibration kits.
Coefficients available for HP, Agilent, Anritsu, Rohde & Schwarz and VNWA
network analyzers.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more opti

[sage-devel] Re: Building on SPARC Solaris

[Volker Braun]

So apparently this museum piece doesn't understand the -g3 compiler flag. 
Now I can compile gcc, but then the build dies shortly after that.

On Friday, January 3, 2014 6:13:09 PM UTC-10, Volker Braun wrote:
>
> PS: In case it is not clear, SAGE_ROOT=/home/vbraun/mark
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sage-devel] User friendly output for divergant integrals/sum

[Volker Braun]

It would still be nice to return +-oo if the improper integral diverges to 
infinity. E.g.

sage: integrate(1/x, (x, 1, oo))   # raises ValueError instead
oo
sage: integrate(1/sqrt(x), (x, 0, 1))  # this improper integral is evaluated
2

I agree that printing something instead of raising an error is never a good 
idea.


On Friday, January 3, 2014 9:44:29 PM UTC-10, Snark wrote:
>
> Le 04/01/2014 07:12, Vibhav Pant a �crit : 
> > Sage currently handles divergant integrals/sums by raising a ValueError, 
> wouldn't it be nice if a more user friendly output (like infinity or 
> printing "divergant integral") could be used instead of raising an 
> exception? 
>
> Printing something nice for the user is ok if it's the only computation 
> done. In a longer program, an exception is better. 
>
> Snark on #sagemath 
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.