On Fri, Jul 10, 2020 at 8:41 PM rjf <fate...@gmail.com> wrote: > You of course realize that in expressing good intentions, you are not > alone, and certainly > not first. > The devil is in the details. Parsing Mathematica expressions into an > intermediate > form (like a Lisp symbolic expression) is the easy part. > > Here's a detail that came up in another mailing list. > What is Infinity or Inf in Mma? > Is it the same as in your favorite other CAS? Or in your > favorite text? >
User choice by option: If you want loose compatibility, then Inf in Mma. If you want strict compatibility there is a strict compatibility library and you can define SageInf in Mma. > Mma says 1/Inf = 0. It also says -1/Inf =0. From which > we might conclude that 1=-1. Do we have to get around > this? If so, how? If you have a system that has a > more nuanced version of infinity, what do you do? > > There are other similar issues. > > Another point -- that if two CAS come up with the "same" > answer, it must be right, is wishful thinking. In certain > simple domains I would treat equal results as strongly confirmatory. > There used to be a list of system-independent bugs -- > caused by common simplistic thinking, where > mathematics taught in high school is used as > the basis for manipulating more sophisticated > ideas. > > Sorry to provide a bit more rain on your parade. > I don't think you get the idea that flaky can sometimes be okay. I know this is going to sound a broken record, but you keep coming back to the same thing. Do you use google translate? If so, have you ever found its answers to be wrong? If you haven't used google translate, let me suggest that enough people use it that google still supports that project and it continues to fund and improve it. Spoiler alert: *it still makes a lot of mistakes*. If we insisted that rational numbers on computers be the correct rational as it is in mathematics, then floating point would have never been invented. Even more basic, if we had insisted that integers on computers be the same as integers in mathematics and not that silly modulo arithmetic, it would have taken computers a lot longer to get started. I am sure there are some or many that feel that this was the wrong thing to do. Personally, I, as apparently many others, *understand and accept *that the limitations and live with flakiness. When MMa fist came out, I recall at IBM there were a lot of people who were put off by it because it did a lot of computation by discrete approximation which was pervasively considered (at IBM) worse than the richness of Scratchpad2's more symbolic and more thorough handling. Looking back though, it is hard to argue that it should have come initially with something that was better and that improved the existing art on symbolic terms. And in the meantime, MMa has continued to improve to the point where it is used far more than those better systems like ScratchPad2. > Have fun with the easy parts and see how far you > can get with the hard parts! > Will do! In the short term, this is strictly for my own education and amusement and meager needs. I don't envision that anything I will do in the short term that will care about whether 1/Inf = 0. But when I do encounter it and it bothers me, I know about and have written compatibility libraries. (In fact I ran into something similar in Python. The details are here: Converting Python complex string output like (-0-0j) into an equivalent complex string <https://stackoverflow.com/questions/59384884/converting-python-complex-string-output-like-0-0j-into-an-equivalent-complex>. I solved it as I indicated here: I wrote my own routine <https://github.com/rocky/python-uncompyle6/blob/master/uncompyle6/util.py#L12-L14> that does what is needed. > RJF > I don't think you get the idea that flaky is sometimes okay if you declare it flakey. Sorry to rain on your parade. > > On Friday, July 10, 2020 at 11:30:51 AM UTC-7, Rocky Bernstein wrote: >> >> Ok. Something to consider is rendering to Mathematica output. (And then >> doing the same thing for Sage.) >> >> On Fri, Jul 10, 2020 at 1:37 PM Fredrik Johansson <fredrik....@gmail.com> >> wrote: >> >>> I will just mention http://fungrim.org/grim/ which is somewhat related >>> to the present discussion. >>> >>> This is an attempt to design a symbolic formula language that is easy to >>> parse and has well-defined semantics. Key points: >>> >>> * Can be used within Python (and other languages) without special syntax >>> * Expressly designed to describe mathematical objects and not for >>> reflection (manipulation of symbolic expressions is meant to be done in the >>> environment, e.g. Python, not from within the symbolic expression language) >>> * Expressions are inert by default (there is no automatically-enforced >>> pseudo-canonical form, and any form of evaluation or rewriting must be >>> invoked explicitly by the user) >>> * Evaluation and simplification is subject to a rigorous assumptions >>> system >>> * There is an explicit distinction between symbolic variables and >>> polynomial indeterminates >>> * Real numbers are mathematical real numbers >>> * Functions are mathematical functions, with well-defined and consistent >>> behavior at "exceptional points" >>> >>> The specification is still far from complete and the implementation >>> still has a long way to go, but I'm working on it :-) >>> >>> I'm using it with some success to build http://fungrim.org/. Thanks to >>> the strong semantics, it is possible to do automated randomized testing of >>> the formulas and their assumptions. To illustrate: >>> >>> >>> formula = Equal(Gamma(x+1), x*Gamma(x)) >>> >>> formula.test(variables=[x], assumptions=Element(x, CC)) >>> {x: -3} ... True >>> {x: 8} ... True >>> {x: 0} ... False >>> Traceback (most recent call last): >>> ... >>> ValueError >>> >>> (Gamma(0+1) = 0*Gamma(0) is not a true identity.) With correct >>> assumptions, excluding the poles: >>> >>> >>> formula.test(variables=[x], assumptions=Element(x, SetMinus(CC, >>> ZZLessEqual(0)))) >>> {x: Sqrt(2)} ... Unknown >>> {x: Mul(Mul(2, Pi), ConstI)} ... Unknown >>> {x: Div(Mul(3, Pi), 2)} ... Unknown >>> {x: Neg(Div(1, 2))} ... True >>> {x: Div(1, 2)} ... True >>> {x: Add(Sqrt(2), 1)} ... Unknown >>> {x: Add(1, ConstI)} ... Unknown >>> ... >>> {x: Sub(Pi, ConstI)} ... Unknown >>> {x: Sub(Sqrt(2), 1)} ... Unknown >>> {x: 64} ... True >>> {x: 255} ... Unknown >>> {x: 7} ... True >>> Passed 100 instances (25 True, 75 Unknown, 0 False) >>> {'True': 25, 'Unknown': 75, 'False': 0, 'Total': 100} >>> >>> Fredrik >>> >>> On Friday, July 10, 2020 at 5:21:07 PM UTC+2 rocky.b...@gmail.com wrote: >>> >>>> Ok. This is on my back-burner list of things to get to. >>>> >>>> It is something I would like to do, and think I could do reasonably >>>> well, but I never know if I'll have the free time. >>>> >>>> And if someone else wants to take the lead, I'll be happy to share what >>>> I know on the compiler/transpiler end and contribute. >>>> >>>> Also, if there is funding for this effort, then it will most likely get >>>> done. >>>> >>>> >>>> >>>> On Fri, Jul 10, 2020 at 10:52 AM kcrisman <kcri...@gmail.com> wrote: >>>> >>>>> >>>>> >>>>> >>>>> Clearly, adding the ability to parse some Mathematica code fits well >>>>>> into that goal. If nothing else, it could be a helpful step in >>>>>> converting >>>>>> existing Mathematica user code so that it can work in Sage, and >>>>>> that's part of being a viable alternative. >>>>>> >>>>> >>>>> This is an important point that I am sorry we did not mention earlier; >>>>> thanks, William. I have definitely had many requests for such an >>>>> automated >>>>> tool in the past from colleagues with a lot of Mma stuff. >>>>> >>>>> -- >>>>> >>>> You received this message because you are subscribed to a topic in the >>>>> Google Groups "sage-devel" group. >>>>> To unsubscribe from this topic, visit >>>>> https://groups.google.com/d/topic/sage-devel/z3XBhQOCh9E/unsubscribe. >>>>> >>>> To unsubscribe from this group and all its topics, send an email to >>>>> sage-devel+...@googlegroups.com. >>>>> To view this discussion on the web visit >>>>> https://groups.google.com/d/msgid/sage-devel/8dd1a617-6bcc-40e3-a1c7-89efb2927597o%40googlegroups.com >>>>> <https://groups.google.com/d/msgid/sage-devel/8dd1a617-6bcc-40e3-a1c7-89efb2927597o%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>> -- >>> You received this message because you are subscribed to a topic in the >>> Google Groups "sage-devel" group. >>> To unsubscribe from this topic, visit >>> https://groups.google.com/d/topic/sage-devel/z3XBhQOCh9E/unsubscribe. >>> To unsubscribe from this group and all its topics, send an email to >>> sage-...@googlegroups.com. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/sage-devel/050a44ed-e31b-4ddb-8687-fc9dcd53e3c1n%40googlegroups.com >>> <https://groups.google.com/d/msgid/sage-devel/050a44ed-e31b-4ddb-8687-fc9dcd53e3c1n%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- > You received this message because you are subscribed to a topic in the > Google Groups "sage-devel" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/sage-devel/z3XBhQOCh9E/unsubscribe. > To unsubscribe from this group and all its topics, 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/7ad837b4-fa7e-4d5c-a008-6d11e03df84bo%40googlegroups.com > <https://groups.google.com/d/msgid/sage-devel/7ad837b4-fa7e-4d5c-a008-6d11e03df84bo%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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/CANCp2gYAeyPaGicuC9wqEp68wkHS8DgQQirpZyTSm5J2MLeuRA%40mail.gmail.com.
