Actually, base ring is preserved already. Just assumed it gets lost as well.
The backend is lost though.
Something as
sage: polytopes.dodecahedron(backend='normaliz').pyramid()
will create a polyhedron with backend 'field'.
Am Montag, 3. Juni 2019 23:31:29 UTC+2 schrieb vdelecroix:
>
> To my m
Mon 2019-06-03 22:45 UTC, darwin doppelganger:
>
> By the way, why are we seeing Mac users compiling Sage
> for themselves rather than just downloading an executable?
> Is it anything to do with the double-clickable Mac application
> problem that appeared on Mac OSX 10.4 (Mojave)?
One might want t
On Monday, June 3, 2019 at 12:15:28 PM UTC-5, Samuel Lelievre wrote:
>
> ...
> Would it make sense to mitigate this frequent source of problems
> for Sage users by detecting the presence of Anaconda and issuing
> a helpful message indicating Anaconda was detected and it being
> in the PATH is li
To my mind:
* backend and base ring should be preserved by default. Of course
it should make sense: a translation by sqrt(2) would break the
base ring QQ.
* no need to create one ticket for each method if this is mostly
the same action to be done for each of them. If some method needs
Hello: I do have a skylake architecture (10-core, i9-7900X), and the
assembler is as: GNU assembler version 2.27-34.base.el7. Unfortunately
make -j1 openblas also gave the same error message. I tried ./configure
with_blas=atlas, and got: a new error! (that seems like an improvement,
actual
At the moment the backend setting is lost, when constructing a pyramid of a
Polyhedron.
Same holds for all other constructions.
I think that all constructions should respect the backend of self. I intend
to create tickets (one by one) for each construction in Polyhedron_base
(that gives a new
Mon 2019-06-01 06:20:39 UTC, E. Madison Bray:
>
> On Sun, Jun 2, 2019 at 11:46 PM darwin doppelganger:
> >
> > I responded to a similar posting with a link to directions
> > for removing anaconda. It seems to have worked just fine,
> > but Dima's suggestion sounds easier.
>
> One thing I've noti
It appears that it is not an issue of this particular old system as
Matthias pointed out. I would appreciate further help at
https://trac.sagemath.org/ticket/27907 to figure out how to provide the
correct version of
[gcc-7.2.0] /usr/lib/../lib/crti.o: could not read symbols: File in
wrong
On Mon, 3 Jun 2019 at 08:41, E. Madison Bray wrote:
> Well, this would be a problem building OpenBLAS specifically :)
>
> I see this same problem mentioned here as well. Maybe it will help:
> https://github.com/JuliaLang/julia/issues/30696
>
> I'm not sure I understand the patch on that issue th
