> Of course 'simplify' and friends can simplify them at will.
I think simplifExp should handle that, I'll add it in a separate patch.
> - If we want sane semantics for Expression(Float) we should
> convert floats to rationals in almost all places. Some other
> systems allow users to put floa
oldk1331 wrote:
>
> (1) -> (x::EXPR INT)^(-3.4)
>
>1.0
>(1)
> 3 5+-+2
> x \|x
> Type: Expression(Float)
>
>
> I don't think this result is correct. It can get very ugly
> because of the nature of
>
> > Of course the problem is due to approximate nature of floating
> > point numbers. And we have Approximate for such purpose.
> > But ATM:
> >
> > (11) -> Complex(Float) has Approximate
> >
> >(11) false
> >
> > We can build a lot of strange domains. Expression(PrimeField(3))
> > and si
oldk1331 wrote:
>
> Related questions:
>
> (1) -> (0::EXPR INT)^(x::EXPR INT)
>
> x
>(1) 0
> Type: Expression(Integer)
> (2) -> (1::EXPR INT)^(x::EXPR INT)
>
> x
>(2) 1
>
Related questions:
(1) -> (0::EXPR INT)^(x::EXPR INT)
x
(1) 0
Type: Expression(Integer)
(2) -> (1::EXPR INT)^(x::EXPR INT)
x
(2) 1
Type: Expression(Integer)
Should t
> Of course the problem is due to approximate nature of floating
> point numbers. And we have Approximate for such purpose.
> But ATM:
>
> (11) -> Complex(Float) has Approximate
>
>(11) false
>
> We can build a lot of strange domains. Expression(PrimeField(3))
> and similar are likely to sho
oldk1331 wrote:
>
> (1) -> (x::EXPR INT)^(-3.4)
>
>1.0
>(1)
> 3 5+-+2
> x \|x
> Type: Expression(Float)
>
>
> I don't think this result is correct. It can get very ugly
> because of the nature of
(1) -> (x::EXPR INT)^(-3.4)
1.0
(1)
3 5+-+2
x \|x
Type: Expression(Float)
I don't think this result is correct. It can get very ugly
because of the nature of Float (a big fraction).
In combfunc.spad
