Timeline for Repeated string pattern: difference between the FrontEnd and WolframScript?
Current License: CC BY-SA 4.0
11 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Mar 29, 2020 at 8:20 | vote | accept | Roman | ||
| Mar 27, 2020 at 19:22 | comment | added | Robert Jacobson | @ItaiSeggev Could we move to a better venue for technical conversation? I'd also like to ask you more about the times issue. Let me suggest either or both of Wolfram Language Slack workspace: wolfr.am/LmVzbTQt GitHub issues: wolfr.am/LmVCyFV5 | |
| Mar 26, 2020 at 23:02 | comment | added | Itai Seggev | About Unicode minus. So there are the raw number forms where you have to use ASCII minus. Are there others? I have to say that my gut reaction this would be a lot of effort for not very much gain. Indeed possibly a loss--you'll have gone from a situation where \[Minus] is always subtraction (whether unary or binary) to one where it might inadvertently be soaked up by a number to its left. If you know of other situations or can describe why you care, that might affect our assessment. | |
| Mar 26, 2020 at 22:50 | comment | added | Itai Seggev | @RobertJacobson No, I was referring to your claim that "any expression for which the FE and command line give different FullForm expressions also have different hashes in each." Once you have an expression, it's FullForm is unambgious and so its is hash. I agree there are inputs that produce different expressions between the FE. But the FullForm is not a property of the input (which may be given in any of several ways), it is a property of the expression. BTW for "Expression" the issues are primarily things like word size or byte order that might affect the arithmetic--less relevant today. | |
| Mar 25, 2020 at 20:10 | comment | added | Robert Jacobson | @ItaiSeggev Since you are the unary minus expert, can I suggest that the Unicode minus symbol should be able to be used in any place the ASCII symbol can? | |
| Mar 25, 2020 at 20:08 | comment | added | Robert Jacobson | "Most signifcantly, FullForm doesn't depend on the environment..." I assume you are referring to differences between systems. I haven't witnessed it—I am just quoting the docs which might be incorrect. Thanks for the correction re: the Times issue. I will need to correct the page. Let me know of any other errors. You're the first person from Wolfram to express any interest in this, as most of it has been known to be broken for years. If you would like more, I can look through my notes. (That website was motivated by differences in operator precedence between notebook and command line.) | |
| Mar 25, 2020 at 15:04 | comment | added | Daniel Lichtblau | @RobertJackson I will note that Itai spent significant time testing and debugging the pending changes to the kernel times/unary minus parsing. | |
| Mar 25, 2020 at 7:12 | comment | added | Itai Seggev | I see several errors on that page. Most signifcantly, FullForm doesn't depend on the environment--parsing of an input might be context-dependent, but once you have an expression its FullForm is unambiguous. However, you also point out real issues (many of which are known). For example the Times issue you point out is not, in fact, always, semantically insignificant (for finite precision arithmetic). We actually have a fix for that in our internal prototype build and I'm optimistic it will make into our next major release. I am happy to discuss further in some suitable venue. | |
| Mar 25, 2020 at 4:14 | comment | added | Robert Jacobson | Today I collected a few of them here: wltools.github.io/LanguageSpec/Resources/KernelVsFE. I have not included difference in operator precedence on that page. | |
| Mar 24, 2020 at 22:26 | comment | added | Robert Jacobson | "P.S. We do take these differences seriously, especially when easily typable input parses differently in the two contexts." I have many, many examples. See my links above if you are interested. | |
| Mar 24, 2020 at 20:02 | history | answered | Itai Seggev | CC BY-SA 4.0 |