It should be like
a=42
k=3
sage: a.multifactorial(k)
On Wednesday, October 28, 2015 at 2:50:01 PM UTC+5:30, Dima Pasechnik wrote:
>
>
>
> On Wednesday, 28 October 2015 02:11:59 UTC-7, prateek sharma wrote:
>>
>> Hi,
>> I am looking for multifactorial function in the source code but unable
>> to.
On Thursday, October 29, 2015 at 10:07:33 AM UTC-7, Nathann Cohen wrote:
>
> Hello,
>
> > Since we can already detect doctests, and among those we can already
> detect
> > the various doctest flags, we should be able to hide those flags. The
> TESTS
> > blocks are a different situation. If w
On 2015-10-29 18:30, William Stein wrote:
That would be incompatible and inconsistent with IPython, which is
used (very) widely outside of Sage, and also *is* the sage command
line.
I agree with William. We should stay as compatible with IPython as we
can (which also implies that we should pus
> Nothing prevents you from writing
>
> # random (platform-dependent)
HMmmm.. Right, makes sense.
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-de
On 2015-10-29 19:15, Nathann Cohen wrote:
Yo,
Now, to give a testable example of this kind of function one must put
sorted() to output or do someting like (1 in result, 2 in result) --> True.
Should we show them to user? I think that this could be argued to both
directions.
In those cases I'
On Thursday, 29 October 2015 10:43:27 UTC-6, Michael Orlitzky wrote:
>
> On 10/29/2015 10:47 AM, William Stein wrote:
> >
> > In the meantime, I may just have to patch Sage to get rid of the
> > interactive nature of "-i"... or use some workaround involving
> > > automate.
>
> yes | sage -i
Yo,
> Now, to give a testable example of this kind of function one must put
> sorted() to output or do someting like (1 in result, 2 in result) --> True.
>
> Should we show them to user? I think that this could be argued to both
> directions.
In those cases I'd say that '# random' does the job. T
Another thing about TESTS and EXAMPLES. Many functions returns
semantically a set but technically a list. Neighbours of a vertex in a
graph is an example. There is nothing wrong for these to return for
example [1,2] on PC and [2,1] on a Mac.
Now, to give a testable example of this kind of func
On Thu, Oct 29, 2015 at 11:03 AM, Nathann Cohen wrote:
> [...] come show us that you still know how to write python code.
Flame bait.
https://groups.google.com/forum/#!forum/sage-flame
http://wiki.sagemath.org/CodeOfConduct
--
William (http://wstein.org)
--
You received this message because
> There is no place for tests that cannot be automatically run somehow
> in our test suite.
O_o
Since when? Says who? Surely you care about the pedagogical of doctests?
This graph [1] is a counterexample to a conjecture. It was expected to
be hamiltonian, and it is not. In the doctest, I says th
On Thu, Oct 29, 2015 at 10:42 AM, Nathann Cohen wrote:
>> That's what
>>
>> # long time
>>
>> is supposed to be for.
>
> I don't think so. You wouldn't want to see a doctest take one hour to
> run, even if it is flagged with 'long time'. I don't know about you,
> but I run 'long' doctests seve
> That's what
>
> # long time
>
> is supposed to be for.
I don't think so. You wouldn't want to see a doctest take one hour to
run, even if it is flagged with 'long time'. I don't know about you,
but I run 'long' doctests several time per day on some files.
>> The same happens for some doctes
On Thu, 29 Oct 2015, William Stein wrote:
foo??? should do what foo?? does now, i.e. show the source. foo?? should do
what foo? does now, and foo? should hide TESTS, ALGORITHM and AUTHOR.
That would be incompatible and inconsistent with IPython - -
OK. Then maybe foo? , foo?+ and foo?? ?
-
On Thu, 29 Oct 2015, William Stein wrote:
The same happens for some doctests that rely on optional LP solvers:
they can take <1s with CPLEX/Gurobi, but 'standard sage' (with GLPK)
cannot be expected to ever solve them.
So if a user tries to use them they will be effectively broken?
But do w
On Thu, Oct 29, 2015 at 10:22 AM, Jori Mäntysalo wrote:
> On Thu, 29 Oct 2015, John H Palmieri wrote:
>
>> Should it hide "TESTS" blocks? Same questions when you ask for interactive
>> help via "foo?".
>
>
> foo??? should do what foo?? does now, i.e. show the source. foo?? should do
> what foo? do
On Thursday, October 29, 2015 at 10:12:59 AM UTC-7, Nathann Cohen wrote:
>
> > Yep! That's why I called it "not tested". In my opinion, the only
> > reasonable change would be
> >
> > " # not tested" > " # broken"
> >
> > That would probably create an even more accurate impress
On Thu, 29 Oct 2015, John H Palmieri wrote:
Should it hide "TESTS" blocks? Same questions when you ask for
interactive help via "foo?".
foo??? should do what foo?? does now, i.e. show the source. foo?? should
do what foo? does now, and foo? should hide TESTS, ALGORITHM and AUTHOR.
--
Jori M
On Thu, Oct 29, 2015 at 10:12 AM, Nathann Cohen wrote:
>> Yep! That's why I called it "not tested". In my opinion, the only
>> reasonable change would be
>>
>> " # not tested" > " # broken"
>>
>> That would probably create an even more accurate impression.
>
> I flagged many doctests
> Yep! That's why I called it "not tested". In my opinion, the only
> reasonable change would be
>
> " # not tested" > " # broken"
>
> That would probably create an even more accurate impression.
I flagged many doctests with 'not tested' because running them would
take 10+s per funct
On Thu, Oct 29, 2015 at 5:30 AM, Jeroen Demeyer wrote:
> On 2015-10-29 13:23, Samuel Lelièvre wrote:
>>
>> However, to the non-expert eye, such as a non-developer user
>> reading the documentation, seeing "# not tested" produces the
>> impression that this piece of code is not guaranteed to work,
Hello,
> Since we can already detect doctests, and among those we can already detect
> the various doctest flags, we should be able to hide those flags. The TESTS
> blocks are a different situation. If we insist that TESTS blocks are always
> the last thing in the docstring, I can imagine it worki
On 10/29/2015 10:47 AM, William Stein wrote:
>
> In the meantime, I may just have to patch Sage to get rid of the
> interactive nature of "-i"... or use some workaround involving
> automate.
yes | sage -i csdp
--
You received this message because you are subscribed to the Google Groups
"sage
On Thursday, October 29, 2015 at 8:59:04 AM UTC-7, Nathann Cohen wrote:
>
> > How important is it that the user see any of these? Should our
> documentation
> > build hide these labels altogether? Should it hide "TESTS" blocks? Same
> > questions when you ask for interactive help via "foo?".
> How important is it that the user see any of these? Should our documentation
> build hide these labels altogether? Should it hide "TESTS" blocks? Same
> questions when you ask for interactive help via "foo?".
This has been asked in different forms on this forum. I don't think
that there was any
How important is it that the user see any of these? Should our
documentation build hide these labels altogether? Should it hide "TESTS"
blocks? Same questions when you ask for interactive help via "foo?".
John
On Thursday, October 29, 2015 at 5:54:26 AM UTC-7, Nathann Cohen wrote:
>
> Ar
On Thu, Oct 29, 2015 at 4:57 AM, Volker Braun wrote:
> On Thursday, October 29, 2015 at 12:44:23 PM UTC+1, Nathann Cohen wrote:
>>
>> We need this at least in the case of a non-gpl-compatible package.
>
>
> No. The default should be to error out, and a command line switch like
> "--accept-license=
On 2015-10-29 12:44, Nathann Cohen wrote:
If you think that this package is okay, then make it pass optional tests
and it can become optional.
Exactly: if there is an experimental package you care about, try to make
it optional.
--
You received this message because you are subscribed to the
Arg... Sorry I misread. I have to live with half a brain these days.
I'm +1 to the change 'not tested' -> 'skip' for the reason that you
gave in your first message.
I'm not too keen on adding 'doctest:' everywhere though. Some of us
type these things often.
Nathann
On 29 October 2015 at 13:
On 29/10/15 09:23, Samuel Lelièvre wrote:
When consulting the documentation, many code fragments
have annotations that are meant as doctesting instructions.
Among these doctesting instructions, there is one, "# not tested",
that tells the doctesting mechanism to skip that line in doctests.
Howe
+1. Please update the developer's manual if you change this.
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 p
Le jeudi 29 octobre 2015 13:23:56 UTC+1, Samuel Lelievre a écrit :
>
>
> - # not tested
> + # doctest: skip
>
> - # not tested (random order)
> + # doctest: skip (random order)
>
> - # optional - qepcad
> + # doctest: optional - qepcad
>
>
+1
Eric.
--
You received
+1
Eric.
--
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
On 2015-10-29 13:23, Samuel Lelièvre wrote:
However, to the non-expert eye, such as a non-developer user
reading the documentation, seeing "# not tested" produces the
impression that this piece of code is not guaranteed to work,
because it has never been tested.
That impression is 100% right.
When consulting the documentation, many code fragments
have annotations that are meant as doctesting instructions.
Among these doctesting instructions, there is one, "# not tested",
that tells the doctesting mechanism to skip that line in doctests.
However, to the non-expert eye, such as a non-de
On 29/10/15 08:57, Volker Braun wrote:
On Thursday, October 29, 2015 at 12:44:23 PM UTC+1, Nathann Cohen wrote:
We need this at least in the case of a non-gpl-compatible package.
No. The default should be to error out, and a command line switch like
"--accept-license=foo" or "--nonfree"
A
> It's not because "one of you" claims something without justification that it
> becomes truth.
Then I don't believe what you just said.
Nathann
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving em
On 2015-10-29 12:57, Nathann Cohen wrote:
and one of you said that it was not allowed somehow.
It's not because "one of you" claims something without justification
that it becomes truth.
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsu
Yo,
> No. The default should be to error out, and a command line switch like
> "--accept-license=foo" or "--nonfree"
I wouldn't mind at all.
Nathann
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receivi
> Why do you think that?
I think I read that here on a related thread. It talked of the
situations in which a guy types "sage -i package1" (with package1
GPL-compatible), but that package1 has package2 as a dependency, with
package2 not gpl-compatible.
In this situation the user only explicitly a
On Thursday, October 29, 2015 at 12:44:23 PM UTC+1, Nathann Cohen wrote:
> We need this at least in the case of a non-gpl-compatible package.
No. The default should be to error out, and a command line switch like
"--accept-license=foo" or "--nonfree"
> Also, this message appears because we
On 2015-10-29 12:44, Nathann Cohen wrote:
We need this at least in the case of a non-gpl-compatible package. The
guy has to say "I agree"
Why do you think that?
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and
Yo,
> Command-line tools shouldn't ask stupid questions, this totally defeats
>> the use of the commandline UI as building blocks for writing scripts. I
>> said that before but it nobody is listening ;-)
>>
>
> You are right!
>
We need this at least in the case of a non-gpl-compatible package.
Just to spell out the obvious: By the principle of least surprise the
working directory should always be the same if possible.
On Wednesday, October 28, 2015 at 1:28:15 AM UTC+1, Andrey Novoseltsev
wrote:
>
> I have ran
>
> import subprocess
> print subprocess.check_output("pwd")
> print r.eva
For those who don't know about CSDP (like me 5 min ago),
CSDP is a "C Library for Semidefinite Programming".
Homepage:
https://projects.coin-or.org/Csdp/
Added as an experimental package for Sage two years ago,
see SageMath trac ticket #14505:
http://trac.sagemath.org/ticket/14505
Used b
On 2015-10-29 00:11, Dima Pasechnik wrote:
Dear all,
can we promote CSDP to optional?
It it works properly on all supported systems, passes doctests... then sure.
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group an
45 matches
Mail list logo
