Martin Rubey wrote:
>
> Waldek Hebisch <[EMAIL PROTECTED]> writes:
>
> > Your message deserves longer answer, unfortunatly I am in hurry now.
> > In short, it is better to have more tests, so I find the following
> > acceptable. However, I prefer different organization of source files.
>
> OK, I'll wait until you are back. However, I'd like to add the tests in this
> or a better form really soon, and move on then. Also, I'm convinced enough of
> my proposal to give it a try, at least experimentally. It should not be
> difficult (although it will probably be some work) to reorganise tests the
> proposal turns out to be inadequate.
>
What I find problematic:
1) Split chunks: Spad contains no end markers, so to know that for
example function definition is complete one has to see _next_
function or end of file. With current Spad usage normally (except
for guessing package) also end of chunk means that give construct
is complete. Widespread use of split chunks would break this
useful property.
2) Category definitions should be relatively stable, while new
tests may be added at any time. If tests are kept together
with algebra adding tests can break build process (say due
to wrong noweb markers). In practice it means that before
commiting a test one has to do full rebuild. With separate
tests it is enough to just re-run tests. It also makes
hader to track changes to categories.
3) In practice we test domains and packages: while some functions
are implemented in categories we can test them only via domains.
Also, good test _should_ depend on implementation: we should test
for known/suspected weak spots of implementation, we should aim
for full coverage... Putting tests in categories moves
implemention information into wrong place.
Point 3) may suggest that test should go into domain/packages.
This has some merits, but with our current machinery we still
have problems 1) and to some degree 2).
So, I would put tests in input subdirectory, either in a sparate
file or in some existing file (AFAICS elemfun.input.pamphlet would be
the correct file).
Now for FriCAS I would like to ensure "forward progress". To
explain this: there are two dangers for the project. One is
that changes made by project members either go backwards or
cancel each other. The other is that real work is blocked
by discussions or excessive control. Concerning trigcat,
some parts of change looks undesirable (as explained above),
other are positive. If change is limited to trigcat, then
probably this is not worth long discussion -- just go on.
OTOH, if you plan more changes of this sort I would ask
you to reconsider.
--
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
-~----------~----~----~----~------~----~------~--~---
