Is there any reason why Pike should accept a 0*0 image objects (or n*0 or 0*n for that matter)?
I think the question you meant to ask is: Is there any reason why it *shouldn't*?
To answer your original question: I can think of some (hypothetical) situations when it would be nice, but all of them have alternative solutions of course. In theory, an empy image could be just as useful as an empty string, mapping or array.
/ Fredrik (Naranek) Hubinette (T minus 4 weeks)
Previous text:
2004-08-08 21:48: Subject: Image.Image
Is there any reason why Pike should accept a 0*0 image objects (or n*0 or 0*n for that matter)?
/ Martin Nilsson (DivX Networks)
For implementational reasons it would be good if X*Y!=0, to safely be able to do e.g. malloc(X*Y*foo);
/ Martin Nilsson (DivX Networks)
Previous text:
2004-08-08 21:54: Subject: Image.Image
I think the question you meant to ask is: Is there any reason why it *shouldn't*?
To answer your original question: I can think of some (hypothetical) situations when it would be nice, but all of them have alternative solutions of course. In theory, an empy image could be just as useful as an empty string, mapping or array.
/ Fredrik (Naranek) Hubinette (T minus 4 weeks)
Saving one line of code in the implementation is hardly a good reason for limiting the functionality of the language.
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Previous text:
2004-08-09 01:55: Subject: Image.Image
For implementational reasons it would be good if X*Y!=0, to safely be able to do e.g. malloc(X*Y*foo);
/ Martin Nilsson (DivX Networks)
No, but now most code do malloc(X*Y*foo+1), which probably isn't good when malloc works on blocks bigger than bytes. X*Y*foo tend to have a nice, round size.
/ Martin Nilsson (DivX Networks)
Previous text:
2004-08-09 11:12: Subject: Image.Image
Saving one line of code in the implementation is hardly a good reason for limiting the functionality of the language.
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Fix that then.
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Previous text:
2004-08-09 11:15: Subject: Image.Image
No, but now most code do malloc(X*Y*foo+1), which probably isn't good when malloc works on blocks bigger than bytes. X*Y*foo tend to have a nice, round size.
/ Martin Nilsson (DivX Networks)
No, ensuring non-zero size does not change the fact that malloc(X*Y*foo+1) allocates an odd size.
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Previous text:
2004-08-09 11:23: Subject: Image.Image
That is obviously what I'm trying to find the best way to do. Ensuring non-zero size on creation is one way.
/ Martin Nilsson (DivX Networks)
When the size is always non-zero (appearently not obviously) the rest of the code can be altered to benefit from that fact.
/ Martin Nilsson (DivX Networks)
Previous text:
2004-08-09 11:32: Subject: Image.Image
My bot obviously has a better ability of observing the scope of a problem than your brain.
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Yes, but since the "benefit" is marginal, and not at all needed to solve the problem, it should not be considered part of the solution. Of course, if the non-zero-requirement is deemed positive for _other_ reasons, it's ok to "benefit" from it in this context too.
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Previous text:
2004-08-09 12:01: Subject: Image.Image
When the size is always non-zero (appearently not obviously) the rest of the code can be altered to benefit from that fact.
/ Martin Nilsson (DivX Networks)
nice and round sizes is death to most mallocs, since they usually add 8 bytes overhead.
Thus, on linux allocating 65536 bytes tends to use 69632 bytes or so.
/ Per Hedbor ()
Previous text:
2004-08-09 11:15: Subject: Image.Image
No, but now most code do malloc(X*Y*foo+1), which probably isn't good when malloc works on blocks bigger than bytes. X*Y*foo tend to have a nice, round size.
/ Martin Nilsson (DivX Networks)
I would guess that nice and round sizes +1 is worse.
/ Martin Nilsson (DivX Networks)
Previous text:
2004-08-09 12:10: Subject: Image.Image
nice and round sizes is death to most mallocs, since they usually add 8 bytes overhead.
Thus, on linux allocating 65536 bytes tends to use 69632 bytes or so.
/ Per Hedbor ()
Not really, no. Since the size is usually rouded to a nice round number _after_ the addition of the malloc overhead. And no malloc I know of allocates memory with less than 8bytes alignment.
So the average wasteage is probably smallre than 1 byte.
/ Per Hedbor ()
Previous text:
2004-08-09 15:14: Subject: Image.Image
It takes a byte extra.
/ Peter Bortas (Kein Paket!)
Definately, but no waste is better rhan a little waste here and there. At least when it's fairly simple to avoid.
/ Peter Bortas (Kein Paket!)
Previous text:
2004-08-09 15:19: Subject: Image.Image
Not really, no. Since the size is usually rouded to a nice round number _after_ the addition of the malloc overhead. And no malloc I know of allocates memory with less than 8bytes alignment.
So the average wasteage is probably smallre than 1 byte.
/ Per Hedbor ()
As long as the codesize increase is not larger than the increase in memory usage. :-)
/ Per Hedbor ()
Previous text:
2004-08-09 15:21: Subject: Image.Image
Definately, but no waste is better rhan a little waste here and there. At least when it's fairly simple to avoid.
/ Peter Bortas (Kein Paket!)
foo in this case is 3, so I bet X*Y*foo+1 is about as even as often as X*Y*foo+0 in this case.
/ Mirar
Previous text:
2004-08-09 11:15: Subject: Image.Image
No, but now most code do malloc(X*Y*foo+1), which probably isn't good when malloc works on blocks bigger than bytes. X*Y*foo tend to have a nice, round size.
/ Martin Nilsson (DivX Networks)
X*Y*foo+1 is worse but more often than not ((CS-1)/CS) it doesn't matter. To remove the abaility for zero size images to make malloc easier seems wrong, but to allow zero sized images seems at least as wrong.
/ Peter Bortas (Kein Paket!)
Previous text:
2004-08-09 13:12: Subject: Image.Image
foo in this case is 3, so I bet X*Y*foo+1 is about as even as often as X*Y*foo+0 in this case.
/ Mirar
Traditinally, the only way to get a 0xY or Xx0 sized image is because of a bug in scale().
I don't think anything will break if everything starts to protest for zero-sized images.
/ Mirar
Previous text:
2004-08-08 21:48: Subject: Image.Image
Is there any reason why Pike should accept a 0*0 image objects (or n*0 or 0*n for that matter)?
/ Martin Nilsson (DivX Networks)
What about cropping, computing layer intersections etc? It would be ugly if high-level code had to add extra checks for those cases, especially when an empty image is an intermediate result in a longer sequence of operations.
/ Jonas Walldén
Previous text:
2004-08-09 13:14: Subject: Image.Image
Traditinally, the only way to get a 0xY or Xx0 sized image is because of a bug in scale().
I don't think anything will break if everything starts to protest for zero-sized images.
/ Mirar
Layer-ing (Image.lay) takes a size component:
| > Image.lay( ({}), 0,0, 0,0); | Bad argument 4 to Image.lay(). Expected int(1..).
Noone has protested against that, so far.
Image.Image->copy takes coordinates, and can't produce an image smaller then 1x1 pixels:
| > Image.Image(100,100)->copy(20,20,0,0); | (1) Result: Image.Image( 21 x 21 /* 1.3Kb */) | > Image.Image(100,100)->copy(20,20,20,20); | (2) Result: Image.Image( 1 x 1 /* 0.0Kb */)
There is no crop method.
/ Mirar
Previous text:
2004-08-10 11:47: Subject: Image.Image
What about cropping, computing layer intersections etc? It would be ugly if high-level code had to add extra checks for those cases, especially when an empty image is an intermediate result in a longer sequence of operations.
/ Jonas Walldén
Eew, even more inconsistencies! If (0,0)-(0,0) is a zero-sized image, it's not intuitive that (20,20)-(20,20) produces a 1x1 image. Also, having one API function require corner point plus size and a second two corner points is another unfortunate inconsistency.
Ideally the Image classes should have defined coordinates to identify the grid in between pixels. I guess I'm spoiled by QuickDraw which uses a well-defined model in this regard.
Noone has protested against that, so far.
Well, consider it done. :-)
/ Jonas Walldén
Previous text:
2004-08-10 11:59: Subject: Image.Image
Layer-ing (Image.lay) takes a size component:
| > Image.lay( ({}), 0,0, 0,0); | Bad argument 4 to Image.lay(). Expected int(1..).
Noone has protested against that, so far.
Image.Image->copy takes coordinates, and can't produce an image smaller then 1x1 pixels:
| > Image.Image(100,100)->copy(20,20,0,0); | (1) Result: Image.Image( 21 x 21 /* 1.3Kb */) | > Image.Image(100,100)->copy(20,20,20,20); | (2) Result: Image.Image( 1 x 1 /* 0.0Kb */)
There is no crop method.
/ Mirar
In this case I actually agree. Inclusive coordinates is a pain to work with, you always need that extra -1.
It's sort of hard to change now, though. :-)
/ Per Hedbor ()
Previous text:
2004-08-10 12:19: Subject: Image.Image
Eew, even more inconsistencies! If (0,0)-(0,0) is a zero-sized image, it's not intuitive that (20,20)-(20,20) produces a 1x1 image. Also, having one API function require corner point plus size and a second two corner points is another unfortunate inconsistency.
Ideally the Image classes should have defined coordinates to identify the grid in between pixels. I guess I'm spoiled by QuickDraw which uses a well-defined model in this regard.
Noone has protested against that, so far.
Well, consider it done. :-)
/ Jonas Walldén
But think of all the bytes we'd save by removing the -1 all over the place. :-)
(I agree it's impossible to change now.)
/ Jonas Walldén
Previous text:
2004-08-10 12:22: Subject: Image.Image
In this case I actually agree. Inclusive coordinates is a pain to work with, you always need that extra -1.
It's sort of hard to change now, though. :-)
/ Per Hedbor ()
When I wrote it I used the models that the coordinates were to pixels, 0,0 being the top left pixel - not absolute coordinates in an image, and a,b to a,b describes a 1x1 pixel image, from a,b to and inclusive a,b.
I would probably do it with a better coordinate system, today.
/ Mirar
Previous text:
2004-08-10 12:19: Subject: Image.Image
Eew, even more inconsistencies! If (0,0)-(0,0) is a zero-sized image, it's not intuitive that (20,20)-(20,20) produces a 1x1 image. Also, having one API function require corner point plus size and a second two corner points is another unfortunate inconsistency.
Ideally the Image classes should have defined coordinates to identify the grid in between pixels. I guess I'm spoiled by QuickDraw which uses a well-defined model in this regard.
Noone has protested against that, so far.
Well, consider it done. :-)
/ Jonas Walldén
pike-devel@lists.lysator.liu.se
-
Fredrik (Naranek) Hubinette (T minus 4 weeks) ＠ Pike (-) developers forum -
Jonas Walld�n ＠ Pike developers forum
-
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum
-
Martin Nilsson (DivX Networks) ＠ Pike (-) developers forum
-
Mirar ＠ Pike developers forum
-
Per Hedbor () ＠ Pike (-) developers forum
-
Peter Bortas (Kein Paket!) ＠ Pike (-) developers forum