Re: math on widths doesn't add up (Sean Cole (Pi))
On 7/10/19 1:07 PM, Quentin Long via use-livecode wrote: One fictional contemplation of the 4th and 5th dimensions:https://johnesimpson.com/pdf/Ifth_of_oofth-waltertevis.pdf Heh. Thanks, Quentin. Walter Tevis' first published story! -- Mark Wieder ahsoftw...@gmail.com ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: math on widths doesn't add up (Sean Cole (Pi))
Wonderful! [Massive-grin]. That pleases me a lot. Thank you for sharing it. :D Sean Cole Pi Digital Prod Ltd > On 11 Jul 2019, at 16:17, Bob Sneidar via use-livecode > wrote: > > Great story! > > Bob S > > >> On Jul 10, 2019, at 13:07 , Quentin Long via use-livecode >> wrote: >> >> sez Sean Cole (Pi):>I've just been teaching my youngest about the 4th - nth >> dimensions. Time is >>> not the 4th but the 1st temporal dimension. If the 3 spatial dimensions are >>> Length, height and width then the 4th is depth, ie, going inwards and >>> outwards as the easiest way to picture it (but not truly representative). >>> That being the case, how would you describe the 5th spacial dimension. >>> That'll twist your noggin if it's not something you've thought of before :) >> One fictional contemplation of the 4th and 5th >> dimensions:https://johnesimpson.com/pdf/Ifth_of_oofth-waltertevis.pdf >> ___ > > > ___ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your subscription > preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: math on widths doesn't add up (Sean Cole (Pi))
Great story! Bob S > On Jul 10, 2019, at 13:07 , Quentin Long via use-livecode > wrote: > > sez Sean Cole (Pi):>I've just been teaching my youngest about the 4th - nth > dimensions. Time is >> not the 4th but the 1st temporal dimension. If the 3 spatial dimensions are >> Length, height and width then the 4th is depth, ie, going inwards and >> outwards as the easiest way to picture it (but not truly representative). >> That being the case, how would you describe the 5th spacial dimension. >> That'll twist your noggin if it's not something you've thought of before :) > One fictional contemplation of the 4th and 5th > dimensions:https://johnesimpson.com/pdf/Ifth_of_oofth-waltertevis.pdf > ___ ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: math on widths doesn't add up (Sean Cole (Pi))
sez Sean Cole (Pi):>I've just been teaching my youngest about the 4th - nth dimensions. Time is >not the 4th but the 1st temporal dimension. If the 3 spatial dimensions are >Length, height and width then the 4th is depth, ie, going inwards and >outwards as the easiest way to picture it (but not truly representative). >That being the case, how would you describe the 5th spacial dimension. >That'll twist your noggin if it's not something you've thought of before :) One fictional contemplation of the 4th and 5th dimensions:https://johnesimpson.com/pdf/Ifth_of_oofth-waltertevis.pdf ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: math on widths doesn't add up
Perhaps warmth, strength, wealth, breadth, greenth. Maybe forth, growth, faith, health. > On Jul 7, 2019, at 4:07 PM, Sean Cole (Pi) via use-livecode > wrote: > > I've just been teaching my youngest about the 4th - nth dimensions. Time is > not the 4th but the 1st temporal dimension. If the 3 spatial dimensions are > Length, height and width then the 4th is depth, ie, going inwards and > outwards as the easiest way to picture it (but not truly representative). > That being the case, how would you describe the 5th spacial dimension. > That'll twist your noggin if it's not something you've thought of before :) > > Sean > > > On Mon, 17 Jun 2019 at 21:55, Bob Sneidar via use-livecode < > use-livecode@lists.runrev.com> wrote: > >> Heh! That reminds me, I knew a British professor once who used the >> illustration that a two dimensional being, confronted with a line would >> perceive it as impassible. He then went on to explain how it might be that >> a 3 dimensional being, when needing to see into the future might perceive >> it as impossible, whereas to a 4th dimensional being, that is not bound by >> time, would not. >> >> Bob S >> >> >>> On Jun 17, 2019, at 13:24 , Dar Scott Consulting via use-livecode < >> use-livecode@lists.runrev.com> wrote: >>> >>> Sure. I do it all the time and everybody knows how 1D I am. >>> >>> Some random thoughts: >>> >>> A Turing machine might be considered 1D. It can draw x,y. >>> >>> This past month, I was working in very high dimensions. I was not able >> to visualize that very well and used dimension reduction techniques such as >> PCA, UMAP and t-SNE to help. I would guess the 1D being might have to do >> something similar for "visualization". Maybe. >>> >>> Lewis and Clark went on a path or route, 1D, and took measurements that >> allowed them to create a 2D map. That is, the space of the 1D path was >> assumed to bend in a 2D space. >>> >>> The floor of my lab looks 2D to me, but I have latitude and longitude >> marked for the center. That labelling assumes a curving into 3D. >> >> >> ___ >> use-livecode mailing list >> use-livecode@lists.runrev.com >> Please visit this url to subscribe, unsubscribe and manage your >> subscription preferences: >> http://lists.runrev.com/mailman/listinfo/use-livecode >> > ___ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your subscription > preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: math on widths doesn't add up
What my cat looks for. On Sun, Jul 7, 2019 at 15:08 Sean Cole (Pi) via use-livecode < use-livecode@lists.runrev.com> wrote: > I've just been teaching my youngest about the 4th - nth dimensions. Time is > not the 4th but the 1st temporal dimension. If the 3 spatial dimensions are > Length, height and width then the 4th is depth, ie, going inwards and > outwards as the easiest way to picture it (but not truly representative). > That being the case, how would you describe the 5th spacial dimension. > That'll twist your noggin if it's not something you've thought of before :) > > Sean > > > On Mon, 17 Jun 2019 at 21:55, Bob Sneidar via use-livecode < > use-livecode@lists.runrev.com> wrote: > > > Heh! That reminds me, I knew a British professor once who used the > > illustration that a two dimensional being, confronted with a line would > > perceive it as impassible. He then went on to explain how it might be > that > > a 3 dimensional being, when needing to see into the future might perceive > > it as impossible, whereas to a 4th dimensional being, that is not bound > by > > time, would not. > > > > Bob S > > > > > > > On Jun 17, 2019, at 13:24 , Dar Scott Consulting via use-livecode < > > use-livecode@lists.runrev.com> wrote: > > > > > > Sure. I do it all the time and everybody knows how 1D I am. > > > > > > Some random thoughts: > > > > > > A Turing machine might be considered 1D. It can draw x,y. > > > > > > This past month, I was working in very high dimensions. I was not able > > to visualize that very well and used dimension reduction techniques such > as > > PCA, UMAP and t-SNE to help. I would guess the 1D being might have to do > > something similar for "visualization". Maybe. > > > > > > Lewis and Clark went on a path or route, 1D, and took measurements that > > allowed them to create a 2D map. That is, the space of the 1D path was > > assumed to bend in a 2D space. > > > > > > The floor of my lab looks 2D to me, but I have latitude and longitude > > marked for the center. That labelling assumes a curving into 3D. > > > > > > ___ > > use-livecode mailing list > > use-livecode@lists.runrev.com > > Please visit this url to subscribe, unsubscribe and manage your > > subscription preferences: > > http://lists.runrev.com/mailman/listinfo/use-livecode > > > ___ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your > subscription preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode > -- -- Stephen Barncard - Sebastopol Ca. USA - mixstream.org ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: math on widths doesn't add up
I've just been teaching my youngest about the 4th - nth dimensions. Time is not the 4th but the 1st temporal dimension. If the 3 spatial dimensions are Length, height and width then the 4th is depth, ie, going inwards and outwards as the easiest way to picture it (but not truly representative). That being the case, how would you describe the 5th spacial dimension. That'll twist your noggin if it's not something you've thought of before :) Sean On Mon, 17 Jun 2019 at 21:55, Bob Sneidar via use-livecode < use-livecode@lists.runrev.com> wrote: > Heh! That reminds me, I knew a British professor once who used the > illustration that a two dimensional being, confronted with a line would > perceive it as impassible. He then went on to explain how it might be that > a 3 dimensional being, when needing to see into the future might perceive > it as impossible, whereas to a 4th dimensional being, that is not bound by > time, would not. > > Bob S > > > > On Jun 17, 2019, at 13:24 , Dar Scott Consulting via use-livecode < > use-livecode@lists.runrev.com> wrote: > > > > Sure. I do it all the time and everybody knows how 1D I am. > > > > Some random thoughts: > > > > A Turing machine might be considered 1D. It can draw x,y. > > > > This past month, I was working in very high dimensions. I was not able > to visualize that very well and used dimension reduction techniques such as > PCA, UMAP and t-SNE to help. I would guess the 1D being might have to do > something similar for "visualization". Maybe. > > > > Lewis and Clark went on a path or route, 1D, and took measurements that > allowed them to create a 2D map. That is, the space of the 1D path was > assumed to bend in a 2D space. > > > > The floor of my lab looks 2D to me, but I have latitude and longitude > marked for the center. That labelling assumes a curving into 3D. > > > ___ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your > subscription preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode > ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: math on widths doesn't add up
Heh! That reminds me, I knew a British professor once who used the illustration that a two dimensional being, confronted with a line would perceive it as impassible. He then went on to explain how it might be that a 3 dimensional being, when needing to see into the future might perceive it as impossible, whereas to a 4th dimensional being, that is not bound by time, would not. Bob S > On Jun 17, 2019, at 13:24 , Dar Scott Consulting via use-livecode > wrote: > > Sure. I do it all the time and everybody knows how 1D I am. > > Some random thoughts: > > A Turing machine might be considered 1D. It can draw x,y. > > This past month, I was working in very high dimensions. I was not able to > visualize that very well and used dimension reduction techniques such as PCA, > UMAP and t-SNE to help. I would guess the 1D being might have to do something > similar for "visualization". Maybe. > > Lewis and Clark went on a path or route, 1D, and took measurements that > allowed them to create a 2D map. That is, the space of the 1D path was > assumed to bend in a 2D space. > > The floor of my lab looks 2D to me, but I have latitude and longitude marked > for the center. That labelling assumes a curving into 3D. ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: math on widths doesn't add up
Sure. I do it all the time and everybody knows how 1D I am. Some random thoughts: A Turing machine might be considered 1D. It can draw x,y. This past month, I was working in very high dimensions. I was not able to visualize that very well and used dimension reduction techniques such as PCA, UMAP and t-SNE to help. I would guess the 1D being might have to do something similar for "visualization". Maybe. Lewis and Clark went on a path or route, 1D, and took measurements that allowed them to create a 2D map. That is, the space of the 1D path was assumed to bend in a 2D space. The floor of my lab looks 2D to me, but I have latitude and longitude marked for the center. That labelling assumes a curving into 3D. > On Jun 17, 2019, at 10:31 AM, Bob Sneidar via use-livecode > wrote: > > Hmmm... I wonder if theoretically a one dimensional being could draw x,y. > > Bob S > > >> On Jun 14, 2019, at 14:54 , hh via use-livecode >> wrote: >> >> @Dar. >> >> Probably you wish with your post avoid the confusion between >> >> = a math-point (x,y) which has no dimension, so cannot be drawn and > > > ___ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your subscription > preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: math on widths doesn't add up
Hmmm... I wonder if theoretically a one dimensional being could draw x,y. Bob S > On Jun 14, 2019, at 14:54 , hh via use-livecode > wrote: > > @Dar. > > Probably you wish with your post avoid the confusion between > > = a math-point (x,y) which has no dimension, so cannot be drawn and ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: math on widths doesn't add up
[Sorry, confused notation. The last part of my previous post should read:] This is certainly in general a clear method for counting/ identifying pixels. For example: The rect (x1,y1,x2,y2) with x1 I wrote: > "Use center pixel coordinates" does probably mean you use the math-loc > of a pixel as model? For example (always assume a linewidth of 1): > > LC point (0,0) = rect (0,0,1,1) = first pixel has a math-loc of (0.5,0.5). > One imagines the pixel pinned up at its math-loc/center. > [I use the notation "math-loc" to avoid confusion with the rounded LC-loc.] > > This is certainly in general a clear method for counting/ identifying > pixels. For example: > > The rect (x1,y1,x2,y2) with x1 > The topleft pixel (x1,x2,x1+1,x2+1) = LC-point (x1,x2) is > math-located at (x1+0.5,x2+0.5) and > the bottomright pixel (x1-1,y2-1,x2,y2) = LC-point (x1-1,x2-1) is > math-located at (x2-0.5,y2-0.5). > > The topleft of the first pixel is the math-point (x1,y1), > the bottomright of the last pixel is the math-point (x2,y2). ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: math on widths doesn't add up
> Ralph D. wrote: > You don't need sub-pixels per say but you need to know they exist. > I found that out real quick when writing the color gradient math for > CGI. If I did not use center pixel coordinates the gradients were > "jaggy" so to speak. "Use center pixel coordinates" does probably mean you use the math-loc of a pixel as model? For example (always assume a linewidth of 1): LC point (0,0) = rect (0,0,1,1) = first pixel has a math-loc of (0.5,0.5). One imagines the pixel pinned up at its math-loc/center. [I use the notation "math-loc" to avoid confusion with the rounded LC-loc.] This is certainly in general a clear method for counting/ identifying pixels. For example: The rect (x1,y1,x2,y2) with x1http://lists.runrev.com/mailman/listinfo/use-livecode
RE: math on widths doesn't add up
You don't need sub-pixels per say but you need to know they exist. I found that out real quick when writing the color gradient math for CGI. If I did not use center pixel coordinates the gradients were "jaggy" so to speak. Ralph DiMola IT Director Evergreen Information Services rdim...@evergreeninfo.net -Original Message- From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On Behalf Of hh via use-livecode Sent: Friday, June 14, 2019 7:01 PM To: use-livecode@lists.runrev.com Cc: hh Subject: Re: math on widths doesn't add up @Dar. Could we agree that in LC Script we cannot draw subpixels? (I would like to...) And yes, you are right with the invariance of width and height. The number of pixels isn't dependent of how I enumerate them. Sorry. > I don't understand why you say "pixel 1". OK. I should say pixel 1 (one-based counting). Zero-based counting certainly has also some advantages. ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: math on widths doesn't add up
Sure, I'll agree (SVG notwithstanding). > On Jun 14, 2019, at 5:01 PM, hh via use-livecode > wrote: > > @Dar. > Could we agree that in LC Script we cannot draw subpixels? (I would like > to...) > > And yes, you are right with the invariance of width and height. The number of > pixels > isn't dependent of how I enumerate them. Sorry. > >> I don't understand why you say "pixel 1". > > OK. I should say pixel 1 (one-based counting). > Zero-based counting certainly has also some advantages. > > > ___ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your subscription > preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: math on widths doesn't add up
@Dar. Could we agree that in LC Script we cannot draw subpixels? (I would like to...) And yes, you are right with the invariance of width and height. The number of pixels isn't dependent of how I enumerate them. Sorry. > I don't understand why you say "pixel 1". OK. I should say pixel 1 (one-based counting). Zero-based counting certainly has also some advantages. ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: math on widths doesn't add up
For some reason the message below was delayed a while and thus is out of order. Looking back, I see hh has been mentioning things like first pixel and counting pixels. This might be where there is confusion. I was referring to pixels by the LiveCode reference. > On Jun 14, 2019, at 4:13 PM, Dar Scott Consulting via use-livecode > wrote: > > When we apply math, we must map what we see to our mathematical models. What > we see is LiveCode. The application of math is thus an interpretation. (The > interpretation of calendar year or how-old-are-you might not apply.) > > I do agree with you, except for the part that one has to redefine width and > height. A delta does not depend on the offset. > > If I create a line from 0,0 to 100,0; I get a line visible on the card, not a > line just off the card. The LiveCode line is between the coordinates we are > talking about, that is, a half pixel moved in from those, creating pixel > coordinates off from what we are saying. > > I can get the same thing with a rectangle of rect 0, 0, 101, 1. Well, if the > border width is zero and the fill color is set. This uses the coordinates we > are talking about. The rectangle is filled. > > The one-pixel width of the line causes it to fill that space. If there is a > 1-pixel square as a brush and it went from 0.5 to 100.5, it would sweep out > the same space as the rectangle > > However, others might have a view, an interpretation, that also works. > > > >> On Jun 14, 2019, at 3:04 PM, hh via use-livecode >> wrote: >> >> This is interestingly the same problem that made a lot of people believe >> two thousand years were full at the end of 1999/ beginning of 2000. >> Two thousand years were full at the END of 2000/ beginning of 2001: >> >> Full year 1 has the left 0, the right 1 and the width = right-left = 1 year, >> ..., >> full years 1 to 2000 have the left 0, the right 2000 and the width = >> right-left = 2000 years. >> >>> Dar S. wrote: >>> I like this interpretation. I don't think it is a popular view, but it >>> makes sense to me. >>> I would change the range wording, though, to something like this: >>> Pixel 0 ranges from 0 to 1. >>> For example, the rect of a card has zeros. >>> Maybe it depends on whether one wants to draw pixels on the intersections >>> of the lines >>> on the graph paper, or in between. >> >> No, this is math, not an interpretation. If you agree that counting pixels >> is one-based >> then there is no pixel 0. >> >> Rect (0,0,0,0) has left 0, right 0, top 0, bottom 0, width 0 and height 0, >> contains 0 pixels. >> In fact it is degenerated to the point (0,0). >> >> Rect (0,0,1,1) is one pixel, the first pixel on your coordinate system. >> It has left 0, right 1, top 0, bottom 1 and width 1, height 1. >> >> The width of a rect is the number of its pixel columns, >> the height of a rect is the number of its pixel rows, >> width*height of a rect is the number of its enclosed pixels. >> >> If you wisth to count zero-based the you have to redefine width and height. >> ___ >> use-livecode mailing list >> use-livecode@lists.runrev.com >> Please visit this url to subscribe, unsubscribe and manage your subscription >> preferences: >> http://lists.runrev.com/mailman/listinfo/use-livecode > > > ___ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your subscription > preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: math on widths doesn't add up
When we apply math, we must map what we see to our mathematical models. What we see is LiveCode. The application of math is thus an interpretation. (The interpretation of calendar year or how-old-are-you might not apply.) I do agree with you, except for the part that one has to redefine width and height. A delta does not depend on the offset. If I create a line from 0,0 to 100,0; I get a line visible on the card, not a line just off the card. The LiveCode line is between the coordinates we are talking about, that is, a half pixel moved in from those, creating pixel coordinates off from what we are saying. I can get the same thing with a rectangle of rect 0, 0, 101, 1. Well, if the border width is zero and the fill color is set. This uses the coordinates we are talking about. The rectangle is filled. The one-pixel width of the line causes it to fill that space. If there is a 1-pixel square as a brush and it went from 0.5 to 100.5, it would sweep out the same space as the rectangle However, others might have a view, an interpretation, that also works. > On Jun 14, 2019, at 3:04 PM, hh via use-livecode > wrote: > > This is interestingly the same problem that made a lot of people believe > two thousand years were full at the end of 1999/ beginning of 2000. > Two thousand years were full at the END of 2000/ beginning of 2001: > > Full year 1 has the left 0, the right 1 and the width = right-left = 1 year, > ..., > full years 1 to 2000 have the left 0, the right 2000 and the width = > right-left = 2000 years. > >> Dar S. wrote: >> I like this interpretation. I don't think it is a popular view, but it makes >> sense to me. >> I would change the range wording, though, to something like this: >> Pixel 0 ranges from 0 to 1. >> For example, the rect of a card has zeros. >> Maybe it depends on whether one wants to draw pixels on the intersections of >> the lines >> on the graph paper, or in between. > > No, this is math, not an interpretation. If you agree that counting pixels is > one-based > then there is no pixel 0. > > Rect (0,0,0,0) has left 0, right 0, top 0, bottom 0, width 0 and height 0, > contains 0 pixels. > In fact it is degenerated to the point (0,0). > > Rect (0,0,1,1) is one pixel, the first pixel on your coordinate system. > It has left 0, right 1, top 0, bottom 1 and width 1, height 1. > > The width of a rect is the number of its pixel columns, > the height of a rect is the number of its pixel rows, > width*height of a rect is the number of its enclosed pixels. > > If you wisth to count zero-based the you have to redefine width and height. > ___ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your subscription > preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: math on widths doesn't add up
I tried to avoid the confusion by using the word pixel. I goofed somewhere. I don't understand why you say "pixel 1". Other that that, I think we are saying the same thing. > On Jun 14, 2019, at 3:54 PM, hh via use-livecode > wrote: > > @Dar. > > Probably you wish with your post avoid the confusion between > > = a math-point (x,y) which has no dimension, so cannot be drawn and > > = a LC-point (x,y) which is (with a linewidth of 1) in fact a > shorthand for the rect (x,y,x+1,y+1)= 1 pixel, which can be drawn. > > So the LC-point (x,y) is (with a linewidth of 1) the pixel in column x+1 > and row y+1 of your screen/ coordinate system which has the rect > (x,y,x+1,y+1). > > Rows and Columns count here one-based, so for example (with a linewidth of 1) > LC-Point (0,0) = rect (0,0,1,1) = pixel 1 of your coordinate system. > ___ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your subscription > preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: math on widths doesn't add up
When we apply math, we must map what we see to our mathematical models. What we see is LiveCode. The application of math is thus an interpretation. (The interpretation of calendar year or how-old-are-you might not apply.) I do agree with you, except for the part that one has to redefine width and height. A delta does not depend on the offset. If I create a line from 0,0 to 100,0; I get a line visible on the card, not a line just off the card. The LiveCode line is between the coordinates we are talking about, that is, a half pixel moved in from those, creating pixel coordinates off from what we are saying. I can get the same thing with a rectangle of rect 0, 0, 101, 1. Well, if the border width is zero and the fill color is set. This uses the coordinates we are talking about. The rectangle is filled. The one-pixel width of the line causes it to fill that space. If there is a 1-pixel square as a brush and it went from 0.5 to 100.5, it would sweep out the same space as the rectangle However, others might have a view, an interpretation, that also works. > On Jun 14, 2019, at 3:04 PM, hh via use-livecode > wrote: > > This is interestingly the same problem that made a lot of people believe > two thousand years were full at the end of 1999/ beginning of 2000. > Two thousand years were full at the END of 2000/ beginning of 2001: > > Full year 1 has the left 0, the right 1 and the width = right-left = 1 year, > ..., > full years 1 to 2000 have the left 0, the right 2000 and the width = > right-left = 2000 years. > >> Dar S. wrote: >> I like this interpretation. I don't think it is a popular view, but it makes >> sense to me. >> I would change the range wording, though, to something like this: >> Pixel 0 ranges from 0 to 1. >> For example, the rect of a card has zeros. >> Maybe it depends on whether one wants to draw pixels on the intersections of >> the lines >> on the graph paper, or in between. > > No, this is math, not an interpretation. If you agree that counting pixels is > one-based > then there is no pixel 0. > > Rect (0,0,0,0) has left 0, right 0, top 0, bottom 0, width 0 and height 0, > contains 0 pixels. > In fact it is degenerated to the point (0,0). > > Rect (0,0,1,1) is one pixel, the first pixel on your coordinate system. > It has left 0, right 1, top 0, bottom 1 and width 1, height 1. > > The width of a rect is the number of its pixel columns, > the height of a rect is the number of its pixel rows, > width*height of a rect is the number of its enclosed pixels. > > If you wisth to count zero-based the you have to redefine width and height. > ___ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your subscription > preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: math on widths doesn't add up
@Dar. Probably you wish with your post avoid the confusion between = a math-point (x,y) which has no dimension, so cannot be drawn and = a LC-point (x,y) which is (with a linewidth of 1) in fact a shorthand for the rect (x,y,x+1,y+1)= 1 pixel, which can be drawn. So the LC-point (x,y) is (with a linewidth of 1) the pixel in column x+1 and row y+1 of your screen/ coordinate system which has the rect (x,y,x+1,y+1). Rows and Columns count here one-based, so for example (with a linewidth of 1) LC-Point (0,0) = rect (0,0,1,1) = pixel 1 of your coordinate system. ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: math on widths doesn't add up
This is interestingly the same problem that made a lot of people believe two thousand years were full at the end of 1999/ beginning of 2000. Two thousand years were full at the END of 2000/ beginning of 2001: Full year 1 has the left 0, the right 1 and the width = right-left = 1 year, ..., full years 1 to 2000 have the left 0, the right 2000 and the width = right-left = 2000 years. > Dar S. wrote: > I like this interpretation. I don't think it is a popular view, but it makes > sense to me. > I would change the range wording, though, to something like this: > Pixel 0 ranges from 0 to 1. > For example, the rect of a card has zeros. > Maybe it depends on whether one wants to draw pixels on the intersections of > the lines > on the graph paper, or in between. No, this is math, not an interpretation. If you agree that counting pixels is one-based then there is no pixel 0. Rect (0,0,0,0) has left 0, right 0, top 0, bottom 0, width 0 and height 0, contains 0 pixels. In fact it is degenerated to the point (0,0). Rect (0,0,1,1) is one pixel, the first pixel on your coordinate system. It has left 0, right 1, top 0, bottom 1 and width 1, height 1. The width of a rect is the number of its pixel columns, the height of a rect is the number of its pixel rows, width*height of a rect is the number of its enclosed pixels. If you wisth to count zero-based the you have to redefine width and height. ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: math on widths doesn't add up
I like this interpretation. I don't think it is a popular view, but it makes sense to me. I would change the range wording, though, to something like this: Pixel 0 ranges from 0 to 1. For example, the rect of a card has zeros. Maybe it depends on whether one wants to draw pixels on the intersections of the lines on the graph paper, or in between. > On Jun 14, 2019, at 1:55 PM, hh via use-livecode > wrote: > > Nothing is wrong: > If you have a row then left is the integer left of first pixel > and right is the integer right of last pixel. > > So left and right are the integers that limit the object, NOT pixel numbers. > > As to your example: > pixel 1 ranges from 0 to 1, ... pixel 12 ranges from 11 to 12. > The left is 0, the right is 12, the width is 12=right-left. > >> Richard H. wrote: >> Playing around with a couple of things needing alignment, I’ve noticed that >> the math on widths and edges isn’t quite right. >> For example, I have a boundary rect of width 12, with a left of 0 and a >> right of 12. >> One of these is wrong . . . a width of 12 would go from 0 to 11; 0 to 12 is >> 13 pixels wide . . . >> It seems that “right” actually means, “the pixel to the right of” . . . > > > ___ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your subscription > preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode > ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: math on widths doesn't add up
Nothing is wrong: If you have a row then left is the integer left of first pixel and right is the integer right of last pixel. So left and right are the integers that limit the object, NOT pixel numbers. As to your example: pixel 1 ranges from 0 to 1, ... pixel 12 ranges from 11 to 12. The left is 0, the right is 12, the width is 12=right-left. > Richard H. wrote: > Playing around with a couple of things needing alignment, I’ve noticed that > the math on widths and edges isn’t quite right. > For example, I have a boundary rect of width 12, with a left of 0 and a right > of 12. > One of these is wrong . . . a width of 12 would go from 0 to 11; 0 to 12 is > 13 pixels wide . . . > It seems that “right” actually means, “the pixel to the right of” . . . ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
math on widths doesn't add up
Playing around with a couple of things needing alignment, I’ve noticed that the math on widths and edges isn’t quite right. For example, I have a boundary rect of width 12, with a left of 0 and a right of 12. One of these is wrong . . . a width of 12 would go from 0 to 11; 0 to 12 is 13 pixels wide . . . It seems that “right” actually means, “the pixel to the right of” . . . — Richard E. Hawkins, Esq. The Hawkins Law Firm 3430 E. Flamingo Rd. Suite 232 Las Vegas, NV 89121 (702) 508-8462 ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
