> One remark: if we want just preserve existing functionality,
> then the simplest way is probably to remove the third argument to
> Localize and LocalAlgebra. Namely, currentlty there is probably
> no way to create nontrivial domain of SubsetCategory, so the
> in working code third argument will be the same as the second
> one.
Oh, good that you yourself say this. I was exactly thinking in this
direction and wanted to create a two parameter Localize and LocalAlgebra
(*in addition*, in order not to break other people's code that relies on
3-parameter version).
But yes, I am very much in favour of removing the third parameter. Or
rather to replace it with a boolean function in the following sense
(It's similar to SubDomain.):
Instead of
Localize(M:Module R,
R:CommutativeRing,
S:SubsetCategory(Monoid, R)): Module R with
we would have
Localize(M:Module R,
R:CommutativeRing,
denominator?: R -> Boolean): Module R with
where denominator is the characteristic function for the subset S of R
that can be used for denominators.
Of course, there is a big problem: It cannot be ensured that the set of
all r for which denominator?(r) returns true is indeed a sub-monoid of
R. But in some way that is as troublesome as is the second parameter of
SubDomain. Nothing would currently prevent me to define
MyPosInt: AbelianMonoid == SubDomain(Integer, #1>0) add (x:%)
So this 'denominator?' parameter would not make things much worse.
> Your patch actually makes Localize more general, because
> it allows different representation for S -- AFAICS you can
> use
>
> Localize(M, Polynomial Integer, MyInteger)
>
> where MyInteger is Integer with extra coercion to Polynomial Integer.
Yes.
> Extra generality may be good, but I wonder if gain (possibility
> to use different representation and checking that denominators
> really belong to S) is worth the cost (possible performance loss).
The most common domain like Fraction should not suffer. But with my
change it possibly does (adding a coerce: %->% panelty that is avoidable
by a two-parameter Localize).
> Also, it is not clear how well S different from R would work
> -- I must admit that current Localize and LocalAlgebra look
> half-baked to me.
>
> BTW: While LocalAlgebra is mentioned in solverad.spad.pamphlet
> AFAICS it is actually unused.
Oh, good observation.
> So it seems that the only current
> use of Localize and LocalAlgebra is via Fraction.
In this case, I would even go to the extreme and remove LocalAlgebra and
Localize completely. If somebody later sees some need for their
reimplementation then we have someone who is familiar with all the
issues and who knows probably some use cases that should work.
Ralf
PS: It seems that I am trying to get rid of FriCAS functionality. I hope
nobody beats me for that... ;-)
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/fricas-devel?hl=en
-~----------~----~----~----~------~----~------~--~---
