On Tuesday, March 27, 2018 at 2:57:12 PM UTC-5, Michael Orlitzky wrote:The thread was about casual users, who shouldn't have to care about the implementation details behind what "0.5" means. To a casual user, 0.5 is one-half. I didn't bring this up to fight about by pet bug again, but because of the similarity between this and the fact that 12/4 is not three. Casual users don't want to hear about the coercion framework, categories, maps and what-not -- they just want to be able to put in trivial homework problems and get out the right answers.
I definitely agree with Michael, and would go further and say that this doesn't just affect students who want to solve their homework problems, but also people who teach physics and even likely many people with an extensive knowledge of mathematics. I have used Mathematica Far more in my physics classes than I have in my mathematics classes, and my physics professors would definitely expect the rank of these two matrices to be the same, if they are indeed equivalent. Actually, so would all of my mathematics professors, I am fairly sure. In my opinion, the purpose of an ideal CAS is to do mathematics/computation, not get bogged down with the technical details. So even if, by the nature of floating point numbers, the ranks should be different, that is absolutely useless to most people. Most people are not interested in the intricacies of floating point numbers, the CAS should understand the users likely intention and leave these special case usages (such as having floating point numbers work non-associatively) as options (not the default). Why not assume by default that when someone enters a floating point number, they intend it as a member of QQ, at least in this case. Why not introducing a different function, is_prime_integer() say, keeping > is_prime() as it is now? > Of course, x.is_prime_integer(), or is_prime_integer(x), would return > ZZ(x).is_prime(). > Then, for the casual user, we should advertise (in examples, tutorials, > etc.) the use of is_prime_integer() over is_prime(). > Note that the casual user may discover is_prime_integer() by the standard > TAB mechanism, since its name starts by "is_prime". Facing the choice > between the two functions, he would probably (hopefully?) opt for > is_prime_integer(), which is self-explanatory. I am actually not a fan of this solution, though I definitely appreciate the intention. For me, the goal should be that the easiest to use function(in the sense that it is the one the casual user will likely type) is the one that behaves like the average user would want. So, in this case, it Should assume that 3/1 is referring to the integer 3, use is_prime on the integer, and then also give a warning stating that 3/1 was interpreted as the integer 3. Then, we should have a function like is_prime_in_ring, which functions the way is_prime functions right now, ie it takes into account what the parent was instead of making the common simplification. The warning I mentioned earlier could even tell the use that if they want a ring dependent result, then they should use is_prime_in_ring. Again, the vast majority of users are assuming 3/1 = 3, and paying attention to the parent is a case of special usage. -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
