{"action":"created","issue":{"url":"https://api.github.com/repos/tbeu/Modelica/issues/365","repository_url":"https://api.github.com/repos/tbeu/Modelica","labels_url":"https://api.github.com/repos/tbeu/Modelica/issues/365/labels{/name}","comments_url":"https://api.github.com/repos/tbeu/Modelica/issues/365/comments","events_url":"https://api.github.com/repos/tbeu/Modelica/issues/365/events","html_url":"https://github.com/tbeu/Modelica/issues/365","id":196336373,"number":365,"title":"Is the handling of complex arrays too complex?","user":{"login":"modelica-trac-importer","id":22202507,"avatar_url":"https://avatars.githubusercontent.com/u/22202507?v=3","gravatar_id":"","url":"https://api.github.com/users/modelica-trac-importer","html_url":"https://github.com/modelica-trac-importer","followers_url":"https://api.github.com/users/modelica-trac-importer/followers","following_url":"https://api.github.com/users/modelica-trac-importer/following{/other_user}","gists_url":"https://api.github.com/users/modelica-trac-importer/gists{/gist_id}","starred_url":"https://api.github.com/users/modelica-trac-importer/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/modelica-trac-importer/subscriptions","organizations_url":"https://api.github.com/users/modelica-trac-importer/orgs","repos_url":"https://api.github.com/users/modelica-trac-importer/repos","events_url":"https://api.github.com/users/modelica-trac-importer/events{/privacy}","received_events_url":"https://api.github.com/users/modelica-trac-importer/received_events","type":"User","site_admin":false},"labels":[{"id":503147049,"url":"https://api.github.com/repos/tbeu/Modelica/labels/Complex*","name":"Complex*","color":"0000aa","default":false},{"id":503143285,"url":"https://api.github.com/repos/tbeu/Modelica/labels/enhancement","name":"enhancement","color":"84b6eb","default":true},{"id":503148306,"url":"https://api.github.com/repos/tbeu/Modelica/labels/P:%20high","name":"P: high","color":"ff6666","default":false}],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":4,"created_at":"2016-12-19T05:52:32Z","updated_at":"2016-12-19T05:53:41Z","closed_at":null,"body":"**Reported by christiankral on 28 Apr 2010 11:29 UTC**\nI was running into a problem when I wanted to perform a calculation where real and complex arrays are incorporated. Consider the following parameters:\n\n```\n  parameter Integer n=3;\n  parameter Real r1[n]={1,2,3};\n  parameter Real r2[n]={2,3,4};\n  parameter Complex c[n]={Complex(1,1),Complex(1,2),Complex(1,3)};\n```\n\nI can compute the element wise sum of the arrays `r1` and `r2` by:\n\n```\n  parameter Real sumr_1 = sum(r1.*r2);\n  parameter Real sumr_2 = r1*r2;\n```  \n\nHow could a similar operation be performed for `c` and `r1`? Here are two equally awkward looking solutions to the problem:\n\n```\n  parameter Complex sumc_1 = \n    Modelica.ComplexMath.'sum'({r1[j]*c[j] for j in 1:n}); // works\n  parameter Complex sumc_2 = Complex.'*'.scalarProduct\n    ({Complex(r1[k]) for k in 1:n},c);                     // works\n```\n\nWhat I would like to have is:\n\n```\n  parameter Complex sumc_3 = sum(r1.*c); // does not work\n  parameter COmplex sumc_4 = r1*c;       // does not work\n```\n\n\n# Conclusions\n\nThe working cases are\n * difficult to write, read and understand\n * a horror for a Modelica beginner: how can we explain to anybody that the achievements of the last ten years turn out to looks like this? \n\nThe not working case are\n * easy to write, read and understand\n * logical to a beginner, because the code looks the same in case of real expressions\n\nI wonder where the gap between the two cases comes from? I cannot believe that Modelica has to be so unclear and confused. \n\n# Proposal\n\nSimplify handling of complex arrays. Simplify Modelica. Make Complex a built in data type if necessary. \n\n\nMigrated-From: https://trac.modelica.org/Modelica/ticket/365"},"comment":{"url":"https://api.github.com/repos/tbeu/Modelica/issues/comments/267887560","html_url":"https://github.com/tbeu/Modelica/issues/365#issuecomment-267887560","issue_url":"https://api.github.com/repos/tbeu/Modelica/issues/365","id":267887560,"user":{"login":"modelica-trac-importer","id":22202507,"avatar_url":"https://avatars.githubusercontent.com/u/22202507?v=3","gravatar_id":"","url":"https://api.github.com/users/modelica-trac-importer","html_url":"https://github.com/modelica-trac-importer","followers_url":"https://api.github.com/users/modelica-trac-importer/followers","following_url":"https://api.github.com/users/modelica-trac-importer/following{/other_user}","gists_url":"https://api.github.com/users/modelica-trac-importer/gists{/gist_id}","starred_url":"https://api.github.com/users/modelica-trac-importer/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/modelica-trac-importer/subscriptions","organizations_url":"https://api.github.com/users/modelica-trac-importer/orgs","repos_url":"https://api.github.com/users/modelica-trac-importer/repos","events_url":"https://api.github.com/users/modelica-trac-importer/events{/privacy}","received_events_url":"https://api.github.com/users/modelica-trac-importer/received_events","type":"User","site_admin":false},"created_at":"2016-12-19T05:53:41Z","updated_at":"2016-12-19T05:53:41Z","body":"**Comment by PHarman on 2 Nov 2010 16:37 UTC**\nsumc_3 and sumc_4 work in our implementation. This however may conflict with 2 statements in the specification:\n\n  10.6.3 Array Element-wise Multiplication\n\n  Scalar multiplication s*a or a*s with numeric scalar s and numeric scalar, vector, matrix or array a is defined element-wise.\n\n  Element-wise multiplication a.*b of numeric scalars, vectors, matrices or arrays a and b requires a numeric type class for a and b and either size(a) = size(b) or scalar a or scalar b.\n\nSince it is stated that this requires a numeric type class this would suggest that values representing instances of operator-records cannot be treated in the same way.\n\n  14.4 Overloaded Binary Operations\n\n  ...\n\n  4.  If A or B is an array type, then the expression is conceptually evaluated according to the rules of section 10.6 with the following exceptions concerning Section 10.6.4:\n\n  (a) vector*vector should be left undefined [as the scalar product of Table 10-14 does not generalize to the expected linear and conjugate linear scalar product of complex numbers].\n\n  (b) vector*matrix should be left undefined [as the corresponding definition of Table 10-14 does not generalize to complex numbers in the expected way].\n\n  (c) If the inner dimension for matrix*vector or matrix*matrix is zero, this uses the overloaded 0 operator of the result type. If the operator 0 is not defined for that class it is an error.\n\nThe initial statement that it is evaluated according to 10.6 I suspect actually suggests an error in 10.6.3, and that operator-records can in fact be treated like numeric classes.\n(a) and (b) I find quite surprising. The point of operator-overloading is to generalise the addition of custom types, and yet we have a restriction on it's operation that is specific to one particular application, that of complex numbers. This actually prevents operations for other operator-record classes that would be perfectly valid.\n\nI agree with Christian on the syntax, and I think it is actually a small (backwards compatible) specification change to vastly improve it.\n"}}
{"actor":{"display_login":"modelica-trac-importer"}}