I was a bit surprised about the following:
sage: k = ZZ["q"].hom(QQ["q"])
sage: isinstance(k, Morphism)
True
sage: m = ZZ["q,t"].hom(QQ["q,t"])
sage: isinstance(m, Morphism)
False
However, I vaguely recall a discussion about morphisms between multivariate
polynomial rings being problematic. Doe
Given SR constant, I want to extract the first L base B digits
of the fractional part.
So far the best solution I found is:
floor((SR(expression)*B**L).numerical_approx(digits=L)).digits(B)
Can I do better?
Why the following approach fails numerically:
```
def base_B_digits(A, B,prot=False):
I assume you should use floor division to preserve accuracy. As a
numerical example, say you want the first 100 /decimal/ digits of 3 /
173. That's the same as floor(10^100 * 3 / 173).
In [105]: from decimal import Decimal, getcontext
...: getcontext().prec = 300
...: print(10**100 *
One question, Matthias: I see that you have proposed a project involving
integration with proof assistants/theorem provers. Just out of curiosity:
how do you envision such integration?
El martes, 6 de febrero de 2024 a las 6:56:44 UTC+1, Matthias Koeppe
escribió:
> Great, thanks a lot, Travis
Hi Miguel,
There's of course a large scope of work that can be meaningful. I'll just
mention two directions, but I'll be happy to have a broader and/or more
detailed conversation.
1. For interactive proof assistants/theorem provers such as LEAN, it can be
powerful to make CAS capabilities availa
We added the packages as optional "pip" packages
(see
https://deploy-livedoc--sagemath.netlify.app/html/en/developer/packaging#package-types
for the terminology), each more than 1 year ago.
-
https://deploy-livedoc--sagemath.netlify.app/html/en/reference/spkg/pytest#spkg-pytest
(added in 20
On Sat, Feb 10, 2024 at 10:18 PM Matthias Koeppe
wrote:
>
> We added the packages as optional "pip" packages (see
> https://deploy-livedoc--sagemath.netlify.app/html/en/developer/packaging#package-types
> for the terminology), each more than 1 year ago.
>
> -
> https://deploy-livedoc--sagemath.
On Saturday, February 10, 2024 at 2:56:57 PM UTC-8 Dima Pasechnik wrote:
yes, make them standard, but keep them pip packages (i.e. no version
pinning, no tarballs/checksums).
By current policy, "standard" packages cannot be "pip" packages. This is
documented in
https://deploy-livedoc--sagemat
On 10 February 2024 23:40:59 GMT, Matthias Koeppe
wrote:
>On Saturday, February 10, 2024 at 2:56:57 PM UTC-8 Dima Pasechnik wrote:
>
>yes, make them standard, but keep them pip packages (i.e. no version
>pinning, no tarballs/checksums).
>
>
>By current policy, "standard" packages cannot be "p
On Saturday, February 10, 2024 at 4:09:32 PM UTC-8 Dima Pasechnik wrote:
How about we initiate a vote on letting standard packages be pip packages?
You can make such a change of policy your project, but the present vote
will not wait for it.
--
You received this message because you are subscr
Hi Dima,
I believe I'm the person who introduced that long standing policy. It
was indeed motivated by a significant paying customer's requirement
to install Sage entirely from source, and without an external network.
I believe no such customers have supported the Sage project for about
a decade,
(Also, thanks everyone for so far taking extra effort to be civil when
discussing the topic of vendored
dependencies, which I know touches a nerve for people.)
On Sat, Feb 10, 2024 at 4:36 PM William Stein wrote:
>
> Hi Dima,
>
> I believe I'm the person who introduced that long standing policy.
12 matches
Mail list logo
