[Scilab-users] Bitget for int64/uint64

classic Classic list List threaded Threaded
12 messages Options
JLan JLan
Reply | Threaded
Open this post in threaded view
|

[Scilab-users] Bitget for int64/uint64

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
  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0
0  0  0  0  0  0  0
         column 33 to 64
  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0
0  0  0  0  1  0  0

--> bitget(b,1:64)
 ans  =
         column 1 to 32
  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0
0  0  0  0  0  0  0
         column 33 to 64
  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0
0  0  0  0  1  0  0



--
Sent from: http://mailinglists.scilab.org/Scilab-users-Mailing-Lists-Archives-f2602246.html
_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users
mottelet mottelet
Reply | Threaded
Open this post in threaded view
|

Re: Bitget for int64/uint64

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  =   2305843009213693952
> --> b=uint64(2^61)+1
>   b  =   2305843009213693953
> --> bitget(a,1:64)
>   ans  =
>           column 1 to 32
>    0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0
> 0  0  0  0  0  0  0
>           column 33 to 64
>    0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0
> 0  0  0  0  1  0  0
>
> --> bitget(b,1:64)
>   ans  =
>           column 1 to 32
>    0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0
> 0  0  0  0  0  0  0
>           column 33 to 64
>    0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0
> 0  0  0  0  1  0  0
>
>
>
> --
> Sent from: https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/mailinglists.scilab.org/Scilab-users-Mailing-Lists-Archives-f2602246.html
> _______________________________________________
> users mailing list
> [hidden email]
> 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
[hidden email]
http://lists.scilab.org/mailman/listinfo/users
mottelet mottelet
Reply | Threaded
Open this post in threaded view
|

Re: Bitget for int64/uint64

But the problem with bitget remains. The new bitstring is ok:

--> bitstring(a)
  ans  =

"0010000000000000000000000000000000000000000000000000000000000000"

--> bitstring(a+1)
  ans  =

"0010000000000000000000000000000000000000000000000000000000000001"

S.

Le 27/02/2020 à 16:37, Stéphane Mottelet a écrit :

> 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  =   2305843009213693952
>> --> b=uint64(2^61)+1
>>   b  =   2305843009213693953
>> --> bitget(a,1:64)
>>   ans  =
>>           column 1 to 32
>>    0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0 0  0 
>> 0  0  0
>> 0  0  0  0  0  0  0
>>           column 33 to 64
>>    0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0 0  0 
>> 0  0  0
>> 0  0  0  0  1  0  0
>>
>> --> bitget(b,1:64)
>>   ans  =
>>           column 1 to 32
>>    0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0 0  0 
>> 0  0  0
>> 0  0  0  0  0  0  0
>>           column 33 to 64
>>    0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0 0  0 
>> 0  0  0
>> 0  0  0  0  1  0  0
>>
>>
>>
>> --
>> Sent from:
>> https://antispam.utc.fr/proxy/2/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/mailinglists.scilab.org/Scilab-users-Mailing-Lists-Archives-f2602246.html
>> _______________________________________________
>> users mailing list
>> [hidden email]
>> https://antispam.utc.fr/proxy/2/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/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
[hidden email]
http://lists.scilab.org/mailman/listinfo/users
Samuel GOUGEON Samuel GOUGEON
Reply | Threaded
Open this post in threaded view
|

Re: Bitget for int64/uint64

In reply to this post by JLan
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(b,1)

--> bitget(b,1)
  ans  =
   0

is a bug.
bitget.tst tests int64 and uint64 cases with other inttypes:
--> edit SCI\modules\elementary_functions\tests\unit_tests\bitget.tst

When bitget() has been extended to 64 bits integers ~3 years ago,
several bugs have appeared about the processing of these integers by
other Scilab functions, noticeably some functions involved in the bitget
implementation.
Not all are fixed (actually, only few of them are fixed).
But maybe it's another issue here. I could have a look, about this
specific case.

If you can do other tests and get issues, please report all of them on
bugzilla.
Thanks

_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users
JLan JLan
Reply | Threaded
Open this post in threaded view
|

Re: Bitget for int64/uint64

In reply to this post by mottelet
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-02-27 16:55 PM, Stéphane Mottelet wrote:

> But the problem with bitget remains. The new bitstring is ok:
>
> --> bitstring(a)
>  ans  =
>
> "0010000000000000000000000000000000000000000000000000000000000000"
>
> --> bitstring(a+1)
>  ans  =
>
> "0010000000000000000000000000000000000000000000000000000000000001"
>
> S.
>
> Le 27/02/2020 à 16:37, Stéphane Mottelet a écrit :
>> 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  =   2305843009213693952
>>> --> b=uint64(2^61)+1
>>>   b  =   2305843009213693953
>>> --> bitget(a,1:64)
>>>   ans  =
>>>           column 1 to 32
>>>    0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0 0  0 
>>> 0  0  0
>>> 0  0  0  0  0  0  0
>>>           column 33 to 64
>>>    0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0 0  0 
>>> 0  0  0
>>> 0  0  0  0  1  0  0
>>>
>>> --> bitget(b,1:64)
>>>   ans  =
>>>           column 1 to 32
>>>    0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0 0  0 
>>> 0  0  0
>>> 0  0  0  0  0  0  0
>>>           column 33 to 64
>>>    0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0 0  0 
>>> 0  0  0
>>> 0  0  0  0  1  0  0
>>>
>>>
>>>
>>> --
>>> Sent from:
>>> https://antispam.utc.fr/proxy/2/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/mailinglists.scilab.org/Scilab-users-Mailing-Lists-Archives-f2602246.html
>>> _______________________________________________
>>> users mailing list
>>> [hidden email]
>>> https://antispam.utc.fr/proxy/2/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users 
>>>
>>
_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users
Samuel GOUGEON Samuel GOUGEON
Reply | Threaded
Open this post in threaded view
|

Re: Bitget for int64/uint64

In reply to this post by Samuel GOUGEON
As suspected, the bug originates from the * operator, that is still not reliable between uint64 or int64:
--> b
 b  =
  2305843009213693955

--> b * uint64(1)
 ans  =
  2305843009213693952

This was reported in 2018 @ http://bugzilla.scilab.org/15836 and is still unfixed.

For bitget, i will see how to do, if there is a workaround. If not, at least warn users in the help page.

Samuel

Le 27/02/2020 à 16:58, Samuel Gougeon a écrit :
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(b,1)

--> bitget(b,1)
 ans  =
  0

is a bug.
bitget.tst tests int64 and uint64 cases with other inttypes:
--> edit SCI\modules\elementary_functions\tests\unit_tests\bitget.tst

When bitget() has been extended to 64 bits integers ~3 years ago, several bugs have appeared about the processing of these integers by other Scilab functions, noticeably some functions involved in the bitget implementation.
Not all are fixed (actually, only few of them are fixed).
But maybe it's another issue here. I could have a look, about this specific case.

If you can do other tests and get issues, please report all of them on bugzilla.
Thanks

_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users



_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users
Samuel GOUGEON Samuel GOUGEON
Reply | Threaded
Open this post in threaded view
|

Re: Bitget for int64/uint64

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 :
As suspected, the bug originates from the * operator, that is still not reliable between uint64 or int64:
--> b
 b  =
  2305843009213693955

--> b * uint64(1)
 ans  =
  2305843009213693952

This was reported in 2018 @ http://bugzilla.scilab.org/15836 and is still unfixed.

For bitget, i will see how to do, if there is a workaround. If not, at least warn users in the help page.

Samuel

Le 27/02/2020 à 16:58, Samuel Gougeon a écrit :
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(b,1)

--> bitget(b,1)
 ans  =
  0

is a bug.
bitget.tst tests int64 and uint64 cases with other inttypes:
--> edit SCI\modules\elementary_functions\tests\unit_tests\bitget.tst

When bitget() has been extended to 64 bits integers ~3 years ago, several bugs have appeared about the processing of these integers by other Scilab functions, noticeably some functions involved in the bitget implementation.
Not all are fixed (actually, only few of them are fixed).
But maybe it's another issue here. I could have a look, about this specific case.

If you can do other tests and get issues, please report all of them on bugzilla.
Thanks

_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users



_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users



_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users
Samuel GOUGEON Samuel GOUGEON
Reply | Threaded
Open this post in threaded view
|

Re: Bitget for int64/uint64

In reply to this post by JLan
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 é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(a,1:64)
 ans  =
         column 1 to 32
  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0 
0  0  0  0  0  0  0
         column 33 to 64
  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0 
0  0  0  0  1  0  0

--> bitget(b,1:64)
 ans  =
         column 1 to 32
  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0 
0  0  0  0  0  0  0
         column 33 to 64
  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0 
0  0  0  0  1  0  0



--
Sent from: http://mailinglists.scilab.org/Scilab-users-Mailing-Lists-Archives-f2602246.html
_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users



_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users
Samuel GOUGEON Samuel GOUGEON
Reply | Threaded
Open this post in threaded view
|

Re: Bitget for int64/uint64

In reply to this post by JLan
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, since a
boolean is stored on 4 bytes.

By the way, providing a result with the same integer type as the input
straightforwardly allows many operations between the input and the
result, if required.

Samuel

_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users
Samuel GOUGEON Samuel GOUGEON
Reply | Threaded
Open this post in threaded view
|

Re: Bitget for int64/uint64

In reply to this post by JLan
Hello Jan,

You will find => there a fixed version of bitget() for big u-int64 integers.
You can patch your Scilab 6.1.0 installation in the following way:
  • download and unzip the file. rename it bitget.sci
  • put bitget.sci in the SCI/elementary_functions/macros directory
  • Run the following Scilab code in the console:
    cd SCI/elementary_functions/macros
    predef clear
    genlib elementary_functionslib
    clear bitget
And then test and use bitget in the current session and all forthcoming ones.

Regards
Samuel

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(a,1:64)
 ans  =
         column 1 to 32
  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0 
0  0  0  0  0  0  0
         column 33 to 64
  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0 
0  0  0  0  1  0  0

--> bitget(b,1:64)
 ans  =
         column 1 to 32
  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0 
0  0  0  0  0  0  0
         column 33 to 64
  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0 
0  0  0  0  1  0  0


_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users
JLan JLan
Reply | Threaded
Open this post in threaded view
|

Re: Bitget for int64/uint64

This post was updated on .
Thank you Samuel

For some reason I get an error message :

--> genlib elementary_functionslib
genlib: Cannot open file ''C:\Program
Files\scilab-6.1.0\modules\elementary_functions\macros\lib''.
  ans  =  F

Although scinotes("lib") opens the file, so it is there.

Anyway, this works fine:

--> exec bitget.sci;
Warning : redefining function: bitget                  . Use funcprot(0)
to avoid this message

EDIT: Works OK when running Scilab as administrator (right click to choose), thanks to Chin Lue Tan for the suggestion.

Regards

Jan


On 2020-02-28 16:25 PM, Samuel Gougeon wrote:
> Hello Jan,
>
> You will find => there
> <https://codereview.scilab.org/cat/21421%2C2%2Cscilab/modules/elementary_functions/macros/bitget.sci
> a fixed version of bitget() for big u-int64 integers.
> You can patch your Scilab 6.1.0 installation in the following way:
>
>   * download and unzip the file. rename it bitget.sci
>   * put bitget.sci in the SCI/elementary_functions/macros directory
>   * Run the following Scilab code in the console:
>     cd SCI/elementary_functions/macros
>     predef clear
>     genlib elementary_functionslib
>     clear bitget
>
> And then test and use bitget in the current session and all
> forthcoming ones.
>
> Regards
> Samuel
>
> 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(a,1:64)
>>   ans  =
>>           column 1 to 32
>>    0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0
>> 0  0  0  0  0  0  0
>>           column 33 to 64
>>    0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0
>> 0  0  0  0  1  0  0
>>
>> --> bitget(b,1:64)
>>   ans  =
>>           column 1 to 32
>>    0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0
>> 0  0  0  0  0  0  0
>>           column 33 to 64
>>    0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0
>> 0  0  0  0  1  0  0
>
>
> _______________________________________________
> users mailing list
> users@lists.scilab.org
> http://lists.scilab.org/mailman/listinfo/users

_______________________________________________
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users
Samuel GOUGEON Samuel GOUGEON
Reply | Threaded
Open this post in threaded view
|

Re: Bitget for int64/uint64

Le 28/02/2020 à 18:14, Jan Åge Langeland a écrit :

>
> Thank you Samuel
>
> For some reason I get an error message :
>
> --> genlib elementary_functionslib
> genlib: Cannot open file ''C:\Program
> Files\scilab-6.1.0\modules\elementary_functions\macros\lib''.
>  ans  =  F
>
> Although scinotes("lib") opens the file, so it is there.
>

If the lib file is opened for another reason -- for instance it is
edited in Scinotes or another editor -- while you run genlib(), then it
is likely locked (by the editor), in such a way that genlib() can't
update it.

Or it may be for another reason.

Samuel
_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users