On 04/02/2017 03:01 AM, oldk1331 wrote:
> 'monomial?' for SMP/POLY/POLYCAT originates from
> AbelianMonoidRing:
>
> monomial? : % -> Boolean
> ++ monomial?(p) tests if p is a single monomial.
>
> 'monomial?' for SUP/UPOLYCAT originates from
> IndexedDirectProductCategory:
>
> mon
> I would be happy to participate in
> adding FriCAS as a "community supported language" in Travis if anyone
> else is interested.
Bill, I think the "community supported language" means that it'll be easier
for other Spad project, while there's not much Spad project, I think that is
unnecessary.
In the long term, I would support the usage of BasicOperator
to replace Symbol. Because BasicOperator is more accurate,
it will not mistake a variable for operator. But since Symbol
version functions are widely used, it would be a big project
and take a long time to do so.
--
You received this
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
'monomial?' for SMP/POLY/POLYCAT originates from
AbelianMonoidRing:
monomial? : % -> Boolean
++ monomial?(p) tests if p is a single monomial.
'monomial?' for SUP/UPOLYCAT originates from
IndexedDirectProductCategory:
monomial? : % -> Boolean
++ \spad{monomial?(x)} return
On 1 April 2017 at 10:46, Martin Baker wrote:
> On 31/03/17 14:08, Bill Page wrote:
>>
>> Perhaps one of the things that makes this resistance to such changes
>> seem sound is that FriCAS lacks anything approaching a comprehensive
>> test system. This makes it quite possible that changes such as w
oldk1331 wrote:
>
> > I do not think we need new domain. In fact, we want the
> > same simplifications to apply to more general expressions.
> > Certainly it makes sense to implement better simplification
> > of radicals.
>
> Can you be more specific about this 'simplifyRadical'?
>
> For radica
On 31/03/17 14:08, Bill Page wrote:
Perhaps one of the things that makes this resistance to such changes
seem sound is that FriCAS lacks anything approaching a comprehensive
test system. This makes it quite possible that changes such as we
propose could have far reaching effects which are not pos
oldk1331 wrote:
>
> Hmm,
>
> (1) -> monomial?(0::POLY INT)
>
>(1) true
> Type: Boolean
> (2) -> monomial?(0::SUP INT)
>
>(2) false
> Type: Boolean
>
> Is th
Hmm,
(1) -> monomial?(0::POLY INT)
(1) true
Type: Boolean
(2) -> monomial?(0::SUP INT)
(2) false
Type: Boolean
Is there a problem?
--
You received this messa
I have benchmarked, 'monomial?' is much faster (O(n) to O(1)).
Off topic a little, 'constructOrdered' and 'listOfTerms' uses shared
structure, that's good for performance, but may cause unwanted
changes. One should be careful to use these functions. I take
a look at current usage, seems good so
11 matches
Mail list logo
