[Pharo-project] [NativeBoost] Question: zero-based or one-based indexes?
Hi, there i added a bunch of accessors to ByteArray and NBExternalAddress which having uniform look: nb<type>At: nb<type>At: put: where types are: {U}Int<8/16/32/64> or Float<32/64> the problem is that indexes in ByteArray are 1-based, but in NBExternalAddress is 0-based. And there's already different places in code which following these rules. But i feel like this should be uniform (so same piece of code can be used for either bytearrays or external addresses), to avoid confusion and mistakes. i just not sure which one to leave: 1-based or 0-based ?
From one side, all collections in smalltalk is 1-based.. but from other side accessing memory at 1-based offset looks also unnatural.
What you think? -- Best regards, Igor Stasenko.
Hello Igor, 0-based - because it's oriented towards C structures (and therefore memory oriented). Another way to see this is: it's not an index, its an byte-offset from the beginning of the memory. Therefore I would not name the parameter as something like index, but more like zeroBasedOffset. By the way: VASmalltalk does it the same way. The same problem might occur, when dealing with pointers to array of primitive data types in ByteArray or instances of NBExternalAddress. Even here I would suggest using zero based index structures - though it is contrary to Smalltalk typical 0ne-based array index. In VASmalltalk this situation is zero-based access and the parameter is not a byte index, but a data element index. And an index of "0" returns the start of the array (and the first element). Marten Am 03.09.2012 02:28, schrieb Igor Stasenko:
Hi, there
i added a bunch of accessors to ByteArray and NBExternalAddress which having uniform look:
nb<type>At: nb<type>At: put:
where types are:
{U}Int<8/16/32/64> or Float<32/64>
the problem is that indexes in ByteArray are 1-based, but in NBExternalAddress is 0-based.
And there's already different places in code which following these rules. But i feel like this should be uniform (so same piece of code can be used for either bytearrays or external addresses), to avoid confusion and mistakes.
i just not sure which one to leave: 1-based or 0-based ?
From one side, all collections in smalltalk is 1-based.. but from other side accessing memory at 1-based offset looks also unnatural.
What you think?
Hi Igor, I am also used to the 0-based when dealing with C-stuff. Cheers, #Luc 2012/9/3 Marten Feldtmann <marten@schrievkrom.de>
Hello Igor,
0-based - because it's oriented towards C structures (and therefore memory oriented).
Another way to see this is: it's not an index, its an byte-offset from the beginning of the memory. Therefore I would not name the parameter as something like index, but more like zeroBasedOffset. By the way: VASmalltalk does it the same way.
The same problem might occur, when dealing with pointers to array of primitive data types in ByteArray or instances of NBExternalAddress.
Even here I would suggest using zero based index structures - though it is contrary to Smalltalk typical 0ne-based array index. In VASmalltalk this situation is zero-based access and the parameter is not a byte index, but a data element index. And an index of "0" returns the start of the array (and the first element).
Marten
Am 03.09.2012 02:28, schrieb Igor Stasenko:
Hi, there
i added a bunch of accessors to ByteArray and NBExternalAddress which having uniform look:
nb<type>At: nb<type>At: put:
where types are:
{U}Int<8/16/32/64> or Float<32/64>
the problem is that indexes in ByteArray are 1-based, but in NBExternalAddress is 0-based.
And there's already different places in code which following these rules. But i feel like this should be uniform (so same piece of code can be used for either bytearrays or external addresses), to avoid confusion and mistakes.
i just not sure which one to leave: 1-based or 0-based ?
From one side, all collections in smalltalk is 1-based.. but from other side accessing memory at 1-based offset looks also unnatural.
What you think?
ok. so i shall convert them all to 0-based. and then carefully look over the code and get rid of 1-based assumption. On 3 September 2012 11:58, Luc Fabresse <luc.fabresse@gmail.com> wrote:
Hi Igor,
I am also used to the 0-based when dealing with C-stuff.
Cheers,
#Luc
2012/9/3 Marten Feldtmann <marten@schrievkrom.de>
Hello Igor,
0-based - because it's oriented towards C structures (and therefore memory oriented).
Another way to see this is: it's not an index, its an byte-offset from the beginning of the memory. Therefore I would not name the parameter as something like index, but more like zeroBasedOffset. By the way: VASmalltalk does it the same way.
The same problem might occur, when dealing with pointers to array of primitive data types in ByteArray or instances of NBExternalAddress.
Even here I would suggest using zero based index structures - though it is contrary to Smalltalk typical 0ne-based array index. In VASmalltalk this situation is zero-based access and the parameter is not a byte index, but a data element index. And an index of "0" returns the start of the array (and the first element).
Marten
Am 03.09.2012 02:28, schrieb Igor Stasenko:
Hi, there
i added a bunch of accessors to ByteArray and NBExternalAddress which having uniform look:
nb<type>At: nb<type>At: put:
where types are:
{U}Int<8/16/32/64> or Float<32/64>
the problem is that indexes in ByteArray are 1-based, but in NBExternalAddress is 0-based.
And there's already different places in code which following these rules. But i feel like this should be uniform (so same piece of code can be used for either bytearrays or external addresses), to avoid confusion and mistakes.
i just not sure which one to leave: 1-based or 0-based ?
From one side, all collections in smalltalk is 1-based.. but from other side accessing memory at 1-based offset looks also unnatural.
What you think?
-- Best regards, Igor Stasenko.
+1 to calling the 0-based stuff *offset* /Peter On Mon, Sep 3, 2012 at 12:02 PM, Igor Stasenko <siguctua@gmail.com> wrote:
ok. so i shall convert them all to 0-based. and then carefully look over the code and get rid of 1-based assumption.
On 3 September 2012 11:58, Luc Fabresse <luc.fabresse@gmail.com> wrote:
Hi Igor,
I am also used to the 0-based when dealing with C-stuff.
Cheers,
#Luc
2012/9/3 Marten Feldtmann <marten@schrievkrom.de>
Hello Igor,
0-based - because it's oriented towards C structures (and therefore
memory
oriented).
Another way to see this is: it's not an index, its an byte-offset from the beginning of the memory. Therefore I would not name the parameter as something like index, but more like zeroBasedOffset. By the way: VASmalltalk does it the same way.
The same problem might occur, when dealing with pointers to array of primitive data types in ByteArray or instances of NBExternalAddress.
Even here I would suggest using zero based index structures - though it is contrary to Smalltalk typical 0ne-based array index. In VASmalltalk this situation is zero-based access and the parameter is not a byte index, but a data element index. And an index of "0" returns the start of the array (and the first element).
Marten
Am 03.09.2012 02:28, schrieb Igor Stasenko:
Hi, there
i added a bunch of accessors to ByteArray and NBExternalAddress which having uniform look:
nb<type>At: nb<type>At: put:
where types are:
{U}Int<8/16/32/64> or Float<32/64>
the problem is that indexes in ByteArray are 1-based, but in NBExternalAddress is 0-based.
And there's already different places in code which following these rules. But i feel like this should be uniform (so same piece of code can be used for either bytearrays or external addresses), to avoid confusion and mistakes.
i just not sure which one to leave: 1-based or 0-based ?
From one side, all collections in smalltalk is 1-based.. but from other side accessing memory at 1-based offset looks also unnatural.
What you think?
-- Best regards, Igor Stasenko.
+ 1 Iike the zeroBasedOffset name :) On Sep 3, 2012, at 12:04 PM, Peter Hugosson-Miller wrote:
+1 to calling the 0-based stuff *offset*
/Peter
On Mon, Sep 3, 2012 at 12:02 PM, Igor Stasenko <siguctua@gmail.com> wrote: ok. so i shall convert them all to 0-based. and then carefully look over the code and get rid of 1-based assumption.
On 3 September 2012 11:58, Luc Fabresse <luc.fabresse@gmail.com> wrote:
Hi Igor,
I am also used to the 0-based when dealing with C-stuff.
Cheers,
#Luc
2012/9/3 Marten Feldtmann <marten@schrievkrom.de>
Hello Igor,
0-based - because it's oriented towards C structures (and therefore memory oriented).
Another way to see this is: it's not an index, its an byte-offset from the beginning of the memory. Therefore I would not name the parameter as something like index, but more like zeroBasedOffset. By the way: VASmalltalk does it the same way.
The same problem might occur, when dealing with pointers to array of primitive data types in ByteArray or instances of NBExternalAddress.
Even here I would suggest using zero based index structures - though it is contrary to Smalltalk typical 0ne-based array index. In VASmalltalk this situation is zero-based access and the parameter is not a byte index, but a data element index. And an index of "0" returns the start of the array (and the first element).
Marten
Am 03.09.2012 02:28, schrieb Igor Stasenko:
Hi, there
i added a bunch of accessors to ByteArray and NBExternalAddress which having uniform look:
nb<type>At: nb<type>At: put:
where types are:
{U}Int<8/16/32/64> or Float<32/64>
the problem is that indexes in ByteArray are 1-based, but in NBExternalAddress is 0-based.
And there's already different places in code which following these rules. But i feel like this should be uniform (so same piece of code can be used for either bytearrays or external addresses), to avoid confusion and mistakes.
i just not sure which one to leave: 1-based or 0-based ?
From one side, all collections in smalltalk is 1-based.. but from other side accessing memory at 1-based offset looks also unnatural.
What you think?
-- Best regards, Igor Stasenko.
feldti wrote
0-based - because it's oriented towards C structures (and therefore memory oriented). ... it's not an index, its an byte-offset from the beginning of the memory.
I defer to those who have experience working in the C domain (not me for a long time, thank goodness). And, please if we decide to use 1-based, call it something other than index, which already has a meaning in our domain. Offset sounds good. - S -- View this message in context: http://forum.world.st/NativeBoost-Question-zero-based-or-one-based-indexes-t... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Here we use a convention of naming 0 based accessors with atOffset: and atOffset:put:. If applicable, this could be a good tradeoff. Of course, the arguments are simple integers, but the 0 index gets explicit by the selector. Cheers, Javier. On Mon, Sep 3, 2012 at 11:35 AM, Sean P. DeNigris <sean@clipperadams.com>wrote:
feldti wrote
0-based - because it's oriented towards C structures (and therefore memory oriented). ... it's not an index, its an byte-offset from the beginning of the memory.
I defer to those who have experience working in the C domain (not me for a long time, thank goodness). And, please if we decide to use 1-based, call it something other than index, which already has a meaning in our domain. Offset sounds good.
- S
-- View this message in context: http://forum.world.st/NativeBoost-Question-zero-based-or-one-based-indexes-t... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
-- Lic. Javier Pimás Ciudad de Buenos Aires
On 3 September 2012 16:45, Javier Pimás <elpochodelagente@gmail.com> wrote:
Here we use a convention of naming 0 based accessors with atOffset: and atOffset:put:. If applicable, this could be a good tradeoff. Of course, the arguments are simple integers, but the 0 index gets explicit by the selector.
mmm.. this is more explicit, i agree, but then all selector names will get longer. In our case we're talking about bunch of selectors where first keyword denotes a type: nbFloat32At: nbFloat64At: nbInt16At: .... nbUInt32At: ... etc for me it is not a problem, since 'nb' prefix kinda already says something , like 'watch it, you entering different domain here'.. And , of course renaming 'index' to 'offset' for argument names will also can serve for clarity.. (sure thing you won't see the method's argument name while coding unless you browse the implementation). So, maybe it is not necessarily? So, lets vote for the final form and then i will put it all in uniform way everywhere. foo nbInt64At: 0 vs foo nbInt64AtOffset: 0 what is your pick? -- Best regards, Igor Stasenko.
Igor Stasenko wrote
for me it is not a problem, since 'nb' prefix kinda already says something , like 'watch it, you entering different domain here'..
Ahh... I see. In that case, I retract what I said... I have no opinion here :) -- View this message in context: http://forum.world.st/NativeBoost-Question-zero-based-or-one-based-indexes-t... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
I vote for atOffset because it could be a good way of imposing (or recomending to be more light) like a cultural way of naming zero indexed domains that are much more than only NB. 2012/9/3 Sean P. DeNigris <sean@clipperadams.com>
Igor Stasenko wrote
for me it is not a problem, since 'nb' prefix kinda already says something , like 'watch it, you entering different domain here'..
Ahh... I see. In that case, I retract what I said... I have no opinion here :)
-- View this message in context: http://forum.world.st/NativeBoost-Question-zero-based-or-one-based-indexes-t... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
the change of domain is subtle... "nb" means C conventions? I think that's a knowledge that will be lost with time. +1 offset, even if it is larger :) On Sep 3, 2012, at 5:13 PM, Guido Chari <charig@gmail.com> wrote:
I vote for atOffset because it could be a good way of imposing (or recomending to be more light) like a cultural way of naming zero indexed domains that are much more than only NB.
2012/9/3 Sean P. DeNigris <sean@clipperadams.com>
Igor Stasenko wrote
for me it is not a problem, since 'nb' prefix kinda already says something , like 'watch it, you entering different domain here'..
Ahh... I see. In that case, I retract what I said... I have no opinion here :)
-- View this message in context: http://forum.world.st/NativeBoost-Question-zero-based-or-one-based-indexes-t... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
On 3 September 2012 17:09, Sean P. DeNigris <sean@clipperadams.com> wrote:
Igor Stasenko wrote
for me it is not a problem, since 'nb' prefix kinda already says something , like 'watch it, you entering different domain here'..
Ahh... I see. In that case, I retract what I said... I have no opinion here :)
just imagine you need to write a code which reads raw integer(s) from either byte array(s) or external address. so, you will need to write either: bytarray nbUInt64AtOffset: 10 put: 20 or bytearray nbUInt64At: 10 put: 20. from other side, i thinking maybe Javier is right.. because after just typing two of the above, i have an intuitive feeling that whenever selector ends with 'At:' it should be about working with a single element in array (and therefore a keyword argument i need to pass should be a element index, which as we know in smalltalk should be 1-based).. In contrast, if keyword ends with 'Offset' word, it is absolutely clear that it is not about fetching an element from array. Even more, ending with At: is still leaves room for guessing, like, does that argument is then multiplied with type size or not, i.e. nbUInt64At: 8 --> a real memory offset will be 8*8 while for nbUInt8At: 8 --> a real memory offset will be 1*8 so, i vote for bytarray nbUInt64AtOffset: 10 put: 20 form, despite that i don't like that it is more longer. But it is explicit one. just try to type it youself and listen what you feel :) -- Best regards, Igor Stasenko.
Igor Stasenko wrote
just try to type it youself and listen what you feel :)
Zen and the Art of Pharo Smalltalk -- View this message in context: http://forum.world.st/NativeBoost-Question-zero-based-or-one-based-indexes-t... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
actually, while it is important to have uniformity with those accessors, after introduction of array types, it will be less important.. I plan to do the same as with NBExternalTypeValue.. something like: myArrayType := NBExternalTypeArray ofType: 'int'. myArray := myArrayType new: 10 . "array of 10 ints" myArray at:1 put: 20 myArray at: 2 myArray do: [... ] etc and here there's no longer need to bother whether we use 0-based or 1-based indexes, because it is out of the question: we should use 1-based indexes, because these guys will inherit everything from ArrayedCollection class, and can be used as normal collections. -- Best regards, Igor Stasenko.
Hello 2012/9/3 Igor Stasenko <siguctua@gmail.com>
just imagine you need to write a code which reads raw integer(s) from either byte array(s) or external address.
so, you will need to write either:
bytarray nbUInt64AtOffset: 10 put: 20
or
bytearray nbUInt64At: 10 put: 20.
I like explicit objects for arguments. So your examples can be something like: bytearray nbAt: 10 asOffset put: 20 nbUInt64 bytearray nbAt: 10 asOffset put: 20 nbInt32 bytearray nbAt: 10 asOffset put: 20 nbFloat or bytearray nbAt: 1 asIndex put: 20 nbUInt64 For this classes like NbArrayOffset, NbArrayIndex and others should be introduced Best regards, Denis
Igor, for me it does not matter. I've created my own interface package for all base types, array access - and all zero-index based - either for Smalltalk-memory or external memory access. That's good enough for me and my projects. Now I'm waiting for your base package with all these new accessor methods. Marten
On 3 September 2012 20:09, Marten Feldtmann <marten@schrievkrom.de> wrote:
Igor,
for me it does not matter. I've created my own interface package for all base types, array access - and all zero-index based - either for Smalltalk-memory or external memory access. That's good enough for me and my projects. Now I'm waiting for your base package with all these new accessor methods.
Yes, i know. But i care about things which people will have by default.. because imagine that each project will have own accessors in byte arrays and so on.. at the end you will end up with dozens of methods doing the same thing.. And so, to prevent that, of course, we need a good common layer, which everyone can use instead of inventing own wheel over and over again.
Marten
-- Best regards, Igor Stasenko.
On 3 September 2012 19:31, Denis Kudriashov <dionisiydk@gmail.com> wrote:
Hello
2012/9/3 Igor Stasenko <siguctua@gmail.com>
just imagine you need to write a code which reads raw integer(s) from either byte array(s) or external address.
so, you will need to write either:
bytarray nbUInt64AtOffset: 10 put: 20
or
bytearray nbUInt64At: 10 put: 20.
I like explicit objects for arguments. So your examples can be something like:
bytearray nbAt: 10 asOffset put: 20 nbUInt64 bytearray nbAt: 10 asOffset put: 20 nbInt32 bytearray nbAt: 10 asOffset put: 20 nbFloat
or
bytearray nbAt: 1 asIndex put: 20 nbUInt64
For this classes like NbArrayOffset, NbArrayIndex and others should be introduced
the problem with your approach that it will slow down everything , up to the point that it will become useless. :) -- Best regards, Igor Stasenko.
participants (10)
-
Denis Kudriashov -
Esteban Lorenzano -
Guido Chari -
Igor Stasenko -
Javier Pimás -
Luc Fabresse -
Marten Feldtmann -
Peter Hugosson-Miller -
Sean P. DeNigris -
Stéphane Ducasse