Hello,
Here I test a PELTON basic algorithm under xcos, and record with tic-toc the
simulation real time.
These programs have been set for 120 s (scope)
Results :
Xcos Scilab 5.5.2 :
Durée de la simulation : 45.4 s
Xcos Sciab 6.1.0 :
Durée de la simulation : 65.2 s
So the ratio
Style de liens...? (First select a line)
Similarly helpful, you can select the conjunct of a line and select
'optimal position'.
Regarding the ugly resized and displaced block, i have no idea...
On Fri, 28 Feb 2020, 08:27 Perrichon, wrote:
> Hello Samuel
>
> I dont’t find this option
>
> BR
>
Hello Samuel
I dontt find this option
BR
De : users De la part de Samuel Gougeon
Envoyé : jeudi 27 février 2020 20:09
À : users@lists.scilab.org
Objet : Re: [Scilab-users] Xcos Editor in Scilab 6.1.0 breaks diagrams
Le 27/02/2020 à 19:56, Perrichon a écrit :
Hello
I correctly
Hello,
Le 26/02/2020 à 04:14, Antisen A M a écrit :
Hi, is there a import function available to convert simulink model to
xcos model?
You may set you in CC: and put your +1 to http://bugzilla.scilab.org/5947
And have a look to
https://wiki.scilab.org/Ideas%20of%20development%20for%20Scilab#
Le 27/02/2020 à 17:44, Jan Åge Langeland a écrit :
A bit of a waste to use uint64 to store single bits, but that is what
bitget does:
--> typeof(bb1)
ans = "uint64"
This is not worse than returning always decimal numbers 0. and 1.
And better than returning booleans, for u-int8 and u-int16
Le 27/02/2020 à 19:56, Perrichon a écrit :
Hello
I correctly rewrite the MUX box dans the zcos.
Then I go out off Scilab, come in a new time and go to my folio.
Now I obtain :
What to do ?
Have you tried to use the /Format => Link style => Optimal/ feature?
_
Hello
I correctly rewrite the MUX box dans the zcos.
Then I go out off Scilab, come in a new time and go to my folio.
Now I obtain :
What to do ?
De : users De la part de Perrichon
Envoyé : jeudi 27 février 2020 19:35
À : 'Users mailing list for Scilab'
Objet : [Scilab-users] Xcos E
Hello,
Xcos Editor in Scilab 6.1.0 breaks diagrams. Number of failure is big.
Must I understand I've to rewrite all my projects in Scilab 6.1.0.
Here is an example (with several minus zooms)
The big box in simply a MUX in the standard Palette, normaly drawn at the
bottom of this diagra
With the current implementation, you will get the right result with the
following:
bitget([b b], uint64(1:64))(1,:)
* use a non scalar x (pad it with anything if scalar)
* use a non scalar pos (idem)
* use a pos with the same int64 or uint64 type than x
Samuel
Le 27/02/2020 à 16:17, JLan a
Thank you, Stéphane
So a workaround is:
b =uint64(2)^61+1
bb2=uint64(bin2dec(strsplit(strrev(bitstring(b');
bb1=bitget(b,1:64);
bb2(1)-bb1(1)
ans = 1
A bit of a waste to use uint64 to store single bits, but that is what
bitget does:
--> typeof(bb1)
ans = "uint64"
Jan
On 2020
OK, there is a trivial work-around for bitget().
I will post the URL of the fixed macro and how-to fix it for your own
6.1.0 as soon as put on the forge.
I will also add actual examples with integers in the page, and fix minor
typos.
Samuel
Le 27/02/2020 à 17:51, Samuel Gougeon a écrit :
A
Samuel
My suggestion for a workaround (looks like my first reply disappeared):
b =uint64(2)^61+1
bb2=uint64(bin2dec(strsplit(strrev(bitstring(b');
bb1=bitget(b,1:64);
bb2(1)-bb1(1)
ans = 1
A bit of a waste to use uint64 to store single bits, but that is what
bitget does:
--> type
As suspected, the bug originates from the * operator, that is still not
reliable between uint64 or int64:
--> b
b =
230584300921369395*5*
--> b * uint64(1)
ans =
230584300921369395*2*
This was reported in 2018 @ http://bugzilla.scilab.org/15836 and is
still unfixed.
For bitget, i wil
Le 27/02/2020 à 16:17, JLan a écrit :
I wonder if i have misunderstood the documentation for bitget, or if this is
a bug? It seems to me that numbers > 2^53 are still not handled correctly.
--> a=uint64(2^61)
a = 2305843009213693952
--> b=uint64(2^61)+1
b = 2305843009213693953
bitget(
But the problem with bitget remains. The new bitstring is ok:
--> bitstring(a)
ans =
"0010"
--> bitstring(a+1)
ans =
"0011"
S.
Le 27/02/2020 à 16:37, Stéphane Mottelet
You should generate big ints like this:
a=uint64(2)^61
S.
Le 27/02/2020 à 16:17, JLan a écrit :
I wonder if i have misunderstood the documentation for bitget, or if this is
a bug? It seems to me that numbers > 2^53 are still not handled correctly.
--> a=uint64(2^61)
a = 230584300921369395
I wonder if i have misunderstood the documentation for bitget, or if this is
a bug? It seems to me that numbers > 2^53 are still not handled correctly.
--> a=uint64(2^61)
a = 2305843009213693952
--> b=uint64(2^61)+1
b = 2305843009213693953
--> bitget(a,1:64)
ans =
column 1 to 32
Hello Pierre,
The former isoview() implementation mixed some poor isometrical tuning,
with some unrelated rebounding action.
This is why both types of actions have been split:
* isoview deals only with the isometrical view, in a richer way than
formerly: Please see history sections and com
hi all,
Is there an example of how to use the Automat block in xcos?
The xcos documentation refers to paper [1], which contains good
explanations *but no sci files*.
If you have an example sci files with block Automat, pls share. Thanks!
best wishes,
Ayrat
[1]: Implementation of Hybrid Automa
Hello,
I've seen that syntax change for the isoview in scilab 6.1.0 :
isoview(gcf(), "on")// Scilab 6.1.0
In that case I must take a new time bounds in Nyquist and positionning 0 dB,
3 dB and so on
In my GUI, I personnaly prefer this fonction in scilab 5.5.2, where
20 matches
Mail list logo
