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?
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.
Hence: still looking for a convincing example for the necessity of the current
behaviour.
> 2) is for simplicity -- it would
> be awkward to try to preserve valuses of variables.
o.k.
> 1) is natural,
> since outputFixed should have lasting effect it must set some
> variables. It is natural to set variables belonging to Float
> (as opposed to using Lisp variables).
>
> I agree that this behaviour looks undesirable, but I am not
> sure how to specify a different behaviour that is consistent
> and possible to implement (I do not see how to avoid loosing
> some variables, and once we lost some consistency requires
> that we loose all).
--
Mit freundlichen Grüßen
Johannes Grabmeier
Prof. Dr. Johannes Grabmeier
Köckstr. 1, D-94469-Deggendorf
Tel.-pv. +49-(0)-991-2979-584, Tel.-mob. 0171-550-3789
Tel.-d +49-(0)-991-3615-141, Sekr. -154
Fax-p: +49-(0)-1803-5518-17745
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
