Hello,

Here is one of my files (similar problems I frequently used and solved). Although I solved many of them already, this one is quite a puzzle for me.
Actually, I could not understand why and how there is an error in it - see the picture please.



here is the accompanied file

typeconversionerror.sm

Could someone check this out please. Am I doing anything wrong here?

Regards,
Radovan

Hello,

I suspect that some similar problems are with the following example, therefore I also put it here.

The problem might be my mistake - but I can not see it and this drives me crazy at the moment

I also made another file and remained puzzled again. This time, I did the calculation, then I tried to do the same using the function - but there was an error I could not figure out again where it comes from.
Please look at the picture:



To the left is the calculation and there is a result. To the right there is a function and the same calculation - but there is an error about non matching numbers of rows/columns. Can not say what went wrong because none of the trace() functions has executed and really can not figure out what was wrong with this function.

I made another one, and the problematic function again worked now ??? .



Here is the accompanied file:

functionnotworking.sm

Could someone try to reproduce this one as well, please .

Regards,
Radovan

Hi omorr,

I think that the use of "function of function" with virtual arguments it's very interesting


I don't know why, but the issue seems to be located in the first "if" statement and in "B" evaluation

With your "if" statement, a trace() check relative to the iter variable return this:



there are no steps incremention, both "if" and "else" statements are not evaluated, but while cycle 3 times o_o


if you put a fake statement (f.e. 3<1) the if/else evaluation work:




if you look the trace() output you can see that in the third loop there is a "before B" but not an "after B", so I think the 2nd issue is in that if/else statement

the type conversion error disappear:
- if you put a line() in B
or
- if you directly put a 6x1 vector both in "h" and "z", but not if you put the vector in "h" or in "z" only


watch this file, and enable/disable the broyden functions to see the differences: typeconversionerror_debug.zip


I hope I helped you in some way

regards,

w3b5urf3r

Thank you w3b5urf3r

You helped, indeed. Actually, your checking gave me the idea where to track the things. It seems there is some error inside SMath or something else I could not figure out.

Here is the the screenshot of the example which is working and there is no problem about it.


As one can see, the h-value (which is inside the if(),btw.) is calculated as a vector of numbers - as it should be expected.
On the other hand, when using the problematic example:



As one can see, the h-vector is a nested matrix???. I can not figure out why is this happening. On the other hand, if we do that outside the function everything is fine, h-vector is a vector of numbers as it should be. Therefor, if() got confused and everything else broke down.

Here is the file with both examples typeconversionerror-1.sm

Regards,
Radovan

ok, another little step...

seems that the issue it's the different evaluation of f1(x0) (directly, outside the Broyden function) and f(x0) (indirectly, inside the Broyden function)



I could not find a way to get out the correct result (eval/optimization/line...)

here is the file with different chunked Broyden functions, enable/disble functions to see each output typeconversionerror-1_debug.zip


regards,

w3b5urf3r

Thanks for answering

On the other hand, I begin to doubt in my common sense
Look at this please:


Believe or not, I can not see what I was doing wrong but this seems to me quite peculiar.
Am I right or not?

Here is the file howisthisposible

Regards,
Radovan

Hi,
I think that is that numeric/simbolic optimization issue.

I modified definition of f(X) and turn on numeric optimization, and now answer is coorect:



Regards,

Oscasr

Thank you Oscar,

I think that the point is why my original simple example gives different results. Have no answer on that. Just imagine a bit more complicated functions (like my two examples above with questionable errors - 1.type conversion and 2.wrong vector/matrix dimensions). I am not sure but I suppose there is some bug in SMath. Have no idea at the moment what is going wrong. Just suspect that this simple example has some connection with them.

Regards,
Radovan

bug found and reproduced! (I think)

see this file, and enable or disable evaluations of f1() to see three different behaviors (optimization indipendent) 0.94_arrays%20bug.sm.zip

all differences are in A definition (assigned multiplier / variable multiplier / variable multiplier with operations)




regards,

w3b5urf3r

Wrote

bug found and reproduced! (I think)

see this file, and enable or disable evalutations of f1() to see three different behaviors (optimization indipendent)

I think that the bug is in "line" definition of function.

Look into this file, where I define f(x) without "line": 0.9_line_bug.sm

All answers are ok.

Oscar

Wrote

Wrote

bug found and reproduced! (I think)

see this file, and enable or disable evaluations of f1() to see three different behaviors (optimization indipendent)

I think that the bug is in "line" definition of function.

Look into this file, where I define f(x) without "line": 0.9_line_bug.sm

All answers are ok.

Oscar

Hi oscar,

you're right, the bug involve matrix products defined inside lines(), when the products are stored inside local variables



I think now Andrey has enough elements to try to solve this issue


best regards,

w3b5urf3r

Thank you! It's a great help for me.
Will fix this issue as soon as possible.

Regards.

I've made a fix. Could someone test it before the next release (hope to share new version tomorrow)?
Put the file from this package to SMath Studio installation directory to test the results.

Regards.

---

SyLib.7z (25 KiB) downloaded 50 time(s).

Wrote

I've made a fix. Could someone test it before the next release (hope to share new version tomorrow)?
Put the file from this package to SMath Studio installation directory to test the results.

Regards.

hi,

it seems to work properly


regards,

w3b5urf3r

Thank you Andrey for considering these issues ,

Here is my testing of the files I've posted.

The first one is about type conversion #1
It seems it is working now. Here is the picture:

here is the file typeconversionerror-1.sm

The second one #2 gave me some headache. It gives me constantly the non matching dimension error. Finally, I just find out what causes the problem which I could not understand. The problem was in stack() as presented in this picture:

here is the file xxstacknotworking.sm

I really can not understand why is that. If we just use stack() as a last command it will work but if we use XX:=stack() after that, this will not work ???

The third one is about transpose #6. It is still the same situation for me here - still wrong. Here is the picture:

Here is the file howisthisposible-1.sm

Regards,
Radovan

Wrote

The second one #2 gave me some headache. It gives me constantly the non matching dimension error. Finally, I just find out what causes the problem which I could not understand. The problem was in stack() [...]
here is the file xxstacknotworking.sm

I confirm, same issue with augment()

Wrote

The third one is about transpose #6. It is still the same situation for me here - still wrong. [...]
Here is the file howisthisposible-1.sm

Confirmed, but I think can be considered as a separate (unsolved) bug ( Transpose functions bug)


regards,

w3b5urf3r

Hello,

Wrote

I confirm, same issue with augment() w3b5urf3r

I mentioned some issues regarding augment() and stack() but not sure if there is any connection with this problem. To be honest, It was just a pure coincidence that I tried this - although seems quite non logical.

Regards,
Radovan

Wrote

To be honest, It was just a pure coincidence that I tried this - although seems quite non logical.

I agree :d

Wrote

Hello Andrey,

I wonder if the augment() and stack() could be made to receive a scalar argument in the case of merging vectors and scalars. This is not working at the moment *Array dimensions do not match*:

[...] Andrey, could you make that augment() and stack() could have scalars as their arguments as well, in the cases of merging row or column matrices (vectors)?

Regards,
Radovan

seem right, stack() and augment() should be able to treat a scalar (or a string) as a 1x1 matrix, if other input variables are vectors, scalars or strings


regards,

w3b5urf3r

Issue with augment/stack is also fixed. See augment() and stack() for details.

Fixed.
Regards.

Hello,

Just to mention something regarding this issue. I think this has some connection with it.

In v0.94 you will have

[MATH=eng]f(a):a*mat(b1,b2,b3,3,1)[/MATH]

[MATH=eng]f(a)=mat(a*b1,a*b2,a*b3,3,1)[/MATH]

[MATH=eng]f(mat(a1,a2,a3,1,3))=mat(mat(a1*b1,a2*b1,a3*b1,1,3),mat(a1*b2,a2*b2,a3*b2,1,3),mat(a1*b3,a2*b3,a3*b3,1,3),3,1)[/MATH]

[MATH=eng]f(mat(a1,a2,a3,3,1))=mat(mat(a1,a2,a3,3,1)*b1,mat(a1,a2,a3,3,1)*b2,mat(a1,a2,a3,3,1)*b3,3,1)[/MATH] or
[MATH=eng]f(mat(a1,a2,a3,3,1))=mat(mat(a1*b1,a2*b1,a3*b1,3,1),mat(a1*b2,a2*b2,a3*b2,3,1),mat(a1*b3,a2*b3,a3*b3,3,1),3,1)[/MATH]

[MATH=eng]f(mat(u1,v1,z1,u2,v2,z2,u3,v3,z3,3,3))=mat(mat(u1*b1,v1*b1,z1*b1,u2*b1,v2*b1,z2*b1,u3*b1,v3*b1,z3*b1,3,3),mat(u1*b2,v1*b2,z1*b2,u2*b2,v2*b2,z2*b2,u3*b2,v3*b2,z3*b2,3,3),mat(u1*b3,v1*b3,z1*b3,u2*b3,v2*b3,z2*b3,u3*b3,v3*b3,z3*b3,3,3),3,1)[/MATH]

In v0.95 you will have

[MATH=eng]f(a):a*mat(b1,b2,b3,3,1)[/MATH]

[MATH=eng]f(a)=a*mat(b1,b2,b3,3,1)[/MATH]

[MATH=eng]f(mat(a1,a2,a3,1,3))=mat(a1*b1+a2*b2+a3*b3,1,1)[/MATH]

[MATH=eng]f(mat(a1,a2,a3,3,1))=a1*b1+a2*b2+a3*b3[/MATH]

[MATH=eng]f(mat(u1,v1,z1,u2,v2,z2,u3,v3,z3,3,3))=mat(u1*b1+v1*b2+z1*b3,u2*b1+v2*b2+z2*b3,u3*b1+v3*b2+z3*b3,3,1)[/MATH]

I think that the situation with v0.95 is much acceptable now than before. On the other hand, I think that we have to be careful now because we can not take for granted that the result of these operation are symbolic vectors, matrices - as we would expect.

Regards,
Radovan