This has been an interesting discussion, because it brings up again the inherent tradeoffs present in writing general-purpose software. We (not just Sage, but other similar systems) want something that is usable by those who need floating-point to do what it must do, as well as be intelligible to those who write 1/3 = 0.333 and assume it is correct.
Although the discussion is not about teaching, it seems that the worst-case scenario of users are in that context. I think the compromise reached in Sage is acceptable for all teaching purposes I have ever had to encounter, for two reasons. 1) For many things, instructors need to provide an extra layer of sugar anyway. I have a nice activity I stole from someone else for showing the effect of various matrices on simple graphics, and for students just seeing matrices for the first time, I am not going to expect them to program the whole thing yet. In such cases, an instructor should understand at least the basics that can "go wrong" and shield users if necessary. The rank example falls into this category - as soon as we are doing actual matrix computations "for realsies", students MUST be led to understand that there is numerical error inherent. Michael said, "But if you're learning linear algebra for the first time and typing a matrix into the Sage notebook, typing 0.5 instead of 1/2 should not ruin the entire assignment without so much as a warning." Unfortunately, having taught this materials to complete beginners many time, I have to say that anything that goes beyond integer values to learn the terminology should be mentioning this issue in class, even in an Excel-based math for business course (for example). What level we go to in explaining why they should be careful will depend on their background, but explaining that Excel (or Sage, or whatever) has this limit is very important, even if we then say, "our examples will be selected to avoid this in our beginners' course, but be sure to work with your quantitative people/statisticians if you get weird answers." Maybe that means Nils' allusion is right and rank needs to be disabled (or yield error) on non-exact matrices? I'd be loathe to do that, I'd rather have to deal with the issue in class (and have done so, answering exactly these kinds of questions.). I have to talk about NOT using Excel to get determinants for this reason :-) 2) For other things, anyone using them should know the conventions. The RealField(120)(RR(13/10)) is an example of this - no one who doesn't know what RealField is doing should be put in a position to even worry about this. This particular example was discussed very fully above, but my point on it is that if someone encounters this before a numerical analysis course (in which case it is expected behavior), then someone is asking students to do a computation in a way that isn't appropriate for that course. (That doesn't mean students shouldn't see this kind of thing earlier - there are some very nice examples with things like limits [1] which are very appropriate to talk about in calculus, but we don't talk about floating-point precision in detail, just that we have to be careful "trusting" the computer instead of using analytical tools.) [1] https://sagecell.sagemath.org/?z=eJwrSyzSUM_MKygtUdfk5SpKLS7NKVGwVdBIzi_WAAtr6hpq6oNZcUa8XAU5-SUaEFU6EHkdXT0DMDDUgTE0NQGwjxmm&lang=sage&interacts=eJyLjgUAARUAuQ== I used to feel more like the OP about " A user should be able to send any argument to a function, and it's the responsibility of the programmer to make sure one of two things happen ..." but when I found out why PARI does not return an error message when you ask for the primitive root of a number that doesn't have a primitive root (namely, efficiency in avoiding the process of checking for bad input), I modified that to take into account who the intended end users are. Anyone using RealField(120) should be aware of these issues. It's possible that the conventions are wrong, but they are spelled out. -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/86a1734c-21cb-4ad2-9401-feaf09454f23n%40googlegroups.com.
