[Scilab-users] Generating a boolean vector or matrix

[Federico Miyara]

Stéphane,

>> 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.
>>

true(m,n) may be fake if, as in other message has been clarified, 
boolean takes 4 bytes, but I think this is definitely not right, it is 
way too inefficient as regards memory usage.

By the same token, ones(m,n) wouldn't be strictly necessary either, 
since zeros(m,n) + 1 does the job. But it is more inefficient, and I 
guess any of the ways to get a boolean matrix resorting to ones or zeros 
is more inefficient than would be a custom primitive.

For instance, these codes allow to measure the average time required by 
the indirect creation of a 1000x1000 boolean matrix by two methods:

for  k=1:20  
     tic()
     a  =  ones(1000,1000)  &  %t;
     t(k)  =  toc()
     clear  a
end
to  =  mean(t)  

for  k=1:20  
     tic()
     a  =  (ones(1000, 1000);
     t(k)  =  toc()
     clear  a
end
to  =  mean(t)

In my i7 laptop it is about 0.017 each, while

for  k=1:20  
     tic()
     a  =  ones(1,n);
     t(k)  =  toc()
     clear  a
end
to  =  mean(t)

takes about half the time. However, if ones is replaced by zeros + 1 it 
takes the same time as both methods for boolean

for k=1:20

     tic()
     a  =  zeros(1000,1000)  +  1;
     t(k)  =  toc();
     clear  a
end
to  =  mean(t)

That's why a primitive for booleans, whatever the syntax (such as the 
proposed ones(m,n,'boolean') would be welcome.

Regards,

Federico Miyara



>> 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
>
> _______________________________________________
> users mailing list
> users at lists.scilab.org
> http://lists.scilab.org/mailman/listinfo/users



---
El software de antivirus Avast ha analizado este correo electrónico en busca de virus.
https://www.avast.com/antivirus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.scilab.org/pipermail/users/attachments/20190917/a041c01d/attachment.htm>