>
> On Thursday 28 Oct 2010 18:21:43 Waldek Hebisch wrote:
> > Looks interesting. However ATM I am not able to run any example.
> > In the text you wrote about SPoint2, etc, but there is no such
> > domain...
>
> Waldek,
>
> I have corrected:
> scene.spad.pamphlet
>
Thanks for update. ATM I am having problems bootstrapping with
scene.spad.pamphlet included, once I resolve this I will commit.
Some remarks about code. You have a few parts like:
xform(tr:%,inpt:PT):PT ==
PT has SCartesian(2) => _
applyTransPt2(tr,inpt pretend SCartesian(2)) pretend PT
PT has SCartesian(3) => _
applyTransPt3(tr,inpt pretend SCartesian(3)) pretend PT
PT has SArgand => applyTransCx(tr,inpt pretend SArgand) pretend PT
PT has SConformal(2) => _
applyTransConf2(tr,inpt pretend SConformal(2)) pretend PT
error "invalid point type in transform"
spnt(0::DF,0::DF)$SCartesian(2) pretend PT
Prefered Spad style is have a single name (say applyTrans) and
let the dynamic dispatch choose the right version. If for some
reason this is not possible, then usually it is better to write
if PT has SCartesian(2) then
xform(tr:%,inpt:PT):PT == ...
else if ....
One thing is that in your version testing is done each time xform
is executed, while in the second version test is done only once
when the domain is created.
Also SCartesian(2) is a domain, so the test should be
PT is SCartesian(2)
Also, you wrote:
The most general form of transform would be represented by PT->PT where
PT is any implementation of SPointCategory. So ideally all transforms
should be defined in this way. The usual way to transform a vector is to
use a matrix like this:
transform(in:Vector,def:Matrix):Vector
So what I need is a way to curry it into something like this:
transform(def:Matrix):(Vector->Vector)
I don't know how to this? that is, how do I create an anonymous function
where a variable (in this case def:Matrix) is a constant in the function?
For this use +-> construct:
transform(def : Matrix) : (Vector->Vector) ==
(in : Vector) : Vector +-> transform(in, def)
> By the way, the pamphlet contains 3 domains to support XML:
> XmlAttribute.spad
> XmlElement.spad
> ExportXml.spad
> at some stage in the future I would like to upgrade these to make the
> output easier to read for human readers (indentation, putting
> attributes and elements on the same line only if they don't exceed
> maximum line length and so on). If I do this then it would also be
> useful for XML output formatters such as HTMLFormat (and MathMLFormat
> if Arthur Ralfs agrees).
>
> Therefore, should you choose to use this code it might be worth
> putting it to compile before HTMLFormat. Or, if you prefer, I could
> divide the XML code into a separate pamphlet file.
>
With current bootstrap machinery there should be no need to compile
XML part in some specific order. Yes, I would prefer to avoid duplication
between XML, HTML and MathML (to say the truth there is quite a lot
of duplication between output formatters), but having needed
functionality without duplication requies much more effort than
doing it current way (code with no duplication is easier to maintain
in the future, but harder to create).
--
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.
