On Tue, Aug 5, 2014 at 6:36 PM, rjf <fate...@gmail.com> wrote: > > > On Sunday, August 3, 2014 10:11:57 PM UTC-7, William wrote: >> >> >> >> On Sat, Aug 2, 2014 at 11:16 PM, rjf <fat...@gmail.com> wrote: >> > On Wednesday, July 30, 2014 10:23:03 PM UTC-7, William wrote: >> >> [1] http://maxima.sourceforge.net/docs/manual/en/maxima_29.html >> >> >> >> > Perhaps Axiom and Fricas have such odd Taylor series objects; they >> >> > don't >> >> > seem to be >> >> > something that comes up much, and I would expect they have some >> >> > uncomfortable >> >> > properties. >> >> >> >> They do come up frequently in algebraic geometry, number theory, >> >> representation theory, combinatorics, coding theory and many other >> >> areas of pure and applied mathematics. >> > >> > >> > You can say >> > whatever you want about some made-up computational problems >> > in "pure mathematics" but I think you are just bluffing regarding >> > applications. >> >> Let me get this straight -- you honestly thinking I'm bluffing regarding >> applications of: >> >> "power series in one variable over a finite field" > > Yes. > > I read your statement above to say, among other things, that > > {such odd power series objects} come up frequently in ... many area of ... > applied mathematics. > > > >> >> >> >> Are you seriously claiming that "power series over a finite field" have no >> applications? > > > I can imagine you could invent an "application", so I would not say these > objects > have "no applications". I can even invent one application for you. The > application is > "show a structure that can be created by a computer program that consists of > a power > series etc etc." This sort of smacks of the self referentiality that comes > from answering > the command: > > Use X in a sentence. > > by the response > "Use X in a sentence. >> >> >> >> >> >> > Note that even adding 5 mod 13 and the integer 10 is potentially >> >> > uncomfortable, >> >> >> >> sage: a = Mod(5,13); a >> >> 5 >> >> sage: parent(a) >> >> Ring of integers modulo 13 >> >> sage: type(a) >> >> <type 'sage.rings.finite_rings.integer_mod.IntegerMod_int'> >> >> sage: a + 10 >> >> 2 >> >> sage: parent(a+10) >> >> Ring of integers modulo 13 >> >> >> >> That was really comfortable. >> > >> > >> > Unfortunately, it (a) looks uncomfortable, and (b) got the answer >> > wrong. >> > >> > The sum of 5 mod13 and 10 is 15, not 2. >> > >> > The calculation (( 5 mod 13)+10) mod 13 is 2. >> > >> > Note that the use of mod in the line above, twice, means different >> > things. >> > One is a tag on the number 5 and the second is an operation akin to >> > remainder. >> >> The answer from Sage is correct, and your remarks to the contrary are just >> typical of rather shallow understanding of mathematics. > > > Are you familiar with TeX's \bmod ? > > It is possible to define anything that comes from Sage as correct. > Mathematica does that kind of thing often, declaring its reported bugs to be > features. Sometimes > I agree, sometimes not. > >> >> >> >> It's basically the same in Magma and >> >> GAP. In PARI it's equally comfortable. >> >> >> >> ? Mod(5,13)+10 >> >> %2 = Mod(2, 13) >> >> >> >> >> >> > and the rather common operation of Hensel lifting requires doing >> >> > arithmetic >> >> > in a combination >> >> > of fields (or rings) of different related sizes. >> > >> > >> > If you knew about Hensel lifting, I would think that you would comment >> > here, >> > and that >> > you also would know why 15 rather than 2 might be the useful answer. >> >> The answer output by Pari is neither 15 nor 2. It is "Mod(2, 13)". > > > Well, if you simply insist that arithmetic requires the conversion of 10 to > a number in Z_13, > then that answer is OK. > >> >> >> >> > coercing the integer 10 into something like 10 mod 13 or perhaps >> > -3 >> > mod 13 is >> > a choice, probably the wrong one. >> >> It is a completely canonical choice, and the only possible sensible one to >> make in this situation. > > Which one, -3 or 10? > They can't both be canonical.
Yes, they can "both" be canonical: they are equal (as elements of Z/13Z). There is the choice of internal representation, and what string to use when displaying them to the user, but that doesn't affect its canonicity as a mathematical object. >> That's why every single math software system with any real algebraic >> sophistication has made this (same) choice. > > > I think the issue comes up as to the definition of a system with "real > algebraic sophistication" and for that > matter, whether you are familiar with all of them. > > While you are probably aware that I am not a big fan of Mathematica, it is > quite popular. This is what it > has in its documentation. > > Modulus->n > is an option that can be given in certain algebraic functions to specify > that integers should be treated modulo n. > > It seems that Mathematica does not have built-in functionality to manipulate > objects such as Mod(2,13) . Nope. Or function fields. Or p-adics. Let alone more complicated objects like points on algebraic varieties. > In fact, your whole premise seems to be that mathematically sophisticated > <whatever> must be based on > some notion of strongly-typed hierarchical mathematical categories, an idea > that has proven unpopular > with users, even if it has seemed to system builders, repeatedly and > apparently incorrectly, as the golden fleece, > the universal solvent, etc. > > I think the historical record shows not only the marketing failure of Axiom, > but also mod Reduce, and some subsystem > written in Maple. Also the Newspeak system of a PhD student of mine, > previously mentioned. > Now you may think that (for example) Magma is just what you? the world? > needs (except only that it is not free). > That does not mean it should be used for scientific computing. I can just see you sitting there wondering why Sage hasn't died the tragic death your crystal ball said it would ages ago... >> > presumably one could promote your variable a to have a value in Z and do >> > the addition again. Whether comfortably or not. >> >> sage: a = Mod(5,13); a >> 5 >> sage: a + 10 >> 2 >> sage: b = a.lift(); parent(b) >> Integer Ring >> sage: b + 10 >> 15 > > > Thanks. Can the lifting be done to another computational structure, say > modulo 13^(2^n)? Sure. sage: b = Integers(13^1024)(a); b 5 sage: b^(4*13^1023) 1 >> >> There are many 1's. >> > >> > >> > that's a choice; it may make good sense if you are dealing with a raft >> > of >> > algebraic structures >> > with various identities. >> >> >> >> We are. >> >> > I'm not convinced it is a good choice if you are dealing with the bulk >> > of >> > applied analysis and >> > scientific computing applications amenable to symbolic manipulation. >> >> Sage is definitely not only dealing with the that. > > > Actually, I expect that Sage, as a front end to several systems, does not > adequately > "deal" with ideas like "1". Which might be used in any number of the > subsystems > for concepts like matrix identity under multiplication. Or a power series, > or a polynomial... > >> >> >> >> >> It's not what Sage does. Robert wrote the wrong thing (though his >> >> "see above" means he just got his words confused). >> >> In Sage, one converts the rational to the parent ring of the float, >> >> since that has lower precision. >> > >> > >> > It seems like your understanding of "precision" is more than a little >> > fuzzy. >> > You would not be alone in that, but writing programs for other people to >> > use sometimes means you need to know enough more to keep from >> > offering them holes to fall into. >> > >> > Also, as you know (machine) floats don't form a ring. >> > >> > Also, as you know some rationals cannot be converted to machine floats. >> > >> > ( or do you mean software floats with an unbounded exponent? >> > Since these are roughly the same as rationals with power-of-two >> > denominators >> > / multipliers). >> >> Yes, Sage uses http://www.mpfr.org/ > > While that solves the problem of overflow or underflow, it still does not > allow > the representation of 1/3 as a (binary radix) float of some finite > precision. > >> >> >> >> > What is the precision of the parent ring of a float?? Rings with >> > precision??? >> >> sage: R = parent(1.399390283048203480923490234092043820348); R >> Real Field with 133 bits of precision >> sage: R.precision() >> 133 >> > I'm confused here. Are you now saying R is a Field? Is a Real Field a kind > of > Field? Is there a multiplicative inverse in R for the object 3.0 ? Or is a > Real Field > like a "Dutch Oven" which is actually not an oven, but a pot? R is a (very well studied) approximation to a field. >> >> sage: 1.3 + 2/3 >> >> 1.96666666666667 >> > >> > >> > arguably, this is wrong. >> > >> > 1.3, if we presume this is a machine double-float in IEEE form, is >> > about >> > 1.300000000000000044408920985006261616945266723633.... >> > or EXACTLY >> > 5854679515581645 / 4503599627370496 >> > >> > note that the denominator is 2^52. >> > >> > adding 2/3 to that gives >> > >> > 26571237801485927 / 13510798882111488 >> > >> > EXACTLY. >> > >> > >> > which can be written >> > 1.9666666666666667110755876516729282836119333903... >> > >> > So you can either do "mathematical addition" by default or do >> > "addition yada yada". >> > >> >> In Sage both operands are first converted to a common structure in which >> the operation can be performed, and then the operation is performed. > > > Well, there are a large number of common structures. > One that gets the exact answer is to convert to arbitrary-precision > rationals. > One that does not always get the exact answer is some kind of floating-point > representation. It is more conservative to convert operands to the domain with less precision. We consider the rationals to have infinite precision, our real "fields" a specified have finite precision. This lower precision is represented in the output, similar to how significant figures are used in any other scientific endeavor. This is similar to 10 + (5 mod 13), where the right hand side has "less precision" (in particular there's a canonical map one way, many choices of lift the other. Also, when a user writes 1.3, they are more likely to mean 13/10 than 5854679515581645 / 4503599627370496, but by expressing it in decimal form they are asking for a floating point approximation. Note that real literals are handled specially to allow immediate conversion to a higher-precision parent. sage: QQ(1.3) 13/10 sage: (1.3).exact_rational() 5854679515581645/4503599627370496 sage: a = RealField(200)(1.3); a 1.3000000000000000000000000000000000000000000000000000000000 sage: a.exact_rational() 522254864384171839551137680010877845819715972979407671472947/401734511064747568885490523085290650630550748445698208825344 > It is of course possible to convert these object to (say) polynomials or > Taylor series.. >> >> >> >> >> >> > >> >> >> >> Systematically, throughout the system we coerce from higher precision >> >> (more info) naturally to lower precision. Another example is >> >> >> >> Z ---> Z/13Z >> >> >> >> If you add an exact integer ("high precision") to a number mod 13 >> >> ("less information"), you get a number mod 13 (as above). >> > >> > >> > This is a choice but it is hardly defensible. >> > Here is an extremely accurate number 0.5 >> > even though it can be represented in low precision, if I tell you it is >> > accurate to 100 decimal digits, that is independent of its >> > representation. >> > >> > If I write only 0.5, does that mean that 0.5+0.04 = 0.5? by your >> > rule of >> > precision, the answer can only have 2 digits, the precision of 0.5, and >> > so >> > correctly rounded, >> > the answer is 0.5. Tada. [Seriously, some people do something very >> > close >> > to this. >> > Wolfram's Mathematica, using software floats. One of the easy ways of >> > mocking it.] >> >> The string representation of a number in Sage is not the same thing as >> that number. > > > I think that is kind of taken for granted as the relationship between > input/output forms > and whatever is in the computer. Electrons. And even those are not the > abstraction > "number". > >> >> Here's an example of how to make the image of 1/2, but stored with very >> few bits of precision, then add 0.04 to it: >> >> sage: RealField(2)(0.5) + 0.04 >> 0.50 > > > Hm. Can one change the meaning of "+" so that returns 0.54? > What is the abstraction behind 0.04 ? RealField(n)(0.04) for some > integer n? Yep, RealField(53)(0.04), which is a bit arbitrary. > And is there a difference between 0.10 and > 0.1000000000000000000000000000000000 Yep. sage: a = 0.1000000000000000000000000000000000 sage: a.precision() 113 > (There is a difference in Mathematica. Mathematica claims to be the best > system for scientific computing. :) Few systems don't make that claim about themselves :). >> If one needs more precision tracking regarding exactly what happens when >> doing arithmetic (and using functions) with real or complex numbers, Sage >> also have efficient interval arithmetic, based on, e.g., >> http://gforge.inria.fr/projects/mpfi/. > > > I think that mpfi is probably a fine interval arithmetic package, but I > think it > is not doing precision tracking, really. It's doing reliable (if > pessimistic) > arithmetic. > >> >> >> >> > >> > I think that numbers mod 13 are perfectly precise, and have full >> > information. >> > >> > Now if you were representing integers modulo some huge modulus as >> > nearby floating-point numbers, I guess you would lose some information. >> > >> > There is an excellent survey on What Every Computer Scientist Should >> > Know >> > About Floating Point... >> > by David Goldberg. easily found via Google. >> > >> > I recommend it, often. >> >> Paul Zimmerman writes many useful things about what mathematicians should >> know about floating point -- http://www.loria.fr/~zimmerma/papers/. > > > I have enjoyed reading some of Zimmerman's papers, and he and his authors > have > said many interesting things. The Goldberg article tries to dispel commonly > held > myths about machine floating-point arithmetic. Myths often held by computer > programmers and of course mathematicians. Zimmerman has addressed many > fun problems in clever ways. > > Inventing fast methods is fun, although (my opinion) multiplying integers > of astronomical size is hardly > mainstream scientific computing. > > Not to say that someone might claim that > this problem occurs frequently in many computations in pure and applied > mathematics... I've personally "applied" multiplying astronomically sized before (thought the result itself is squarely in the domain of pure math): http://www.nsf.gov/news/news_summ.jsp?cntn_id=115646/ - Robert -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
