Bill Page wrote:
>
> On Fri, Oct 3, 2008 at 11:12 AM, Waldek Hebisch wrote:
> >
> > Bill Page wrote:
> >> 1) Use of coercions and types in InputForm.
> >> ...
> >> One alternative would be to introduce a specific (non-overloaded)
> >> operation exported by AlgebraicNumber such as 'algebraicNumber'
> >> that does the same thing. That is how Float values are currently
> >> handled:
> >>
> >> (8) -> 3.141592::InputForm
> >>
> >> (8) (float 231808574432053350722 - 66 2)
> >> Type: InputForm
> >> (9) -> unparse %
> >>
> >> (9) "float(231808574432053350722,-66,2)"
> >> Type: String
> >>
> >> Would doing something like this:
> >>
> >> (algebraicNumber (** 2 (/ 1 2)))
> >>
> >> be better?
> >>
> >
> > What is type of argument to this hypotethical function?
>
> algebraicNumber:Expression Integer -> AlgebraicNumber
>
You mean:
algebraicNumber(x: Expression Integer): AlgebraicNumber ==
x::AlgebraicNumber
>From FriCAS/Axiom point of view such a function is just useless
overhead.
Of course, such function is useful when interfacing to other systems,
but I am affraid this is not the way to go. Basically, it sounds
like "To speak with us you must be exactly like us" -- the whole
idea of inteface is that systems do not need intrusive changes.
> > AFAICS constructing floats works well because float can be
> > reconstructed from few integers.
>
> I am concerned that the definition and use of coercion to InputForm is
> not very clear in panAxiom. I believe the main purpose is to provide a
> convenient means in each domain to express domain values as easily
> evaluated expressions. It seems to me that there is always a general
> solution to this problem that is based on the representation Rep of
> the domain. For example, for any domain MyDomain
>
> if Rep has CoercibleTo(InputForm) then
> coerce(x:%) :InputForm ==
> convert(['myDomain,coerce(rep x)@InputForm])
> myDomain(x:Rep):% == per x
>
One of the main principle of Axiom is that Rep is not visible outside
-- you can change Rep at will and everthing will continue to work.
So the above may be useful when handling many specific domains
but definitely can not be taken as "general principle".
> To make this work in general we also need standard coercions to
> InputForm for built-in constructors like Record. For the most part
> these already exist. For example we need something like this: For any
> Record(a:A,b:B, ... ):
>
> if A has CoercibleTo(InputForm) and
> B has CoercibleTo(InputForm) ... then
> coerce(x:%):InputForm ==
> convert(['construct,convert([coerce(rep(x).a)@InputForm,
> coerce(rep(x).a)@InputForm, ... ]) ])
>
> In the case of Float the Rep is
>
> Rep := Record( mantissa:Interger, exponent:Integer )
>
> So for '3.141592::InputForm' we would get:
>
> (float (construct (231808574432053350722 -66)))
>
> or unparse
>
> float(construct(231808574432053350722, -66))
>
> This is essentially what is implemented for Float except that the
> 'construct' operator is absorbed into 'float' and the 3rd argument is
> gratuitous.
>
> > But for algebraic numbers we need much more complicated construction:
> > in general we need to specify tower of algebraic extensions.
>
> I don't think so. The same general construction can be applied as
> above. The Rep of AlgebraicNumber is Expression(Integer).
>
_Currently_ Rep of AlgebraicNumber is Expression(Integer). There
are good reasons to change this. In particular, once we have
AlgebraicNumber in hand we should be able to do reliable zero
testing.
--
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
-~----------~----~----~----~------~----~------~--~---
