On 09/27/2013 10:57 AM, kcrisman wrote:
From a user. I'm not sure how the matplotlib devels would feel about
adding this. And which RGB value would it be, anyway? ;-)
+++
One of my students pointed out a weird flaw in Sage today. Namely, in
the plotting color options, 'sage' is not a known co
When in doubt about rgb colors, consult xkcd: http://xkcd.com/color/rgb/
There he identifies sage (87ae73), light sage (bcecac), dark sage (598556), and
sage green (88b378).
-Ivan
On Sep 26, 2013, at 8:57 PM, kcrisman wrote:
> From a user. I'm not sure how the matplotlib devels would feel ab
>From a user. I'm not sure how the matplotlib devels would feel about
adding this. And which RGB value would it be, anyway? ;-)
+++
One of my students pointed out a weird flaw in Sage today. Namely, in the
plotting color options, 'sage' is not a known color name. So, e.g.,
plot((e^(sin(x))),
1. I agree that "discrete" was a poor name choice
2. Would we want to add a package that implements a single (very
elementary) class? (no)
3. I, for one, would like to keep Sage's documentation apolitical --
I'd rather to see some mathematical examples than those provided.
On Thu, Sep 26, 2013 at
That is the expected result on OSX 10.6. Well-known bug in the OSX
accelerate framework which Apple never fixed.
>> >> > 1. BUG REPORT
> >> >> > `scipy.linalg.blas.sdot` gives wrong results on mac:
> >> >> >
> >> >> > >>> scipy.linalg.blas.sdot(np.array([ 10.], dtype=np.float32),
> >> >> > >
On Thu, Sep 26, 2013 at 11:35 AM, Arnaud Bergeron wrote:
> 2013/9/26 William Stein
>>
>> On Thu, Sep 26, 2013 at 10:04 AM, Arnaud Bergeron
>> wrote:
>> > Or scipy is badly compiled. Since OS X does not ship with a fortran
>> > compiler it is especially hard to compile and link it properly with
On 9/26/13 3:16 AM, Maarten Derickx wrote:
I would definitely use such a construction.
+1. I often wish for something like this when relabeling a graph, for
example.
Jason
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from
On Wednesday, September 25, 2013 9:59:46 AM UTC-7, Tom wrote:
>
> For iso/automorphisms of graphs, I often wish that dictionaries were
> both callable and invertible. In general, yes, I think
> DiscreteFunction and DiscreteBijection classes would be very useful.
>
Does https://pypi.python.org/
1) Please give the output of the following command, both from a normal
shell and from within the Sage shell (sage --sh):
$ ldd /data2/sage-5.11/local/lib/gcc/x86_64-unknown-linux-gnu/4.7.3/cc1
2) Is the error reproducible (does it happen again if you run "make")?
3) Did you use MAKE="make -jN"
Numpy only does machine datatypes and python objects. You can do a numpy
array of python wrappers of mpfr reals but that would not be a good
solution here.
If the library is under your own control, I would recommend to use C++
instead of C and then design the interface around std::vector. This
On 2013-09-25, Volker Braun wrote:
> A pointer to a dynamically malloc'ed array doesn't know how long the array
> is. Your C library function must returns its size, too. You can then read
> it out one-by-one but you can't call list(c_array) since the latter doesn't
> even know how long it is.
I would definitely use such a construction. It would be nice to have a
data structure that behaves like 1:1 correspondence or as in your case 1 to
many correspondances instead of needing to keep two dictionaries. It would
make life a lot easier because you loose the need of a double
administra
12 matches
Mail list logo
