[ Charset ISO-8859-1 unsupported, converting... ]
> Martin Baker wrote:
> > > Ability to write 3-D data to files is interesting. ?But as I wrote
> > > use of 'unparse' looks wrong -- I suspect that it can be replaced
> > > by something simpler. ?In other words I feel that 'Export3D'
> > > needs a cleanup before we include it.
> >
> > I can't understand why 'unparse' is needed but I have tried it without
> > and it does seem to be needed. Can any one help me work it out?
> >
>
> AFAICS instead of 'unparse(convert(v.1)@InputForm)' we should
> use 'message((v.1)::OutputForm)'. ATM in iterpreter I get
> wrong result trying 'message((1.2)::DoubleFloat::OutputForm)'
> I do not know if this is interpteter weirdness or bug
> in 'message', but if 'message' is buggy we should fix it
> intead of woring around and using 'unparse'.
>
Little correction: it seems that ATM there is no direct way
to produce string representation of a DoubleFloat. So
I think that for release we should stick to the 'convert' +
'unparse' trick. But I would itroduce a new function:
toString(x : DoubleFloat) : String ==
unparse(convert(x)@InputForm)
and use it instead of inline code. Later we will add 'toString'
function to DoubleFloat (and maybe to other domains).
Remark: According to Axiom philosophy this function should be
called 'coerce' and DoubleFloat should have CoercibleTo(String).
But I do not want to try what crazy things interpreter will
do with such coercion...
--
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.
