Waldek,
you are amazing!!! A big thanks for the radicalSolve patch.
Ralf
On 5/16/24 15:12, Waldek Hebisch wrote:
On Tue, May 14, 2024 at 03:04:15PM +0200, Ralf Hemmecke wrote:
In fact, the value xx is one of radicalRoots(pp) where
pp :=
On Tue, May 14, 2024 at 03:04:15PM +0200, Ralf Hemmecke wrote:
>
> In fact, the value xx is one of radicalRoots(pp) where
>
> pp :=
> x^4-2729960418308000*x^3-39525843924335225*x^2-554995209477163915*x-34536365622665802676562500
>
> Interestingly, when I put xx into
On Wed, May 15, 2024 at 07:28:50PM +0800, Qian Yun wrote:
> OK, so for radicals, there should be a much more effective
> method to determine its sign. Seems like current method is
> mostly focused on polynomials and pretty limited for radicals.
We are looking at sign of argument to a radical.
OK, so for radicals, there should be a much more effective
method to determine its sign. Seems like current method is
mostly focused on polynomials and pretty limited for radicals.
- Qian
On 5/15/24 19:12, Waldek Hebisch wrote:
On Wed, May 15, 2024 at 06:47:45PM +0800, Qian Yun wrote:
You
On Wed, May 15, 2024 at 06:47:45PM +0800, Qian Yun wrote:
> You said before AlgebraicNumber should represent any branch
> of the root, but here we are talking about the sign of radical.
>
> Does that mean we are taking a specific branch interpretation here?
Yes. Othewise there is problem with
You said before AlgebraicNumber should represent any branch
of the root, but here we are talking about the sign of radical.
Does that mean we are taking a specific branch interpretation here?
- Qian
On 5/15/24 17:42, Waldek Hebisch wrote:
TrigonometricManipulations (which implements imag) is
Thank you, Waldek,
that explains the behaviour much better. I suspected that there must be
some numerics involved, but when I had put debugging output near places
where I saw Float-s, that never appeared, so I got a bit confused and
didn't want to waste more time on this.
Potentially, I
On Wed, May 15, 2024 at 07:19:08AM +0200, Ralf Hemmecke wrote:
> On 5/15/24 01:21, Qian Yun wrote:
> > One possible explanation:
> >
> > )compile a spad file clears internal Kernel cache.
> >
> > So the following computation can have messed up Kernel order.
> >
> > So after compiling a spad
On 5/15/24 01:21, Qian Yun wrote:
One possible explanation:
)compile a spad file clears internal Kernel cache.
So the following computation can have messed up Kernel order.
So after compiling a spad file, do not use kernels created before that.
OK, that explains some of the oddity, but not
One possible explanation:
)compile a spad file clears internal Kernel cache.
So the following computation can have messed up Kernel order.
So after compiling a spad file, do not use kernels created before that.
- Qian
On 5/14/24 22:40, Ralf Hemmecke wrote:
Some more experiments with the
Some more experiments with the imaginary part...
Can someone reproduce/explain the strange behaviour of the attached script?
Please modify the path to efstruc.spad accordingly.
Ralf
--
You received this message because you are subscribed to the Google Groups "FriCAS -
computer algebra
Trying
pp :=
x^4-2729960418308000*x^3-39525843924335225*x^2-554995209477163915*x-34536365622665802676562500
xxx := radicalRoots(pp,'x)$RadicalSolvePackage(INT)
x4 := xxx.4
)set mess bot on
in a fresh session gives
%%% (14) -> imag(x4)
Function Selection for imag
Admittedly, it might be difficult to extract the imaginary part of a
radical expression. But that seems to look like a bug.
%%% (412) -> xx :=
13 matches
Mail list logo
