In Groovy 3.0 (Groovy Version: 3.0.0-rc-1 JVM: 11.0.2)
println 3**3**3
println 3.0**3.0**3.0
gives
19683
19683
In Python (Python 3.5.2) from the terminal, I get
>>> 3**3**3
7625597484987
>>> (3**3)**3
19683
The official site does not give any indication.
Is ** broken in Groovy as of now?
EDIT
Answers in stackoverflow, math.stackexchange make it clear that the the mathematical convention is that exponentiation is right associative.
Defect is defined as a condition in a software product which does not meet a software requirement (as stated in the requirement specifications) or end-user expectation (which may not be specified but is reasonable).
Since this reasonable expectation is violated in an undocumented manner, is not this considered a bug?
No, it's not broken
It just has left to right associativity as with all other operators
In python ** has right to left associativity, so that's not broken either
They just have different rules
Related
How did they do it? Can I also add my own new operators to Python 3? I searched on google but I did not find any information on this.
No, you can't add your own. The numpy team cooperated with the core Python team to add # to the core language, It's in the core Python docs (for example, in the operator precedence table), although core Python doesn't use it for anything in the standard CPython distribution. The core distribution nevertheless recognizes the operator symbol, and generates an appropriate BINARY_MATRIX_MULTIPLY opcode for it:
>>> import dis
>>> def f(a, b):
... return a # b
>>> dis.dis(f)
2 0 LOAD_FAST 0 (a)
2 LOAD_FAST 1 (b)
4 BINARY_MATRIX_MULTIPLY
6 RETURN_VALUE
Answering your second question,
Can I also add my own new operators to Python 3?
A similar question with some very interesting answers can be found here, Python: defining my own operators?
Recently in PyCon US 2022, Sebastiaan Zeeff delivered a talk showing how to implement a new operator. He warns that the implementation is purely educational though. However, it turns out you actually can implement a new operator yourself! Locally, of course :). You can find his talk here, and his code repository here. And if you think your operator could enhance Python Language, why not propose a PEP for it?
What I'm trying to do is basically ask sympy to tell me exactly what mathematical formula is behind some of its builtin functions, since I have been struggling quite a lot with naming conventions, and I'd like to check that I'm using the function I'm supposed to.
My case would be for example with the builtin Bessel functions jn: according to Wikipedia, j0(x)=sin(x)/x, and I'm inclined to agree having solved that simple-case differential equation by hand.
However, when I ask sympy if jn(0, x)-sin(x)/x==0 the query returns False.
Running simplify does nothing but take up time, and I wouldn't know what else to do since factor and expand at most move the x to be a common denominator and evalf gives back the function in terms of yet another builtin function.
Since higher-order functions tend to be a lot more complicated than this, it would be really useful to find out which builtins correspond to what I'm looking for.
I'll be grateful for any link to resources that might help.
Using python3.10.6, sympy 1.9, running on Kubuntu 22.04
You can use the built-in help() function to read the documentation associated to a given SymPy object, or you can explore the documentation.
By reading the documentation with help(jn), we can find the description and a few examples, one of which points out to what you'd like to achieve:
print(expand_func(jn(0, x)))
# out: sin(x)/x
Edit: looking back at your question, you used: jn(0, x)-sin(x)/x==0.
With SymPy there are two kinds of equality testing:
Structural equality, performed with the == operator: you are asking SymPy to compare the expression trees. Clearly, jn(0, x)-sin(x)/x is structurally different then 0, because at this stage jn(0, x) has not been "expanded".
Mathematical equality: generally speaking, two expressions are mathematically equivalent if expr1 - expr2 is equal to 0. So, with the above example we can write: expand_func(jn(0, x)) - sin(x)/x which will results to 0. Or, we can use the equals() method: expand_func(jn(0, x)).equals(sin(x) / x) which will return True. Please, read the documentation about equals to better understand its quirks.
The precedence of ** wrt unary - is the same as its behavior in both standard math notation and common programming languages such as Python, i.e.
-2**4 acts like -(2**4)
up to Groovy 2.4. Is it changing to the nonstandard
-2**4 acts like (-2)**4
in Groovy 2.5 onwards?
Notes:
I can't find any online discussion on this breaking change from a standard behavior to a non-standard one besides http://mail-archives.apache.org/mod_mbox/incubator-groovy-users/201506.mbox/%3C5572D4C8.8070605%40asert.com.au%3E on the Apache mailing list and https://issues.apache.org/jira/browse/GROOVY-7428 on the Apache issue tracker.
The groovy grammar https://github.com/groovy/groovy-core/blob/master/src/main/org/codehaus/groovy/antlr/groovy.g clearly makes a special case of math power operator (**) (without ++(prefix)/--(prefix)/+(unary)/-(unary)). The behavior of ** wrt the pre-incr/decr operators could very well be wrong but that's a separate discussion.
In the Alloy grammar spec on the Alloy Web site, I find myself confused by the use of square brackets.
In a production like the following, things seem clear.
specification ::= [module] open* paragraph*
I guess the square brackets indicate optionality and that the asterisks are Kleene closures, so that the rule just quoted means a specification consists of at most one module statement, zero or more open clauses, and zero or more paragraphs. This makes sense to me (though I am gradually coming to use Wirth's EBNF notation wherever possible, so my notes show this as [module] {open} {paragraph}).
In the following production, though, the brackets are confusing me.
cmdDecl ::= [name ":"] ["run"|"check"] [name|block] scope
It would surprise me a great deal if the keywords run and check were optional in commands, and ditto for the name of the predicate to be run, the name of the assertion to be checked, or the anonymous block to be run or checked. But that's what it looks as if this rule is saying.
So question 1: what do square brackets indicate in the grammar?
Question 2: is the use of square brackets where some readers might expect parentheses a typo? I.e. should this rule instead take the following form?
cmdDecl ::= [name ":"] ("run"|"check") (name|block) scope
Maybe I'm just not familiar enough with the variety of grammatical notations to be found in the wild; perhaps it would be helpful to indicate the tool, or point to a description of the notation.
Question 3: is this notation used by some parser generation tool? Which?
question 1: what do square brackets indicate in the grammar?
You rightly pointed out that the use of square brackets is inconsistent in the grammar you referred to. I think that grammar was copied from the first edition of the "Software Abstractions" book; I'm not sure if the second edition of the book contains the same grammar.
Question 2: is the use of square brackets where some readers might expect parentheses a typo?
Exactly right.
Question 3: is this notation used by some parser generation tool? Which?
It is not. The Alloy Analyzer uses a grammar written in Cup. The .lex and .cup files (Alloy.lex and Alloy.cup) are included in the Alloy distribution jar file (located in "edu/mit/csail/sdg/alloy4compiler/parser/").
Thanks, Michael. The production for cmdDecl was indeed wrong in the book, so I've posted an erratum. Aleks has also updated the grammar on the Alloy website, which had a couple of other errors.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 8 years ago.
Improve this question
I need to manipulate expressions like 1 + sqrt(3) and do basic arithmetic like addition, subtraction, and division. I'd like the result to be in some sort of canonical form so that it can be used as a key in a map. Turning 1 + sqrt(3) into a float is not feasible due to roundoff problems.
I used SymPy for this task in Python. Is there an equivalent native library for Haskell?
Please check out the numbers package. If all you need is to store exact numbers like "1 + √3", you may want to use Data.Number.CReal instead of symbolic arithmetics. It stores the expressions and can be computed to arbitrary number of digits when needed.
Prelude Data.Number.CReal> let cx = 1 + sqrt (3 :: CReal)
Prelude Data.Number.CReal> showCReal 400 cx
"2.7320508075688772935274463415058723669428052538103806280558069794519330169088000370811461867572485756756261414154067030299699450949989524788116555120943736485280932319023055820679748201010846749232650153123432669033228866506722546689218379712270471316603678615880190499865373798593894676503475065760507566183481296061009476021871903250831458295239598329977898245082887144638329173472241639845878553977"
There is also a Data.Number.Symbolic module in the package but the description says "It's mainly useful for debugging".
It seems you are looking for Computer Algebra System (CAS) in Haskell. Inspite of so many references to algebraic objects in the names of Haskell packages/modules, I've never heard of a general purpose and well-maintained CA system in Haskell (like SymPy or Sage in Python).
However in the list of Computer Algebra Systems on Wikipedia I've found a reference to
DoCon. The Algebraic Domain Constructor
It uses a non-standard license, but I dare say it is still Open Source (though with rename and attribution requirements). As of July 2010 docon-2.11 still builds with GHC 6.12.1 and runs demos/tests (I only had to insert a LANGUAGE FlexibleContexts pragma in one file of the demo).
DoCon is well documented (362 pages of the Manual). Its Manual is packed inside of the zip with sources, so I put it online separately for convenience:
DoCon 2.11 Manual.ps
Please look through to check if it suits your needs.
Check out the cyclotomic package, which implements exact arithmetic on the cyclotomic numbers. These include all algebraic numbers (hence in particular 1+sqrt(3)) and the key operations (like equality) are decidable.
They do not provide an Ord instance (for the same reason the complex numbers do not), but one can implement a non-semantic instance if all one needs is to use them as keys in a lookup table. You may want to contact the author about how to do this correctly, as there may be some invariants that are not obvious (e.g. one may need to be careful about zeros in the coeffs map).