Le 10/03/2020 à 00:40, Federico Miyara a écrit :
I'll keep thinking about it, but in the meantime, I noticed that when
displaying
a = A*inv(A)
we get the customary list of columns as the total width exceeds the
available horizontal space. However, we get one "column 1" header and
three
I'll keep thinking about it, but in the meantime, I noticed that when
displaying
a = A*inv(A)
we get the customary list of columns as the total width exceeds the
available horizontal space. However, we get one "column 1" header and
three "column 2" headers instead of "column 1", ...,
Samuel,
Thanks for your answer. Simply being the determinant small doesn't seem
a problem when using floating point. Probably the bigger problem is the
presence, somewhere, of very dissimile orders of magnitude.
One curious detail in my example is that the solution of the system when
tHi,
Just a little bit correction, the module currently I am working on is IPCV, not
SIVP.
I overlooked the scicv in comparison previously as I was "intoxicated" in
telling history of the modules related to IPCV.
In fact I was trying to work on scicv as well, as it is almost a
Hi,
sorry for this misleading finding, infact I've second message to turn it down.
**
ignore the previous finding, turn out to be it seems like just a display issue.
However, I think my initial thought of the precision might be the issue? some
number are too small
Hello Clément,
Thanks for your answer.
I think it clarifies the situation somehow.
I still don't get your point of not open-sourcing it and maintaining it "for
free".
I think it's the other way round: if you open-source it, it might happen that
some members of the community contribute to
About the feature set, I suggest you take a look at SIVP which is much more
complete and target a wider audience. The available functions are the
documented ones and we might add more if customers requested more.
Currently, this toolbox is used by some customers and we only mapped the
feature
Hello,
It seems that this value is below %eps==2.2e-16, so I though that once encoded
in double the difference between 2e-20 and 0 is too small to be properly taken
into account.
Am I missing something?
Antoine
Le Lundi, Mars 09, 2020 15:11 CET, Chin Luh Tan
a écrit:
initially I thought
sorry, ignore the previous finding, turn out to be it seems like just a display
issue.
However, I think my initial thought of the precision might be the issue? some
number are too small (first case) and giving error during computation?
thx
rgds,
CL
On Mon, 09 Mar 2020 22:11:43
initially I thought could it be possible the number is too small (or too large)
to be handled by double?
after trying scaling down the problem, I notice that in Scilab 6.0.2 onwards:
--> 2e-20*%i
ans =
0.
in Scilab 5.5.2
-->2e-20*%i
ans =
2.000D-20i
Could
Hello Clément,
Thanks for your answer.
It's still not clear to me whether I should use scicv or not.
First, many features are missing and it's not clear to me how I can implement
or discover them (hough transforms for example).
Is there a list of the opencv functions that you expose through
Maybe an inversion made in state-space could me more reliable ?
S.
Le 09/03/2020 à 13:36, sgoug...@free.fr a écrit :
Hello Federico,
cond() and rcond() do not accept rationals, but the determinant of A is very
close to 0:
--> det(A)
ans =
Hello Federico,
cond() and rcond() do not accept rationals, but the determinant of A is very
close to 0:
--> det(A)
ans =
3.573D-10
0.027s² +7.433D-10s³
This likely explains that the inversion is not
Hello Stéphane,
>> We have a focus on keeping the data in the OpenCV world and "accessing" them
>> from Scilab.
>
> IMHO this is very confusing for people migrating image processing applications
> from Matlab (this is my case). For example, accessing rgb images directly as
> (n,m,3)
Hello,
Le 09/03/2020 à 10:52, Clément David a écrit :
Hello Antoine,
- scicv: installs without any issue and as reported by Samuel (
https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/forge.scilab.org/index.php/p/scicv/issues/1944/
Hello Antoine,
> - scicv: installs without any issue and as reported by Samuel (
> http://forge.scilab.org/index.php/p/scicv/issues/1944/
> http://forge.scilab.org/index.php/p/scicv/issues/1946/ ), overwrites 'write'
> and
> 'read' which breaks many native functions in scilab together with other
Dear all,
I wonder if the inversion of a matrix of polynomials is working
properly. I have the following code from the direct resolution of a
two-section constant resistance electrical network::
// Data
R1 = 600; R2 = 600; R3 = 600; R4 = 600;
R5 = 10070; R6 = 2774; R7 = 36; R8 = 130; R9 =
Hello Chin Luh,
Thanks for this detailled answer.
For me, the biggest issue with IPCV is the difficulty of getting the install
right and to ensure it will work on a given platform.
(anecdote time: I just received an email from a colleague asking for help to
install IPCV on his computer because
18 matches
Mail list logo
