> I try to answer all mails as good as I can, but I have very limited resources
> right now. I'll fix ACFraction and document DropEmpty as soon as I can.
Good. But you know that there is also some unfinished old code of yours
that appears to be not sufficiently documented. I'd prefer that you
write how you found a solution of some problem when you find one. State
the problem and the way you solve it immediately when you program. It
could be beautified later, but the information would be there.
>> <<exports of Fraction from LibAxiom>>=
>> canonical @ Category;
>> QuotientFieldCategory(S);
>> @
>
> vs.
>
>> So the exports should be
>>
>> Field;
>> FractionExtendCategory S;
>>
>> And "canonical @ Category" is wrong since it is a _conditional_ export.
>
> Forgetting the conditions for canonical was unintentional. The other one is
> since I was out of time and FractionExtendCategory sounds terribly like
> ListExtendCategory which did cost me a lot of time already once.
Yes, I know. Maybe this time we leave "Field and
FractionExtendCategory(S)" and put a prominent marker that there might
be a relation to a problem with ListExtendCategory so that it would be
easy to find a workaround when a problem occurs.
> (Please note that compiling AC takes roughly 5 minutes on my machine if I
> modify one of the basic files like axcompat or series...)
Are you working on a i286 computer? On my 1.6 Centrino 512MB laptop
"time make VARIANTSTOBUILD=debug distclean check" outputs
real 0m43.039s
user 0m36.520s
sys 0m2.936s
I hope you have not set the optimisation option from -q1 to something
higher because then Aldor takes a lot longer. The Aldor compiler is
known to produce bugs with certain optimisation constellations, so I
rather prefer to switch it off for development time.
>> You have several of these remarks (see below) in src/gseries.as.nw.
>> I don't know how you found this workaround.
>
> intuition and experience :-) -- or, rather, :-(
>
>> Maybe we should agree to mark references to compiler bugs in AC with the word
>> "CompilerBug" so that we can find them easily later.
>
> Very good idea. Maybe you could provide a sequential environment like ToDo for
> these things. I abused ToDo so far to document workarounds. And your deletion
> of one of these ToDo's in species.as.nw did cost me a lot of time, although I
> must say that it was correct.
Hmm, introducing
\defSequentialEnvironment{BUG}
would be simple, but I also would like to see who found the bug and who
could be contacted about more information about it, if the documentation
doesn't say it all. So perhaps we have then something like
\begin{BUG}
\begin{rhx}
13-Feb-2007: ....
\end{rhx}
\end{BUG}
In some sense BUG would be on the same level as ToDo. Otherwise another
(outer) ToDo environment would be good. But that sounds like more
overhead than reasonable.
Better suggestions?
>> What I don't understand is why you haven't put a test case into
>> test/gseries.as.nw which demostrates this behaviour. Or are you telling me
>> that this problem only appears in Axiom?
> Yes, it's only for Axiom.
>> Then why isn't there a #if Axiom ... #endif around this workaround?
> Because I was afraid that you hate #if Axiom ... #endif.
Yep, I hate it, but in this case it adds information.
>> But how come that you unconditionalise "differentiate"?
> But I didn't? At least not intentionally.
OK, then I'll fix that.
>> But the exports of FormalPowerSeries are FormalPowerSeriesCategory and there
>> "differentiate" now appears without condition. So if R has not an appropriate
>> * function then "differentiate" is not implemented for FormalPowerSeries(R)
>> and a that probably leads to a segfault.
>
> In my dvi it doesn't appear at all in the list of exports (page 122), but only
> on page 139 as conditional export of formalpowerseriescategory, as intended.
OK. You haven't unconditionalised it, but you haven't read how
conditional exports should be written in ALLPROSE, namely.
cd trunk/allprose
svn update
make laptop colored include-allprose-documentation dvi
xdvi doc/myalps.dvi
And look at ToDo 26 (Section 35 "tools/showexports2aldordoc.pl).
It says:
\begin{ToDo}
We cannot yet properly handle conditional exports in the exports
list.
At the moment a form like
\begin{verbatim}
@<<exports: TYPE>>=
if SomeDomain has SomeCategory then {
@<<exports: TYPE condition 1>>
}
@@
\begin{+++}
...
\end{+++}
@<<exports: TYPE condition 1>>=
func1: Signature1;
@@
\begin{+++}
...
\end{+++}
@<<exports: TYPE condition 1>>=
func2: Signature2;
@@
\end{verbatim}
works reasonably well, though.
\end{ToDo}
You have modified
<<exports: FormalPowerSeriesCategory differentiate>>=
differentiate: % -> %;
@
into
<<exports: FormalPowerSeriesCategory differentiate>>=
if R has with {*: (Integer, %) -> %} then differentiate: % -> %;
@
and thus ALLPROSE does not "see" differentiate anymore since the line
doesn't match a certain regular expression.
I've fixed that in revision 140.
> That looks like a bug in AllProse.
It's not really a bug, but a deficiency.
>> Could you please check via the mailing list whether I might have some reason
>> to conditionalise that function. You could even criticise me by telling me
>> that I never give a (good) reason for the condition.
>
> The reason is, I guess, as follows: you cannot compute n*f_n without
> *: (Integer, R) -> R.
>
> Oops. Maybe the condition is wrong...
>
>> But now we have a bug in AC.
>
> Do we?
No. I just missed that you have moved the condition.
Ralf
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier.
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Aldor-combinat-devel mailing list
Aldor-combinat-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/aldor-combinat-devel
