Johannes Grabmeier wrote:
>
> Am Dienstag, 14. April 2009 23:34 schrieb Waldek Hebisch:
> > Johannes Grabmeier wrote:
> > > following strange and not desired effect:
> > >
> > > 1. Compiling a package NCFLOAT with parameter R: Ring
> > > 2. using it with a concrete ring, here Float
> > > 3. change the behaviour of Float (outputFixed 2)
> > > 4. recompile the package
> > > 5. Side effect: the behaviour of Float is changed back again to original
> > > default, not only in calling NCFLOAT, but even for all Float's in the
> > > workspace
> > > I see no reasonable explanation or even justification for this behaviour.
> >
> > AFAICS:
> >
> > 1) outputFixed 2 sets variables belonging to Float
> > 2) variables belonging to a domain are treated like parameteres,
> > in particular are re-initialized when domain is re-initialized
> > 3) re-compiling a domain causes re-initialization of all domains
> >
>
>
>
>
> > Re-initialization of domain D is needed in case when D uses
> > re-compiled domain, in order to pick up changed function definitions.
> > Because we do not track dependencies between domains we force
> > re-initialization of all of them.
>
> I think this is not the description of the problem here: We have a domain F
> depending on a domain R (of category Ring). Now F is recompiled (which has
> NOTHING to do with one particular instance of a ring R). I agree that F has
> to be re-initialiazed. I see no reason that EVERY Ring which happens to be
> around (it is not even necessary for F to have Float called for R) is
> re-initialized,too. So why not do the following: ONLY re-initialize F and do
> not re-initialize all the other domains, in particular it seems not necessary
> to re-initialize parameters of R. Simply keep them. What could go wrong?
Consider:
D() ... ==
import F
-- use F
...
If we redefined some exported functions in F we expect D to use the
new definition. This requires re-initializing D. Similarly, we
have to re-initialize every domain using D (otherwise this domain
would use old version of D which in turn uses old version of F).
ATM we do not track dependencies so we re-initialize everything.
With proper dependency tracking we could limit number of domains
that need to be re-initialized but such tracking requires some
effort to implement and may be hard to understand for users.
>
>
> Here is a changed example, which should be supported by the present
> philosophy:
>
> )abb package NCFLOAT NotChangeFloat
>
> NotChangeFloat(R : Ring):
> public == private where
> PI ==> PositiveInteger
> NNI ==> NonNegativeInteger
> I ==> Integer
>
> public ==> with
> signValue: R -> R
> private ==> add
> import Float
> signValue(r: R): R ==
> outputFixed(2)
> -r
>
>
> After compilation, however, no changes to Float:
> (18) -> a : Float := 0.99999
>
> (18) 0.99999
> Type: Float
> (19) -> )co ncfloat
>
> (19) -> a
>
> (19) 0.99999
>
>
> O.K. we have not yet called signValue
>
> (20) -> signValue(-3)$NCFLOAT(Integer)
>
> (20) 3
> Type: Integer
> (21) -> a
>
> (21) 1.00
>
> Next refinement: put outputFixed directly in add-part. When does it became
> evaluated?
>
> NotChangeFloat(R : Ring):
> public == private where
> PI ==> PositiveInteger
> NNI ==> NonNegativeInteger
> I ==> Integer
>
> public ==> with
> signValue: R -> R
> private ==> add
> import Float
> outputFixed(2)
> signValue(r: R): R ==
> -r
>
> (22) -> )co ncfloat
>
> (22) -> a
>
> (22) 0.99999
> Type: Float
> (23) -> signValue(-3)$NCFLOAT(Integer)
>
> (23) 3
> Type: Integer
> (24) -> a
>
> (24) 1.00
>
> AHA: nothing happens (NO 'pick up of changed function definitions') by mere
> compilation. Only calling a function of the recompiled domain makes the
> changes valid. That proves to my opinion: There is no need to re-initialize
> all other domains, if ONE domain is recompiled. Just re-initialize this one.
>
Domains are initialized in lazy way. When I wrote "re-initialize" I
really mean that old information is thrown out and some minimal
new information is put in place -- the rest is computed when (if)
needed.
--
Waldek Hebisch
[email protected]
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
