On Tue, Jul 14, 2020 at 12:12 AM Rocky Bernstein
<rocky.bernst...@gmail.com> wrote:
>
> I think we've beat this to death. So let's agree to disagree.
>
> This kind of thing is not intended for someone like you, but rather, someone 
> like me who is just getting started in Sage and CAS and wants to go through a 
> number of simple Mma tutorials and see roughly corresponding results 
> translated to another system. If that works out, I am happy, and may try more 
> ambitious things.
>
> The specific examples showing how the various systems are hopelessly 
> incompatible or where there are subtleties and vagueness are interesting. 
> However I suspect none of this is going to matter. At least not in the short 
> term, if ever. This is for casual, non-mission-critical, and educational use. 
>  After I have something that isn't vaporware (if I get to that stage), you 
> can pop up again and warn people of the dangers. I hear you, and you have 
> some valid points. Now please go away.
>
> There were the hacks one used to do with calculators where you'd divide a 
> number of times by a number and then multiply it back and get something 
> slightly off. Using that, Homer Simpson was able to disprove Fermat's Theorem 
> by finding a solution to the equation  a**12 + b**12 = c**12 in TI calculator 
> math. Somehow though, calculators and mathematics were both able to survive 
> this ordeal.

I think this is a laudable goal, and while RJF's admonitions are
valid, I don't think it should discourage you from trying to get
something working.  I think even if you can get some simple cases
working it would be very impressive and useful.

As a technical note I don't think it would be worth trying to
implement this directly in the sage preparser, at least not yet.  That
would be a can of worms.  Just stick to a stand-alone transpiler
program that can parse Mathematica code and spit out some roughly
equivalent Python/Sage code.  This would make the transpilation result
more transparent, and give you (or anyone else using it) opportunity
to review the transpiled code and modify it.  Burying it in the sage
preparser would get too hairy and distract from the primary mission,
and would also make it more obscured.



> On Mon, Jul 13, 2020 at 4:25 PM rjf <fate...@gmail.com> wrote:
>>
>> the problem I see here is the recipe
>>
>> requiring "user choice"  and somehow specifying "inf in Mma"
>>
>> Most users will not want to specify, but probably would go along with
>> "the mathematically consistent choice according to experts who have
>> studied the matter."
>>
>> Certainly saying, as one choice, "inf in Mma" is inadequate since
>> the user, other people, other CAS, cannot make use of this with
>> any certainty.  Even "inf in Mma version 12.1" while specific,
>> is not so useful outside of Mma version 12.1.  There is no
>> axiomatic specification for "inf in Mma". Also the code
>> supporting it is secret.
>>
>> Being approximately right in mathematics is different from
>> providing an answer which is right within some defined
>> level of approximation  (e.g.  numerical precision,  number
>> of terms in a series, approximation by polynomial, ...)
>>
>> If you consider a robotic automated vehicle, being
>> approximately right might means it will only rarely crash
>> into a tree.  Being right approximately means that it
>> will (always) drive to its destination, give-or-take a short displacement.
>>
>> RJF
>>
>>
>>
>>
>> On Friday, July 10, 2020 at 6:51:15 PM UTC-7, Rocky Bernstein wrote:
>>>
>>>
>>>
>>>
>>> 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.
>>>
>>>>
>>>>
>> I rarely use Google Translate.  I often use voice recognition (Alexa) which 
>> is remarkable but
>> prone to errors in recognition as well as information retrieval. Maybe you 
>> should build your
>> system for math voice parsing?  Alexa responds to
>> "Alexa, how much is 2+3?"
>> with "2+3 is 5".
>>
>> You can see some background on this here:
>> https://people.eecs.berkeley.edu/~fateman/papers/speakmath.pdf
>>
>> Maybe you should consider reviving "how to speak mathematics"
>> using newer technology.   (vs. 2003 or so.)
>>
>>
>>
>> --
>> 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/e0924dda-7720-4485-94e3-50d444f6d89co%40googlegroups.com.
>
> --
> 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/CANCp2gaZh2_WnzhVsvM%3DcmEJdg6wKF22ooH%2Ba%3Dx0HfABXzagJA%40mail.gmail.com.

-- 
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/CAOTD34YgEMj%2Bim%2BAE7AHekQ-R7rpP6-Cek2owAX8%2BJt_jcOceQ%40mail.gmail.com.

Reply via email to