global variables in codegen

[Peter Brady]

So I'm trying to generate some fortran functions that have a uniform signature (x, y, z, t).  While this can be accomplished using the 'argument_sequence' option to 'codegen', my functions make use of module level (i.e. global) variables which I do not want to pass in as function parameters.  But codegen complains that I haven't specified all my variables:

In [1]: from sympy import *

In [2]: x, y, z, t, cp = symbols("x y z t cp")

In [3]: G = cp*sin(x)

In [4]: from sympy.utilities.codegen import codegen

In [14]: codegen(("G", G), "F95", header=False, argument_sequence=(x, y, z, t))

---------------------------------------------------------------------------

CodeGenArgumentListError                  Traceback (most recent call last)

<ipython-input-14-7008c98b03e3> in <module>()

----> 1 codegen(("G", G), "F95", header=False, argument_sequence=(x, y, z, t))

/home/ptb/gitrepos/sympy/sympy/utilities/codegen.py in codegen(name_expr, language, prefix, project, to_files, header, empty, argument_sequence)

   1436     routines = []

   1437     for name, expr in name_expr:

-> 1438         routines.append(code_gen.routine(name, expr, argument_sequence))

   1439 

   1440     # Write the code.

/home/ptb/gitrepos/sympy/sympy/utilities/codegen.py in routine(self, name, expr, argument_sequence)

    569             if missing:

    570                 raise CodeGenArgumentListError("Argument list didn't specify: "

--> 571                         ", ".join([str(m.name) for m in missing]), missing)

    572 

    573             # create redundant arguments to produce the requested sequence

CodeGenArgumentListError: ('cp', [<sympy.utilities.codegen.InputArgument object at 0x7faacdd9c278>])

Is there an option to bypass this check? (other than commenting out the check in the source)

[Jason Moore]

I don't think there is a bypass. You can supply more arguments than there are in the expression but it looks like you must supply all of the arguments in the expression. Seems like an option is warranted, or maybe that check isn't needed.

Jason
moorepants.info
+01 530-601-9791

--
You received this message because you are subscribed to the Google Groups "sympy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sympy+un...@googlegroups.com.
To post to this group, send email to sy...@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/ced27f44-7cd5-424c-99cc-d718ff8c4765%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jason Moore]

It also looks like the error doesn't print correctly.

Jason
moorepants.info
+01 530-601-9791

[Peter Brady]

As a hacky fix, I now specify the all the the local+module variables to codegen and then remove the extraneous arguments/statements from the returned string.  I would be in favor of removing the check since it seems like it's only necessary if the user specifies the arguments in which case I would assume that the user knew what they were doing.

[Jason Moore]

I think the reason the check is there is because if you build a typical function and don't supply all the function args for the given expressions(s) you may just get less-than-decipherable error messages during compilation and/or when you try to call the function. It is really just a check for the typical use case. I like it because I've been caught numerous times not supplying the correct args, maybe we just need the option to disable (or enable it) because the check is nice to have if you want it.

Jason
moorepants.info
+01 530-601-9791

To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/a6879fef-c9fe-4d37-92a8-51e38b36b107%40googlegroups.com.

[Peter Brady]

Along a similar line of reasoning, rather than disable the check, it may be better (safer?) to allow codegen to take a list of global variables that the function can use and then raise an error if the needed symbol is not found in either the local or global list

--
You received this message because you are subscribed to a topic in the Google Groups "sympy" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/sympy/i5C8Vk7RpBI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to sympy+un...@googlegroups.com.

To post to this group, send email to sy...@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.

To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAP7f1AivTH7Pyu%2Bk7WvyTMdoaJHvDD6%3D4jE%2BPAR2F4P%3DqEbDjw%40mail.gmail.com.

[Jason Moore]

That sounds reasonable. Feel free to open a PR and we can get something merged in.

Jason
moorepants.info
+01 530-601-9791

To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CALoNiQd5DxfDTOyNf4b8LxKe76aNrki5YbvrskPLgftPk0TQjQ%40mail.gmail.com.

[Ondřej Čertík]

Hi Peter,

On Mon, Jun 15, 2015 at 2:36 PM, Peter Brady <peter...@gmail.com> wrote:
> Along a similar line of reasoning, rather than disable the check, it may be
> better (safer?) to allow codegen to take a list of global variables that the
> function can use and then raise an error if the needed symbol is not found
> in either the local or global list

That sounds like the correct fix.

Ondrej