[Scilab-users] Generating a boolean vector or matrix

[Stéphane Mottelet]

Le 13/09/2019 à 15:04, Samuel Gougeon a écrit :
> Le 04/09/2019 à 09:11, Federico Miyara a écrit :
>>
>> Dear all,
>>
>> I need to create a boolean vector, such as [%t, %t, %t, %t] but with 
>> a number of components given by a variable n. I couldn't find a 
>> function similar to ones(1,n).
>>
>> However I've found a workaround:
>>
>> a = ones(1,n) & %t
>>
>> It shouldn't work because ones(1,n) is not boolean, but it does.
>>
>> Questions:
>> 1) Why does it work?
>> 2) Is there some native function to create bolean matrices
>> 3) If not, are there any plans to introduce functions such as 
>> true(m,n) or false(m,n)?
>
>
> I hope no. These are typical -- IMO fake -- functions that i would not 
> expect in Scilab (and in any other language). There are many trivial 
> and fast ways to create a boolean array of given dimensions.
>
> To me, the only need is to document these trivial ways in the help 
> pages of %F and %T.
> Replacing a few lines of documentation with a lot of trivial 
> duplicated codes, separate pages, separate tests always look a very 
> bad idea to me.
>
> But i can understand that, for some habit reason, former octavers 
> would appreciate their usual functions.
> This is why i don't clearly understand why this sub-community does not 
> build /and maintain/ a "Matlabic" ATOMS package gathering this kind of 
> "aliases", or do not invest time to contribute to the m2sci converter 
> improvement.
>
> Even when repmat() will be fastened by a factor 7 through its upgrade 
> pending for 7 months now 
> <https://antispam.utc.fr/proxy/2/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/codereview.scilab.org/#/c/19782>, 
> it won't be the optimal way, noticeably due to its overhead.
>
> I am neither very convinced by the ones(m,n,.,"boolean") and 
> zeros(m,n,.. "boolean") proposal, for the same reason initially 
> exposed by Alain. But why not.
> In the same commit, Stéphane proposes to allow using the *"logical"* 
> keyword as an equivalent of the "boolean" one. On this side, i 
> definitively disagree with this. Indeed,
>
>  1. it would be useless, adding strictly no value to scilab
>  2. it would introduce a confusion for everyone, including for former
>     octavers, since in Octave an array of logical type is made of 0
>     and 1, not of %F and %T. While in Scilab we can also have arrays
>     of 0 and 1.
>
OK Samuel, I can forget this one. However, "double" should be kept as an 
equivalent of "constant", even if not the name of a scilab type returned 
by typeof(). We already have the macro "double()" (instead of 
"constant()") and the keyword "double" used everywhere in the API.
>
> 1.
>
>
> About trivial ways, a preliminary note -- and answer to Federico :
>
>> 2) How much memory does it take a boolean scalar? Does a boolean 
>> vector eploit the fact that a byte could theoretically host up to 8 
>> boolean components?
>
> 4 bytes / boolean. This big memory waste is reported since a while: 
> http://bugzilla.scilab.org/12789
>
I think it was stored as 4 bytes for historical reasons (in Visual 
Studio up to version 4.2 C++ int was 4 bytes)
>
> This means that, using an array of decimal numbers to create a boolean 
> array uses an intermediate memory "only" ~twice bigger than the final 
> result.
>
> About some trivial efficient ways:
>
>   * Array of %F :
>       o zeros(m,n,..)==1
>         as Christophe does, the way i use when, for 99,5% of cases, a
>         factor 2 in intermediate memory is not critical
>       o a(m,n,..) = %f;
>         or safer:
>         clear a, a(m,n,..) = %f;
>   * Array of %T :
>       o zeros(m,n,..)==0
>       o a(m,n,..) = %f; ~a
>   * Random boolean array :
>       o rand(m,n,..) < 0.5
>
> Personnaly, i don't need any option for getting all this. But 
> documenting it would be useful.
> In the same way, we can use
>
>   * clear c, c =(5,4,7) = %i*0 // to initiate an array of 0+0i
>     complex-encoded array
>   * clear p, p(5,4,7) = %z*0  // to initiate an array of 0z polynomials
>   * etc
>
> .. still without any specific functions or option.
>
> Best regards
> Samuel
>
>
> _______________________________________________
> users mailing list
> users at lists.scilab.org
> https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users

-- 
Stéphane Mottelet
Ingénieur de recherche
EA 4297 Transformations Intégrées de la Matière Renouvelable
Département Génie des Procédés Industriels
Sorbonne Universités - Université de Technologie de Compiègne
CS 60319, 60203 Compiègne cedex
Tel : +33(0)344234688
http://www.utc.fr/~mottelet

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.scilab.org/pipermail/users/attachments/20190913/fd1323ca/attachment.htm>