At the end of the day, you are writing a toy implementation of an algorithm
that can be used for teaching. It is also a great resource to check results
of more optimized algorithms, so I see it as a useful part of the Sage
library whether you use it for teaching or not.
In this particular case
On Sun, Mar 17, 2013 at 5:19 PM, Andrey Novoseltsev wrote:
> Hello,
>
> http://trac.sagemath.org/sage_trac/ticket/14288 provides a module for
> teaching the simplex method, i.e. you should NOT use it routinely to
> just get solutions of optimization problems. Dima has pointed out that
> an optiona
Hello,
http://trac.sagemath.org/sage_trac/ticket/14288 provides a module for
teaching the simplex method, i.e. you should NOT use it routinely to
just get solutions of optimization problems. Dima has pointed out that
an optional package may be more appropriate in such cases. Does anyone
else has a
On 03/09/2013 06:40 PM, Montgomery-Smith, Stephen wrote:
> Building on FreeBSD, the doc creation process freezes after this point:
>
> [history_a] loading pickled environment... not yet created
> [history_a] building [inventory]: targets for 1 source files that are
> out of date
> [history_a] upda
Julien Puydt wrote:
H... there is no .hg in $SAGE_ROOT/devel/sage/, but there is one in
$SAGE_ROOT/, another in $SAGE_ROOT/local/bin/, another in
$SAGE_ROOT/devel/sage-main/ and a fourth in
$SAGE_ROOT/devel/ext-main/... [looking at a freshly compiled sage 5.7 on
my ARM box]
:-) devel/sage i
Well it is registered under my name so I'm not going to post the keys to
the mailing list ;-) But as far as I understand it, the MKL binaries can
be distributed. I haven't had time yet to really look and see what the
non-distributable part is (partly because my laptop died).
On Sunday, Marc
Well it is registered under my name so I'm not going to post the keys to
the mailing list ;-) But as far as I understand it, the MKL binaries can
be distributed. I haven't had time yet to really look and see what the
non-distributable part is (partly because my laptop died).
On Sunday, Marc
On Sunday, March 17, 2013 9:07:41 AM UTC-4, Nathann Cohen wrote:
> But I have no way to give a meaningful error message if the user feeds it
> with any other non-hashable iterable :-/
>
On the contrary, the error message that you get right now is 100% spot on.
--
You received this message bec
Le 17/03/2013 15:22, leif a écrit :
than...@debian.org wrote:
Am Samstag, 16. März 2013 20:57:13 UTC+1 schrieb leif:
But if we switch to git, improve Sage's package management (as a first
step, split vanilla upstream sources off the spkgs :P ), ...
Is splitting the vanilla upstream sources off
than...@debian.org wrote:
Am Samstag, 16. März 2013 20:57:13 UTC+1 schrieb leif:
But if we switch to git, improve Sage's package management (as a first
step, split vanilla upstream sources off the spkgs :P ), ...
Is splitting the vanilla upstream sources off planned? That would be
very
Well, the function only takes tuples as input right now.
But I have no way to give a meaningful error message if the user feeds it
with any other non-hashable iterable :-/
Nathann
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe fr
HellO !!!
> The error message tells it: Lists (as opposed to tuples) can not be used
> as keys of a dictionary (are unhashable), because they are mutable.
>
> The values computed by a cached_function are stored in a dictionary
> (unless it is a cached method that takes no arguments apa
Hi Nathann,
On 2013-03-17, Nathann Cohen wrote:
> TypeError: unhashable type: 'list'
>
> ...
>
> Would anybody here know what's happening ?
The error message tells it: Lists (as opposed to tuples) can not be used
as keys of a dictionary (are unhashable), because they are mutable.
The values com
Hellooo everybody !
I was writing a (very short) patch to expose a feature from GAP (#14291),
and the ony thing keeping it from passing all tests seems to be the caching
mechanism. My method is meant to catch TypeError exceptions, but they still
walk through my try/except.
Here's the behaviou
On 2013-03-17 09:38, Julien Puydt wrote:
> The impression I have is that
> by default, a patch in an spkg has not.
It really should be. It doesn't mean that upstream will *accept* the
patch of course.
Or sometimes, Sage contains patches to spkgs which are just meant for
the Sage <-> package inter
On 17/03/13 21:38, Julien Puydt wrote:
> Le 17/03/2013 00:36, than...@debian.org a écrit :
>> Is splitting the vanilla upstream sources off planned? That would be
>> very helpful for distributions. Another helpful thing would be a clear
>> distinction between fixes/adjustment to the library and Sag
On 17/03/13 10:43, Volker Braun wrote:
> Just FYI, I received an Linux/OSX Intel MKL license (its closed-source
> BLAS) for the Sage project . As I've written earlier, I'm planning to
> make Sage more vendor-agnostic so we don't have ATLAS hardcoded everywhere.
>
Cool. Is it only for you personal
Le 17/03/2013 00:36, than...@debian.org a écrit :
Is splitting the vanilla upstream sources off planned? That would be
very helpful for distributions. Another helpful thing would be a clear
distinction between fixes/adjustment to the library and Sage glue,
because we need all the Sage glue, but w
18 matches
Mail list logo
