Am 26.11.2014 um 08:50 schrieb Ralf Hemmecke: > On 11/26/2014 06:48 AM, Bill Page wrote: >> On 25 November 2014 at 16:29, Kurt Pagani <nil...@gmail.com> wrote: >>> >>> )abbrev domain RR Real >>> ++ Description: The field of "real numbers" modelled as >>> ++ domain Expression(Integer) + some extensions. >> >> Kurt, could you describe what you are trying to do in a little more detail? >
Yes, with pleasure. I'm still thinking about how to deal with manifolds and differential forms in general and with algebraic ones (also varieties) in the first place. In order to compute 'charts' for example one needs some machinery which is not yet (fully) available. Inspired by http://perso.univ-rennes1.fr/marie-francoise.roy/bpr-ed2-posted2.html I've done some experiments (see SandBox: RealSpace,Prop,Geom1) manifesting the lack of some basic 'sound' concepts as we all know them from Analysis 1+2. It might be of course a matter of nomenclature or even philosophy,however, my understanding of 'Real' (:=\mathbb(R) in the sequel) as a 'Type' is like we do it in calculus: x:Real is a 'real variable' and f:Real -> Real is a real-valued function defined on the real line. But any number (constant) which is real-valued is also an element of R, thus should have type Real (at least as a super-type). A declaration f:R->R, for instance, would then exclude f=sqrt. Indeed, EXPR(INT) mimicks a great deal of this view of 'Real' as EXPR(CMPLX INT) does for 'Complex=\mathbb(C)', however, as Waldek remarked, it's lacking 'soundness'. For example, one has to exclude the possibility to have (or coerce) sqrt(-1) in 'Real'. On the other hand %pi,%e are certainly in R whereas %i is not. Moreover, it would be nice to have the usual 'ordering' incorporated in such a type in order to deal with inequalities and a first order language of fields. My original goal to define \mathbb(R^n), real n-space (n=1,2,3,...) based on EXPR(INT) must fail of course for the same reasons. Some might say it's pedantic or superfluous rigor to isolate these two fundamental 'fields', why not using Expression(X), Vector(Y)? Well, my answer would be "Aldor/SPAD can do better", (and honestly, I'm addicted to 'types ;). > I've changed the subject. > > I don't know whether someone really need this and whether "Real" is the > best name possible, but after a first "This is not real", I think Kurt > has an interesting idea. > > Maybe, it's not new, but who would say that 2*\pi is real? Right. All we > do in mathematics is to assume we knew \pi and that any time we need it > we can at least compute the first few digits of it up to any accuracy. > We certainly also know some properties of it like sin(\pi)=0 without > computing any digit of \pi. In other words, we compute symbolically with > a certain number of real numbers. And if you count the real numbers that > have ever been used by mankind, it's even finite. > > Although (as always) I don't like Expression(Integer) the idea to > introduce symbolic expressions to mean real numbers, sounds attractive > to me. > > However, Expression(Integer) would not be my first choice to implement > such numbers, let's call them for the moment "SybolicReal". The reason > is that for such numbers, I'd like to be able to coerce them to Float, > or rather I'd like to have to each number attached an algorithm that > enables me to get any digit of that number, i.e, the name should rather > be SymbolicAlgorithmicReal. > > So a SymbolicReal is either a rational number or a symbol + an algorithm > to coerce it to Float (of any precision). > In addition to such an algorithm, I'd also attach properties to such a > number, like sin(\pi)=0. Where to handle such properties, is another > question. Yes, sin(x) has to be 'real' whenever x \in \mathbb(R), i.e. x:Real. On the other hand exp(%i*x) only 'can' be 'real', for some x, so we must have exp:R->R, or exp:C->C but no mix. Certainly, once given a sound R one could build C as R^2,... even R^n as direct (cartesian) product. > > Expression(Integer) is probably handling already quite some of these > properties, but I guess, it would be hard for users to introduce other > (named) SymolicReals and their properties. I can't deny that at the moment, we'll see. > > Kurt, if you want to go in such a direction, that would make for a nice > experiment. I've no clue how far one can go, because some functions like > sqrt would suddenly become partial. And whether sqrt(-1)^2 should > simplify to -1 or rather lead to an error, are the first problems to solve. > Once we have R it's not far to R_{+}, so sqrt can only be defined for non-negative reals. > I'd certainly want that sqrt(\pi^2) simplifies to \pi, but what if I > have a SymbolicReal s and try sqrt(s^2)? Depending on whether s can be > turned in to a positive or negative Float, the result is s or -s. Here we should use standard conventions (though I'm not sure, but I believe in real analysis it is) sqrt(s^2)=abs(s) which is well defined when using R -> R+ -> R+, s|->s^2->sqrt(s^2), abs:R->R+. This could be resolved either by subtypes or a first order (field) language. See the REDLOG example (http://www.redlog.eu/quick-start/) showing how it might go (of course one would be in need of some inference mechanisms). > > Just a few thoughts... Interesting ones, thank you both. Kurt > > Ralf > -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to fricas-devel+unsubscr...@googlegroups.com. To post to this group, send email to fricas-devel@googlegroups.com. Visit this group at http://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
