On Tue, Oct 14, 2008 at 6:17 PM, Martin Rubey wrote: > > Bill Page writes: > >> In principle it is possible to combine both value and type information >> into a single InputForm value. For example, this is the output >> generated by a patch that I have proposed for FriCAS: >> >> (1) -> sqrt(2)::InputForm >> >> (1) (:: (** 2 (/ 1 2)) (AlgebraicNumber)) >> Type: InputForm >> >> Here the desired type of the value is given by the final conversion. The >> problem is that I am not convinced that this is really such a good idea. > > Why do you think it's not a good idea?
The reason I think it is not such a good idea is because it explicitly introduces the notion of type into InputForm values in an essential way. There are no explicit types at all in the following examples: (float 231808574432053350722 - 66 2) (algebraicNumber (** 2 (/ 1 2)) ) only function calls. In an external environment like Sage, we need only map these function calls to something native to Sage. If we pass explicit type names, then we will need to handle them is another way, making the process more complicated than it really needs to be. > To convert to Sage (in a spad package), one would have to do a dispatch > depending on the domain. With AlgebraicNumber, it would be SR(2^(1/2)). Currently there is no spad package that does explicit conversion to Sage. The conversion is done on the Sage side in 'axiom.py' interface. If the conversion is done in Spad, then I am not sure that it would necessarily involve InputForm at all. (I am not necessarily against this idea - I am just pointing out that it is not currently done this way.) > Very likely, we cannot determine below and above for > > QQbar.polynomial_root(poly, RIF(below, above)) > > this would only be possible with RECLOS. > The Rep used by AlgebraicNumber is actually 'Expression Integer'. This choice of Rep is a little unusual and is probably the reason that Waldek objected to my notion that we might define value constructors like 'algebraicNumber' based on the underlying Rep. On reflection, I must say that for the most part I agree with his criticism. I think that it is very desirable - when possible - to define a value constructor based on the actual mathematical theory rather than it's particular representation. Some representations are more "naturaul" than others. But even having defined a default way of constructing values for any domain, I think it would be quite normal to override this with something better, when and where possible. Regards, Bill Page. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
