, for vector creation
Locked
12
12
 
|
Hi,
> On Oct 26, 2017, at 4:09 PM, Sean P. DeNigris <[hidden email]> wrote: > > Peter Uhnák wrote >> But in both cases #, is sent to FileReference/Petit parser instance, so it >> is contained. >> You would use it on a (generic) Number and tie it to specific Bloc >> meaning. > > Yes, this is exactly the problem. It is a reintroduction of a message like > #name, which plagued us for so long. We appropriate the meaning of `aNumber, > …` for the whole world. Now, if in MyCoolProject I want to implement > aNumber>>#, I will break the system. Maybe we can follow the FS/PP pattern > and scope the message to only-vector-like-things via an initial message, so > just like `$f asParser, …`, have `1 {vector-appropriate-message}, …`? You mean like sending @ to a number, right? :) Doru > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html > -- www.tudorgirba.com www.feenk.com "Reasonable is what we are accustomed with." |
|
In reply to this post by Tudor Girba-2
A clear separation between Point and Vector makes perfectly sense.
Ideally, Point should be deprecated then. Otherwise it is a complexity growth. Hilaire Le 26/10/2017 à 11:39, Tudor Girba a écrit : > To make the conversation more interesting, in Bloc we also have BlPoint with subclasses for 2D, 3D and 4D. The reason for this is that we model explicitly the intention of usage even if they share the instance variable names. We did not use Point because we needed 3D and 4D as well and Point has too many meanings that are conflated into one. > > This pattern was used everywhere we could. For example, we have BlBounds instead of Rectangle (actually, this is also because of performance reasons of working directly with 4 numbers rather than 2 points). > > Of course, these come with an apparent extra maintenance cost. So, if we see a possibility of unifying we should definitely take it, and this is where external reviewers can help to point out possibilities. We should just not unify just for the sake of it. -- Dr. Geo http://drgeo.eu |
|
Administrator
|
In reply to this post by Tudor Girba-2
Tudor Girba-2 wrote
> You mean like sending @ to a number, right? :) Ha ha, you got me ;) ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
Cheers,
Sean |
|
|
Thanks everyone for the nice discussion.
So, after all arguments, we will remove Number>>, from Bloc. I think using Number>>, for vector creation makes quite some sense. However, we have already seen that we have a few places where we have vectors: Bloc, PolyMath and Moose-Algos. The Bloc needs are smaller than the needs from PolyMath (we need only a limited set of abilities). So, until we have one consensus of having one vector in the image, we can leave room for playing. In the meantime we have: 1. BlVector x: 10 y: 20 BlVector x: 10 y: 20 z: 30 or: 2. (10@20) asBlocVector (10@20@30) asBlocVector The 2nd option reads ok, but it has the downside that it needs an extra object (the point). An interesting thing about Number>>@ is that it is backed by a primitive. This can be quite relevant and I think it would be worthwhile thinking about vector/matrix specific optimizations as well. That is why, in the future, it would be interesting to consider primitives for vector/matrix creation. Cheers, Doru > On Oct 26, 2017, at 5:10 PM, Sean P. DeNigris <[hidden email]> wrote: > > Tudor Girba-2 wrote >> You mean like sending @ to a number, right? :) > > Ha ha, you got me ;) > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html > -- www.tudorgirba.com www.feenk.com "Not knowing how to do something is not an argument for how it cannot be done." |
|
|
This turned into a much more interesting thread than I expected (gosh you learn lots of stuff by reading comments).
But I am impressed that Feenk listened to what people were saying, distilled it down and didn’t take their ball home - thanks guys. Sometimes in all of these slightly robust conversations I have to keep thinking back to when I went to Pharo days, and how cool it was to see the wonderful things people had produced. It was inspiring…. We have to hold onto that and keep moving the boundaries further without getting disillusioned or blocked. I’m looking forward to the next Pharo Days where hopefully some of this stuff will be reality. Tim > On 26 Oct 2017, at 16:45, Tudor Girba <[hidden email]> wrote: > > Thanks everyone for the nice discussion. > > So, after all arguments, we will remove Number>>, from Bloc. > > I think using Number>>, for vector creation makes quite some sense. However, we have already seen that we have a few places where we have vectors: Bloc, PolyMath and Moose-Algos. The Bloc needs are smaller than the needs from PolyMath (we need only a limited set of abilities). So, until we have one consensus of having one vector in the image, we can leave room for playing. > > In the meantime we have: > > 1. > BlVector x: 10 y: 20 > BlVector x: 10 y: 20 z: 30 > > or: > > 2. > (10@20) asBlocVector > (10@20@30) asBlocVector > > The 2nd option reads ok, but it has the downside that it needs an extra object (the point). > > An interesting thing about Number>>@ is that it is backed by a primitive. This can be quite relevant and I think it would be worthwhile thinking about vector/matrix specific optimizations as well. That is why, in the future, it would be interesting to consider primitives for vector/matrix creation. > > Cheers, > Doru > > >> On Oct 26, 2017, at 5:10 PM, Sean P. DeNigris <[hidden email]> wrote: >> >> Tudor Girba-2 wrote >>> You mean like sending @ to a number, right? :) >> >> Ha ha, you got me ;) >> >> >> >> ----- >> Cheers, >> Sean >> -- >> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >> > > -- > www.tudorgirba.com > www.feenk.com > > "Not knowing how to do something is not an argument for how it cannot be done." > > |
|
|
In reply to this post by Sean P. DeNigris
On Thu, Oct 26, 2017 at 7:09 AM, Sean P. DeNigris <[hidden email]> wrote: Maybe we can follow the FS/PP pattern So, something like 1 vector, 2, 5 or 1 biVector, 2, 6 ? -cbc |
|
|
In reply to this post by Tudor Girba-2
Excellent decision Doru!
Thanks!!!! Alexandre > On Oct 26, 2017, at 8:45 AM, Tudor Girba <[hidden email]> wrote: > > Thanks everyone for the nice discussion. > > So, after all arguments, we will remove Number>>, from Bloc. > > I think using Number>>, for vector creation makes quite some sense. However, we have already seen that we have a few places where we have vectors: Bloc, PolyMath and Moose-Algos. The Bloc needs are smaller than the needs from PolyMath (we need only a limited set of abilities). So, until we have one consensus of having one vector in the image, we can leave room for playing. > > In the meantime we have: > > 1. > BlVector x: 10 y: 20 > BlVector x: 10 y: 20 z: 30 > > or: > > 2. > (10@20) asBlocVector > (10@20@30) asBlocVector > > The 2nd option reads ok, but it has the downside that it needs an extra object (the point). > > An interesting thing about Number>>@ is that it is backed by a primitive. This can be quite relevant and I think it would be worthwhile thinking about vector/matrix specific optimizations as well. That is why, in the future, it would be interesting to consider primitives for vector/matrix creation. > > Cheers, > Doru > > >> On Oct 26, 2017, at 5:10 PM, Sean P. DeNigris <[hidden email]> wrote: >> >> Tudor Girba-2 wrote >>> You mean like sending @ to a number, right? :) >> >> Ha ha, you got me ;) >> >> >> >> ----- >> Cheers, >> Sean >> -- >> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >> > > -- > www.tudorgirba.com > www.feenk.com > > "Not knowing how to do something is not an argument for how it cannot be done." > > |
|
|
In reply to this post by cbc
you could do 1 x + 2 y + 5 z and that expression will give you a 3d vector. but it creates a lot of intermediate objects On Thu, Oct 26, 2017 at 2:04 PM, Chris Cunningham <[hidden email]> wrote:
Bernardo E.C. Sent from a cheap desktop computer in South America. |
|
|
> Autoformatting messing with my parentheses is just a mistake. > I put them in, leave them where they are, 'kay? I do not need an editor that rewrites what I tell it. AST power or not.By the same argument you can tear apart any property of autoformatting. "Why is it messing with my indentation here?" "Why is it removing newlines?" "Why is it removing the last dot?" The problem here is that the autoformatter has no way of knowing that it is some "special" use rather than general binary message. (And for the record, I have startup scripts that modify the source code of the formatter, so I certainly am aware of autoformatting limitations...) Peter On Thu, Oct 26, 2017 at 8:34 PM, Bernardo Ezequiel Contreras <[hidden email]> wrote:
|
|
|
In reply to this post by Tudor Girba-2
Doru
I was thinking that you would also have BlMargin because Margin is a nice concept. When I introduced it with Igor it simplified a lot of code in expand, shrink and other operations. Stef On Thu, Oct 26, 2017 at 11:39 AM, Tudor Girba <[hidden email]> wrote: > Hi, > > To make the conversation more interesting, in Bloc we also have BlPoint with subclasses for 2D, 3D and 4D. The reason for this is that we model explicitly the intention of usage even if they share the instance variable names. We did not use Point because we needed 3D and 4D as well and Point has too many meanings that are conflated into one. > > This pattern was used everywhere we could. For example, we have BlBounds instead of Rectangle (actually, this is also because of performance reasons of working directly with 4 numbers rather than 2 points). > > Of course, these come with an apparent extra maintenance cost. So, if we see a possibility of unifying we should definitely take it, and this is where external reviewers can help to point out possibilities. We should just not unify just for the sake of it. > > Cheers, > Doru > >> On Oct 26, 2017, at 10:57 AM, Tudor Girba <[hidden email]> wrote: >> >> Hi, >> >>> On Oct 26, 2017, at 10:36 AM, Denis Kudriashov <[hidden email]> wrote: >>> >>> 2017-10-26 10:20 GMT+02:00 Tudor Girba <[hidden email]>: >>> Hi, >>>> On Oct 26, 2017, at 10:10 AM, Denis Kudriashov <[hidden email]> wrote: >>>> >>>> Another question. >>>> >>>> Will not these vectors deprecate Point in future ? Imaging that we will completely move to Bloc. >>> >>> No. Point is a perfectly reasonable data structure to describe a position. A Vector is something else and has other contracts. The coincidence is that they share the same variables, but they have different API. For example, a vector has #length. A point does not. >>> >>> Now Point implements most vector operations. The #length is defined as radius by #r message. I imaging that with new vector you will reimplement many of Point methods. Also I doubt that Point plays any role in system which is different than math vector. >> >> I think that over time we have accumulated all sorts of other usages for Point. For example, Rectangle uses origin and corner as a position not as vectors. >> >> Doru >> >>> >>>> And what about Rectangle? (Bloc implements own BlRectangle). >>> >>> These two do not have the same semantics. BlRectangle is a BlGeometry and is used for defining a path within an element. BlRectangle is polymorphic with other paths such as BlEllipse or BlPolygon. Rectangle is a generic data structure that can be used for other purposes. >>> >>> We should definitely try to find commonalities and opportunities for unification. However, we should not confuse state with types which are defined by the purpose they are used for (and associated behavior). >>> >>> Doru >>> >>> >>> >>>> 2017-10-26 9:26 GMT+02:00 [hidden email] <[hidden email]>: >>>> #(1 3 4 5 7 -2) asVector >>>> >>>> Meh. >>>> Ugly. >>>> >>>> { 1. 3. 4. a. b } asVector >>>> >>>> is the natural consequence. >>>> >>>> v := (1,3,4,5,7,-2) asVector >>>> >>>> keeps the parens. But why do I need to do that? >>>> >>>> Autoformatting messing with my parentheses is just a mistake. >>>> I put them in, leave them where they are, 'kay? I do not need an editor that rewrites what I tell it. AST power or not. >>>> >>>> And frankly, I like the "Feenk way of doing things" most of the time, so I am willing to go that route. >>>> >>>> Phil >>>> >>>> >>>> >>>> On Thu, Oct 26, 2017 at 8:52 AM, Peter Uhnák <[hidden email]> wrote: >>>>> >>>>> Automatic formatting will turn it into >>>>> >>>>> vector := 1,3,4,5,7,-2. >>>>> >>>>> Which is not as nice. >>>>> >>>>> And even though it looks ok for literal numbers (#(1 3 4 5 7 -2) asVector would work too), this starts to look quite generic: >>>>> >>>>> vector := width, height, depth. >>>>> >>>>> >>>>> Question: why not extend @ notation? >>>>> >>>>> x @ y @ z? >>>>> >>>>> Peter >>>>> >>>>> >>>>> >>>>> On Thu, Oct 26, 2017 at 8:22 AM, [hidden email] <[hidden email]> wrote: >>>>>> >>>>>> I also like the , message for those vectors and the concatenation of dimensions makes sense. >>>>>> >>>>>> vector := (1,3,4,5,7,-2). >>>>>> >>>>>> looks how it should be. >>>>>> >>>>>> Readable, easy to translate vector stuff from reference text. >>>>>> >>>>>> Phil >>>>>> >>>>>> >>>>>> On Thu, Oct 26, 2017 at 7:00 AM, Nicolai Hess <[hidden email]> wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> Am 25.10.2017 10:50 PM schrieb "Torsten Bergmann" <[hidden email]>: >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> there might be reasons for an own 2D vector class (instead of using Point). >>>>>>> But still I dislike the reimplementation of "," because for me so far it >>>>>>> has the meaning of "concatenating things". >>>>>>> >>>>>>> >>>>>>> >>>>>>> Like concatenating coordinates :-) >>>>>>> >>>>>>> >>>>>>> >>>>>>> Here you redefine it to create vector instances and it works only up to three >>>>>>> so far. Right? >>>>>>> >>>>>>> I understand that this gives some similarities with the math notation (1,2) >>>>>>> but I personally would prefer to use: >>>>>>> >>>>>>> 1@2 asVector >>>>>>> >>>>>>> or Vector2D x: 1 y: 2 >>>>>>> >>>>>>> Thx >>>>>>> T. >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Gesendet: Mittwoch, 25. Oktober 2017 um 20:06 Uhr >>>>>>>> Von: "Tudor Girba" <[hidden email]> >>>>>>>> An: "Pharo Development List" <[hidden email]> >>>>>>>> Betreff: [Pharo-dev] , for vector creation >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> As mentioned in the separate thread, we played with introducing the extension: >>>>>>>> >>>>>>>> , aNumber >>>>>>>> ^ BlVector2D x: self y: aNumber >>>>>>>> >>>>>>>> This means that (10,20) will return a 2D vector. >>>>>>>> >>>>>>>> We also have (10,20,30) which returns a 3D vector. >>>>>>>> >>>>>>>> , is used for different meanings already in the image beside the collection concatenation. For example, in FileReference is adds a file extension. And Exceptions create a collection. In other packages, PetitParser uses it as a sequence operator. >>>>>>>> >>>>>>>> Please voice your concerns. >>>>>>>> >>>>>>>> Cheers, >>>>>>>> Doru >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> www.tudorgirba.com >>>>>>>> www.feenk.com >>>>>>>> >>>>>>>> "Every thing should have the right to be different." >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >>> -- >>> www.tudorgirba.com >>> www.feenk.com >>> >>> "When people care, great things can happen." >>> >>> >>> >>> >>> >>> >> >> -- >> www.tudorgirba.com >> www.feenk.com >> >> "If you interrupt the barber while he is cutting your hair, >> you will end up with a messy haircut." > > -- > www.tudorgirba.com > www.feenk.com > > "We are all great at making mistakes." > > > > > > > > > |
|
|
In reply to this post by Tim Mackinnon
+1
BTW we should start looking for an location for PharoDays 2018 :) On Thu, Oct 26, 2017 at 5:53 PM, Tim Mackinnon <[hidden email]> wrote: > This turned into a much more interesting thread than I expected (gosh you learn lots of stuff by reading comments). > > But I am impressed that Feenk listened to what people were saying, distilled it down and didn’t take their ball home - thanks guys. > > Sometimes in all of these slightly robust conversations I have to keep thinking back to when I went to Pharo days, and how cool it was to see the wonderful things people had produced. It was inspiring…. > > We have to hold onto that and keep moving the boundaries further without getting disillusioned or blocked. > > I’m looking forward to the next Pharo Days where hopefully some of this stuff will be reality. > > Tim > > >> On 26 Oct 2017, at 16:45, Tudor Girba <[hidden email]> wrote: >> >> Thanks everyone for the nice discussion. >> >> So, after all arguments, we will remove Number>>, from Bloc. >> >> I think using Number>>, for vector creation makes quite some sense. However, we have already seen that we have a few places where we have vectors: Bloc, PolyMath and Moose-Algos. The Bloc needs are smaller than the needs from PolyMath (we need only a limited set of abilities). So, until we have one consensus of having one vector in the image, we can leave room for playing. >> >> In the meantime we have: >> >> 1. >> BlVector x: 10 y: 20 >> BlVector x: 10 y: 20 z: 30 >> >> or: >> >> 2. >> (10@20) asBlocVector >> (10@20@30) asBlocVector >> >> The 2nd option reads ok, but it has the downside that it needs an extra object (the point). >> >> An interesting thing about Number>>@ is that it is backed by a primitive. This can be quite relevant and I think it would be worthwhile thinking about vector/matrix specific optimizations as well. That is why, in the future, it would be interesting to consider primitives for vector/matrix creation. >> >> Cheers, >> Doru >> >> >>> On Oct 26, 2017, at 5:10 PM, Sean P. DeNigris <[hidden email]> wrote: >>> >>> Tudor Girba-2 wrote >>>> You mean like sending @ to a number, right? :) >>> >>> Ha ha, you got me ;) >>> >>> >>> >>> ----- >>> Cheers, >>> Sean >>> -- >>> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >>> >> >> -- >> www.tudorgirba.com >> www.feenk.com >> >> "Not knowing how to do something is not an argument for how it cannot be done." >> >> > > |
|
|
In reply to this post by Peter Uhnak
I do not turn on autoformatting and use the format menu entry on an as needed basis. Autoformatting on Seaside renderOn: methods is a royal PITA. Phil On Thu, Oct 26, 2017 at 8:44 PM, Peter Uhnák <[hidden email]> wrote:
|
|
|
In reply to this post by Tudor Girba-2
On Thu, Oct 26, 2017 at 11:45 PM, Tudor Girba <[hidden email]> wrote: Thanks everyone for the nice discussion.
Would it be possible/desirable to have this as a single primitive backed keyword message? (10@:20@:30) Perhaps a goal for the consensus on one-true-vector form integrated into the Image? Except at the moment "@:" doesn't parse. cheers -ben
|
|
|
In reply to this post by Stephane Ducasse-3
Indeed, we have BlInsets that are used for either padding or margin.
Doru > On Oct 26, 2017, at 11:43 PM, Stephane Ducasse <[hidden email]> wrote: > > Doru > > I was thinking that you would also have BlMargin because Margin is a > nice concept. > When I introduced it with Igor it simplified a lot of code in expand, > shrink and other operations. > > Stef > > On Thu, Oct 26, 2017 at 11:39 AM, Tudor Girba <[hidden email]> wrote: >> Hi, >> >> To make the conversation more interesting, in Bloc we also have BlPoint with subclasses for 2D, 3D and 4D. The reason for this is that we model explicitly the intention of usage even if they share the instance variable names. We did not use Point because we needed 3D and 4D as well and Point has too many meanings that are conflated into one. >> >> This pattern was used everywhere we could. For example, we have BlBounds instead of Rectangle (actually, this is also because of performance reasons of working directly with 4 numbers rather than 2 points). >> >> Of course, these come with an apparent extra maintenance cost. So, if we see a possibility of unifying we should definitely take it, and this is where external reviewers can help to point out possibilities. We should just not unify just for the sake of it. >> >> Cheers, >> Doru >> >>> On Oct 26, 2017, at 10:57 AM, Tudor Girba <[hidden email]> wrote: >>> >>> Hi, >>> >>>> On Oct 26, 2017, at 10:36 AM, Denis Kudriashov <[hidden email]> wrote: >>>> >>>> 2017-10-26 10:20 GMT+02:00 Tudor Girba <[hidden email]>: >>>> Hi, >>>>> On Oct 26, 2017, at 10:10 AM, Denis Kudriashov <[hidden email]> wrote: >>>>> >>>>> Another question. >>>>> >>>>> Will not these vectors deprecate Point in future ? Imaging that we will completely move to Bloc. >>>> >>>> No. Point is a perfectly reasonable data structure to describe a position. A Vector is something else and has other contracts. The coincidence is that they share the same variables, but they have different API. For example, a vector has #length. A point does not. >>>> >>>> Now Point implements most vector operations. The #length is defined as radius by #r message. I imaging that with new vector you will reimplement many of Point methods. Also I doubt that Point plays any role in system which is different than math vector. >>> >>> I think that over time we have accumulated all sorts of other usages for Point. For example, Rectangle uses origin and corner as a position not as vectors. >>> >>> Doru >>> >>>> >>>>> And what about Rectangle? (Bloc implements own BlRectangle). >>>> >>>> These two do not have the same semantics. BlRectangle is a BlGeometry and is used for defining a path within an element. BlRectangle is polymorphic with other paths such as BlEllipse or BlPolygon. Rectangle is a generic data structure that can be used for other purposes. >>>> >>>> We should definitely try to find commonalities and opportunities for unification. However, we should not confuse state with types which are defined by the purpose they are used for (and associated behavior). >>>> >>>> Doru >>>> >>>> >>>> >>>>> 2017-10-26 9:26 GMT+02:00 [hidden email] <[hidden email]>: >>>>> #(1 3 4 5 7 -2) asVector >>>>> >>>>> Meh. >>>>> Ugly. >>>>> >>>>> { 1. 3. 4. a. b } asVector >>>>> >>>>> is the natural consequence. >>>>> >>>>> v := (1,3,4,5,7,-2) asVector >>>>> >>>>> keeps the parens. But why do I need to do that? >>>>> >>>>> Autoformatting messing with my parentheses is just a mistake. >>>>> I put them in, leave them where they are, 'kay? I do not need an editor that rewrites what I tell it. AST power or not. >>>>> >>>>> And frankly, I like the "Feenk way of doing things" most of the time, so I am willing to go that route. >>>>> >>>>> Phil >>>>> >>>>> >>>>> >>>>> On Thu, Oct 26, 2017 at 8:52 AM, Peter Uhnák <[hidden email]> wrote: >>>>>> >>>>>> Automatic formatting will turn it into >>>>>> >>>>>> vector := 1,3,4,5,7,-2. >>>>>> >>>>>> Which is not as nice. >>>>>> >>>>>> And even though it looks ok for literal numbers (#(1 3 4 5 7 -2) asVector would work too), this starts to look quite generic: >>>>>> >>>>>> vector := width, height, depth. >>>>>> >>>>>> >>>>>> Question: why not extend @ notation? >>>>>> >>>>>> x @ y @ z? >>>>>> >>>>>> Peter >>>>>> >>>>>> >>>>>> >>>>>> On Thu, Oct 26, 2017 at 8:22 AM, [hidden email] <[hidden email]> wrote: >>>>>>> >>>>>>> I also like the , message for those vectors and the concatenation of dimensions makes sense. >>>>>>> >>>>>>> vector := (1,3,4,5,7,-2). >>>>>>> >>>>>>> looks how it should be. >>>>>>> >>>>>>> Readable, easy to translate vector stuff from reference text. >>>>>>> >>>>>>> Phil >>>>>>> >>>>>>> >>>>>>> On Thu, Oct 26, 2017 at 7:00 AM, Nicolai Hess <[hidden email]> wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Am 25.10.2017 10:50 PM schrieb "Torsten Bergmann" <[hidden email]>: >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> there might be reasons for an own 2D vector class (instead of using Point). >>>>>>>> But still I dislike the reimplementation of "," because for me so far it >>>>>>>> has the meaning of "concatenating things". >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Like concatenating coordinates :-) >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Here you redefine it to create vector instances and it works only up to three >>>>>>>> so far. Right? >>>>>>>> >>>>>>>> I understand that this gives some similarities with the math notation (1,2) >>>>>>>> but I personally would prefer to use: >>>>>>>> >>>>>>>> 1@2 asVector >>>>>>>> >>>>>>>> or Vector2D x: 1 y: 2 >>>>>>>> >>>>>>>> Thx >>>>>>>> T. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> Gesendet: Mittwoch, 25. Oktober 2017 um 20:06 Uhr >>>>>>>>> Von: "Tudor Girba" <[hidden email]> >>>>>>>>> An: "Pharo Development List" <[hidden email]> >>>>>>>>> Betreff: [Pharo-dev] , for vector creation >>>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> As mentioned in the separate thread, we played with introducing the extension: >>>>>>>>> >>>>>>>>> , aNumber >>>>>>>>> ^ BlVector2D x: self y: aNumber >>>>>>>>> >>>>>>>>> This means that (10,20) will return a 2D vector. >>>>>>>>> >>>>>>>>> We also have (10,20,30) which returns a 3D vector. >>>>>>>>> >>>>>>>>> , is used for different meanings already in the image beside the collection concatenation. For example, in FileReference is adds a file extension. And Exceptions create a collection. In other packages, PetitParser uses it as a sequence operator. >>>>>>>>> >>>>>>>>> Please voice your concerns. >>>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> Doru >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> www.tudorgirba.com >>>>>>>>> www.feenk.com >>>>>>>>> >>>>>>>>> "Every thing should have the right to be different." >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>>> -- >>>> www.tudorgirba.com >>>> www.feenk.com >>>> >>>> "When people care, great things can happen." >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> -- >>> www.tudorgirba.com >>> www.feenk.com >>> >>> "If you interrupt the barber while he is cutting your hair, >>> you will end up with a messy haircut." >> >> -- >> www.tudorgirba.com >> www.feenk.com >> >> "We are all great at making mistakes." >> >> >> >> >> >> >> >> >> > -- www.tudorgirba.com www.feenk.com "If you can't say why something is relevant, it probably isn't." |
|
|
Ok good to know.
On Fri, Oct 27, 2017 at 8:39 AM, Tudor Girba <[hidden email]> wrote: > Indeed, we have BlInsets that are used for either padding or margin. > > Doru > >> On Oct 26, 2017, at 11:43 PM, Stephane Ducasse <[hidden email]> wrote: >> >> Doru >> >> I was thinking that you would also have BlMargin because Margin is a >> nice concept. >> When I introduced it with Igor it simplified a lot of code in expand, >> shrink and other operations. >> >> Stef >> >> On Thu, Oct 26, 2017 at 11:39 AM, Tudor Girba <[hidden email]> wrote: >>> Hi, >>> >>> To make the conversation more interesting, in Bloc we also have BlPoint with subclasses for 2D, 3D and 4D. The reason for this is that we model explicitly the intention of usage even if they share the instance variable names. We did not use Point because we needed 3D and 4D as well and Point has too many meanings that are conflated into one. >>> >>> This pattern was used everywhere we could. For example, we have BlBounds instead of Rectangle (actually, this is also because of performance reasons of working directly with 4 numbers rather than 2 points). >>> >>> Of course, these come with an apparent extra maintenance cost. So, if we see a possibility of unifying we should definitely take it, and this is where external reviewers can help to point out possibilities. We should just not unify just for the sake of it. >>> >>> Cheers, >>> Doru >>> >>>> On Oct 26, 2017, at 10:57 AM, Tudor Girba <[hidden email]> wrote: >>>> >>>> Hi, >>>> >>>>> On Oct 26, 2017, at 10:36 AM, Denis Kudriashov <[hidden email]> wrote: >>>>> >>>>> 2017-10-26 10:20 GMT+02:00 Tudor Girba <[hidden email]>: >>>>> Hi, >>>>>> On Oct 26, 2017, at 10:10 AM, Denis Kudriashov <[hidden email]> wrote: >>>>>> >>>>>> Another question. >>>>>> >>>>>> Will not these vectors deprecate Point in future ? Imaging that we will completely move to Bloc. >>>>> >>>>> No. Point is a perfectly reasonable data structure to describe a position. A Vector is something else and has other contracts. The coincidence is that they share the same variables, but they have different API. For example, a vector has #length. A point does not. >>>>> >>>>> Now Point implements most vector operations. The #length is defined as radius by #r message. I imaging that with new vector you will reimplement many of Point methods. Also I doubt that Point plays any role in system which is different than math vector. >>>> >>>> I think that over time we have accumulated all sorts of other usages for Point. For example, Rectangle uses origin and corner as a position not as vectors. >>>> >>>> Doru >>>> >>>>> >>>>>> And what about Rectangle? (Bloc implements own BlRectangle). >>>>> >>>>> These two do not have the same semantics. BlRectangle is a BlGeometry and is used for defining a path within an element. BlRectangle is polymorphic with other paths such as BlEllipse or BlPolygon. Rectangle is a generic data structure that can be used for other purposes. >>>>> >>>>> We should definitely try to find commonalities and opportunities for unification. However, we should not confuse state with types which are defined by the purpose they are used for (and associated behavior). >>>>> >>>>> Doru >>>>> >>>>> >>>>> >>>>>> 2017-10-26 9:26 GMT+02:00 [hidden email] <[hidden email]>: >>>>>> #(1 3 4 5 7 -2) asVector >>>>>> >>>>>> Meh. >>>>>> Ugly. >>>>>> >>>>>> { 1. 3. 4. a. b } asVector >>>>>> >>>>>> is the natural consequence. >>>>>> >>>>>> v := (1,3,4,5,7,-2) asVector >>>>>> >>>>>> keeps the parens. But why do I need to do that? >>>>>> >>>>>> Autoformatting messing with my parentheses is just a mistake. >>>>>> I put them in, leave them where they are, 'kay? I do not need an editor that rewrites what I tell it. AST power or not. >>>>>> >>>>>> And frankly, I like the "Feenk way of doing things" most of the time, so I am willing to go that route. >>>>>> >>>>>> Phil >>>>>> >>>>>> >>>>>> >>>>>> On Thu, Oct 26, 2017 at 8:52 AM, Peter Uhnák <[hidden email]> wrote: >>>>>>> >>>>>>> Automatic formatting will turn it into >>>>>>> >>>>>>> vector := 1,3,4,5,7,-2. >>>>>>> >>>>>>> Which is not as nice. >>>>>>> >>>>>>> And even though it looks ok for literal numbers (#(1 3 4 5 7 -2) asVector would work too), this starts to look quite generic: >>>>>>> >>>>>>> vector := width, height, depth. >>>>>>> >>>>>>> >>>>>>> Question: why not extend @ notation? >>>>>>> >>>>>>> x @ y @ z? >>>>>>> >>>>>>> Peter >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Thu, Oct 26, 2017 at 8:22 AM, [hidden email] <[hidden email]> wrote: >>>>>>>> >>>>>>>> I also like the , message for those vectors and the concatenation of dimensions makes sense. >>>>>>>> >>>>>>>> vector := (1,3,4,5,7,-2). >>>>>>>> >>>>>>>> looks how it should be. >>>>>>>> >>>>>>>> Readable, easy to translate vector stuff from reference text. >>>>>>>> >>>>>>>> Phil >>>>>>>> >>>>>>>> >>>>>>>> On Thu, Oct 26, 2017 at 7:00 AM, Nicolai Hess <[hidden email]> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Am 25.10.2017 10:50 PM schrieb "Torsten Bergmann" <[hidden email]>: >>>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> there might be reasons for an own 2D vector class (instead of using Point). >>>>>>>>> But still I dislike the reimplementation of "," because for me so far it >>>>>>>>> has the meaning of "concatenating things". >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Like concatenating coordinates :-) >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Here you redefine it to create vector instances and it works only up to three >>>>>>>>> so far. Right? >>>>>>>>> >>>>>>>>> I understand that this gives some similarities with the math notation (1,2) >>>>>>>>> but I personally would prefer to use: >>>>>>>>> >>>>>>>>> 1@2 asVector >>>>>>>>> >>>>>>>>> or Vector2D x: 1 y: 2 >>>>>>>>> >>>>>>>>> Thx >>>>>>>>> T. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> Gesendet: Mittwoch, 25. Oktober 2017 um 20:06 Uhr >>>>>>>>>> Von: "Tudor Girba" <[hidden email]> >>>>>>>>>> An: "Pharo Development List" <[hidden email]> >>>>>>>>>> Betreff: [Pharo-dev] , for vector creation >>>>>>>>>> >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> As mentioned in the separate thread, we played with introducing the extension: >>>>>>>>>> >>>>>>>>>> , aNumber >>>>>>>>>> ^ BlVector2D x: self y: aNumber >>>>>>>>>> >>>>>>>>>> This means that (10,20) will return a 2D vector. >>>>>>>>>> >>>>>>>>>> We also have (10,20,30) which returns a 3D vector. >>>>>>>>>> >>>>>>>>>> , is used for different meanings already in the image beside the collection concatenation. For example, in FileReference is adds a file extension. And Exceptions create a collection. In other packages, PetitParser uses it as a sequence operator. >>>>>>>>>> >>>>>>>>>> Please voice your concerns. >>>>>>>>>> >>>>>>>>>> Cheers, >>>>>>>>>> Doru >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> www.tudorgirba.com >>>>>>>>>> www.feenk.com >>>>>>>>>> >>>>>>>>>> "Every thing should have the right to be different." >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>>> -- >>>>> www.tudorgirba.com >>>>> www.feenk.com >>>>> >>>>> "When people care, great things can happen." >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> -- >>>> www.tudorgirba.com >>>> www.feenk.com >>>> >>>> "If you interrupt the barber while he is cutting your hair, >>>> you will end up with a messy haircut." >>> >>> -- >>> www.tudorgirba.com >>> www.feenk.com >>> >>> "We are all great at making mistakes." >>> >>> >>> >>> >>> >>> >>> >>> >>> >> > > -- > www.tudorgirba.com > www.feenk.com > > "If you can't say why something is relevant, > it probably isn't." > > |
|
|
Just a few notes: 1) 4 , 2 , 3 , 5 looks too much like Shlemiel the painter, ok for short vector input, but not even for printing (think re-interpreting)2017-10-27 19:12 GMT+02:00 Stephane Ducasse <[hidden email]>: Ok good to know. |
|
|
(1 i: 2) is nice.
Tx for the feedback nicolas. On Sat, Oct 28, 2017 at 11:15 PM, Nicolas Cellier <[hidden email]> wrote: > Just a few notes: > > 1) 4 , 2 , 3 , 5 looks too much like Shlemiel the painter, ok for short > vector input, but not even for printing (think re-interpreting) > > 2) 1 x + 2 y + 3 z might look nice. Exactly like 1+2i (Complex) or > 1+2i+3j+4k (Quaternion) > But for the sake of efficiency, I had to introduce (1 i: 2) otherwise > interpretng a complex matrix was too much expensive (compared to Matlab) > > 3) as Doru said, there are many possible conflicts for Number>>, I'm pretty > sure that Jun was using it too > for this reason I removed it from Smallapack > > 2017-10-27 19:12 GMT+02:00 Stephane Ducasse <[hidden email]>: >> >> Ok good to know. >> >> On Fri, Oct 27, 2017 at 8:39 AM, Tudor Girba <[hidden email]> wrote: >> > Indeed, we have BlInsets that are used for either padding or margin. >> > >> > Doru >> > >> >> On Oct 26, 2017, at 11:43 PM, Stephane Ducasse >> >> <[hidden email]> wrote: >> >> >> >> Doru >> >> >> >> I was thinking that you would also have BlMargin because Margin is a >> >> nice concept. >> >> When I introduced it with Igor it simplified a lot of code in expand, >> >> shrink and other operations. >> >> >> >> Stef >> >> >> >> On Thu, Oct 26, 2017 at 11:39 AM, Tudor Girba <[hidden email]> >> >> wrote: >> >>> Hi, >> >>> >> >>> To make the conversation more interesting, in Bloc we also have >> >>> BlPoint with subclasses for 2D, 3D and 4D. The reason for this is that we >> >>> model explicitly the intention of usage even if they share the instance >> >>> variable names. We did not use Point because we needed 3D and 4D as well and >> >>> Point has too many meanings that are conflated into one. >> >>> >> >>> This pattern was used everywhere we could. For example, we have >> >>> BlBounds instead of Rectangle (actually, this is also because of performance >> >>> reasons of working directly with 4 numbers rather than 2 points). >> >>> >> >>> Of course, these come with an apparent extra maintenance cost. So, if >> >>> we see a possibility of unifying we should definitely take it, and this is >> >>> where external reviewers can help to point out possibilities. We should just >> >>> not unify just for the sake of it. >> >>> >> >>> Cheers, >> >>> Doru >> >>> >> >>>> On Oct 26, 2017, at 10:57 AM, Tudor Girba <[hidden email]> >> >>>> wrote: >> >>>> >> >>>> Hi, >> >>>> >> >>>>> On Oct 26, 2017, at 10:36 AM, Denis Kudriashov >> >>>>> <[hidden email]> wrote: >> >>>>> >> >>>>> 2017-10-26 10:20 GMT+02:00 Tudor Girba <[hidden email]>: >> >>>>> Hi, >> >>>>>> On Oct 26, 2017, at 10:10 AM, Denis Kudriashov >> >>>>>> <[hidden email]> wrote: >> >>>>>> >> >>>>>> Another question. >> >>>>>> >> >>>>>> Will not these vectors deprecate Point in future ? Imaging that we >> >>>>>> will completely move to Bloc. >> >>>>> >> >>>>> No. Point is a perfectly reasonable data structure to describe a >> >>>>> position. A Vector is something else and has other contracts. The >> >>>>> coincidence is that they share the same variables, but they have different >> >>>>> API. For example, a vector has #length. A point does not. >> >>>>> >> >>>>> Now Point implements most vector operations. The #length is defined >> >>>>> as radius by #r message. I imaging that with new vector you will reimplement >> >>>>> many of Point methods. Also I doubt that Point plays any role in system >> >>>>> which is different than math vector. >> >>>> >> >>>> I think that over time we have accumulated all sorts of other usages >> >>>> for Point. For example, Rectangle uses origin and corner as a position not >> >>>> as vectors. >> >>>> >> >>>> Doru >> >>>> >> >>>>> >> >>>>>> And what about Rectangle? (Bloc implements own BlRectangle). >> >>>>> >> >>>>> These two do not have the same semantics. BlRectangle is a >> >>>>> BlGeometry and is used for defining a path within an element. BlRectangle is >> >>>>> polymorphic with other paths such as BlEllipse or BlPolygon. Rectangle is a >> >>>>> generic data structure that can be used for other purposes. >> >>>>> >> >>>>> We should definitely try to find commonalities and opportunities for >> >>>>> unification. However, we should not confuse state with types which are >> >>>>> defined by the purpose they are used for (and associated behavior). >> >>>>> >> >>>>> Doru >> >>>>> >> >>>>> >> >>>>> >> >>>>>> 2017-10-26 9:26 GMT+02:00 [hidden email] <[hidden email]>: >> >>>>>> #(1 3 4 5 7 -2) asVector >> >>>>>> >> >>>>>> Meh. >> >>>>>> Ugly. >> >>>>>> >> >>>>>> { 1. 3. 4. a. b } asVector >> >>>>>> >> >>>>>> is the natural consequence. >> >>>>>> >> >>>>>> v := (1,3,4,5,7,-2) asVector >> >>>>>> >> >>>>>> keeps the parens. But why do I need to do that? >> >>>>>> >> >>>>>> Autoformatting messing with my parentheses is just a mistake. >> >>>>>> I put them in, leave them where they are, 'kay? I do not need an >> >>>>>> editor that rewrites what I tell it. AST power or not. >> >>>>>> >> >>>>>> And frankly, I like the "Feenk way of doing things" most of the >> >>>>>> time, so I am willing to go that route. >> >>>>>> >> >>>>>> Phil >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> On Thu, Oct 26, 2017 at 8:52 AM, Peter Uhnák <[hidden email]> >> >>>>>> wrote: >> >>>>>>> >> >>>>>>> Automatic formatting will turn it into >> >>>>>>> >> >>>>>>> vector := 1,3,4,5,7,-2. >> >>>>>>> >> >>>>>>> Which is not as nice. >> >>>>>>> >> >>>>>>> And even though it looks ok for literal numbers (#(1 3 4 5 7 -2) >> >>>>>>> asVector would work too), this starts to look quite generic: >> >>>>>>> >> >>>>>>> vector := width, height, depth. >> >>>>>>> >> >>>>>>> >> >>>>>>> Question: why not extend @ notation? >> >>>>>>> >> >>>>>>> x @ y @ z? >> >>>>>>> >> >>>>>>> Peter >> >>>>>>> >> >>>>>>> >> >>>>>>> >> >>>>>>> On Thu, Oct 26, 2017 at 8:22 AM, [hidden email] >> >>>>>>> <[hidden email]> wrote: >> >>>>>>>> >> >>>>>>>> I also like the , message for those vectors and the concatenation >> >>>>>>>> of dimensions makes sense. >> >>>>>>>> >> >>>>>>>> vector := (1,3,4,5,7,-2). >> >>>>>>>> >> >>>>>>>> looks how it should be. >> >>>>>>>> >> >>>>>>>> Readable, easy to translate vector stuff from reference text. >> >>>>>>>> >> >>>>>>>> Phil >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> On Thu, Oct 26, 2017 at 7:00 AM, Nicolai Hess >> >>>>>>>> <[hidden email]> wrote: >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> Am 25.10.2017 10:50 PM schrieb "Torsten Bergmann" >> >>>>>>>>> <[hidden email]>: >> >>>>>>>>> >> >>>>>>>>> Hi, >> >>>>>>>>> >> >>>>>>>>> there might be reasons for an own 2D vector class (instead of >> >>>>>>>>> using Point). >> >>>>>>>>> But still I dislike the reimplementation of "," because for me >> >>>>>>>>> so far it >> >>>>>>>>> has the meaning of "concatenating things". >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> Like concatenating coordinates :-) >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> Here you redefine it to create vector instances and it works >> >>>>>>>>> only up to three >> >>>>>>>>> so far. Right? >> >>>>>>>>> >> >>>>>>>>> I understand that this gives some similarities with the math >> >>>>>>>>> notation (1,2) >> >>>>>>>>> but I personally would prefer to use: >> >>>>>>>>> >> >>>>>>>>> 1@2 asVector >> >>>>>>>>> >> >>>>>>>>> or Vector2D x: 1 y: 2 >> >>>>>>>>> >> >>>>>>>>> Thx >> >>>>>>>>> T. >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>>> Gesendet: Mittwoch, 25. Oktober 2017 um 20:06 Uhr >> >>>>>>>>>> Von: "Tudor Girba" <[hidden email]> >> >>>>>>>>>> An: "Pharo Development List" <[hidden email]> >> >>>>>>>>>> Betreff: [Pharo-dev] , for vector creation >> >>>>>>>>>> >> >>>>>>>>>> Hi, >> >>>>>>>>>> >> >>>>>>>>>> As mentioned in the separate thread, we played with introducing >> >>>>>>>>>> the extension: >> >>>>>>>>>> >> >>>>>>>>>> , aNumber >> >>>>>>>>>> ^ BlVector2D x: self y: aNumber >> >>>>>>>>>> >> >>>>>>>>>> This means that (10,20) will return a 2D vector. >> >>>>>>>>>> >> >>>>>>>>>> We also have (10,20,30) which returns a 3D vector. >> >>>>>>>>>> >> >>>>>>>>>> , is used for different meanings already in the image beside >> >>>>>>>>>> the collection concatenation. For example, in FileReference is adds a file >> >>>>>>>>>> extension. And Exceptions create a collection. In other packages, >> >>>>>>>>>> PetitParser uses it as a sequence operator. >> >>>>>>>>>> >> >>>>>>>>>> Please voice your concerns. >> >>>>>>>>>> >> >>>>>>>>>> Cheers, >> >>>>>>>>>> Doru >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> -- >> >>>>>>>>>> www.tudorgirba.com >> >>>>>>>>>> www.feenk.com >> >>>>>>>>>> >> >>>>>>>>>> "Every thing should have the right to be different." >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>> >> >>>>>>> >> >>>>>> >> >>>>> >> >>>>> -- >> >>>>> www.tudorgirba.com >> >>>>> www.feenk.com >> >>>>> >> >>>>> "When people care, great things can happen." >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>> >> >>>> -- >> >>>> www.tudorgirba.com >> >>>> www.feenk.com >> >>>> >> >>>> "If you interrupt the barber while he is cutting your hair, >> >>>> you will end up with a messy haircut." >> >>> >> >>> -- >> >>> www.tudorgirba.com >> >>> www.feenk.com >> >>> >> >>> "We are all great at making mistakes." >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> >> >> > >> > -- >> > www.tudorgirba.com >> > www.feenk.com >> > >> > "If you can't say why something is relevant, >> > it probably isn't." >> > >> > >> > |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |