 |
lua-l archive |
|
|
||
|
Wesley Smith kirjoitti 2.1.2007 kello 2.40:
So here's the problem. I have wrapped some C structures with functions that can take arguments of various types. A simple example is with the matrix functions. If I call a setcell function on a uchar matrix with integer arguments, the cell will be set with the integer data clamped to the range [0, 255]. If I call the same function with float arguments, the range will be clampeed to [0, 1] with the values in this range mapping to the uchar range [0, 255]. This is pretty standard behavior and mirrors OpenGL color values in the float case.
Here, only 1 would be an issue, right? 0 maps to 0 and values [0..1-] would be converted to [0..254].
If I was doing this, I would have two functions just for the clarity of the interface (setcell_raw, setcell ?).
Now let's say I call the getcell function on a uchar matrix. If the
cell is yellow with a little bit of blue channel, one scenario is that
I get a table with values {255, 255, 255, 1} where the first value is
the alpha channel. If I then use this same table to set another cell
in the matrix, the cell will end up white because a float value of 1
is actually 255 in uchar values.
Ok.I think you should standardize the table contents. That they are always either presented as integers, as here, or floats. Is that so already?
If yes, you can take in the table into the C function, and by taking a table you would know the values are all integers. Now, I assume, you are diving into the table at Lua level?
But now that I think about it some more, the problem is more fundamental than distinguishing between 255 and 255. and I think I'm going to have to convert everything into the float range because 255. is textual and when for example the getcell function returns a table of values there is no notion of the '.' because it is not in the script text.
Right, you got it. :) Actually, the fundamental issue is Lua's treatment of all numbers alike (which, I think, is very much a virtue not a sin!) We're so used to thinking in int, short, unsigned long long in C that this simplification seems sometimes troublesome. Overall, it really is not.
Even with an integer patch, the external "all numbers are one" approach is not changed. But for what you are doing, the patch is not relevant.
So, I guess I don't have a problem with Lua but need to rethink how the bindings are done. Thanks for prodding me to think about this some more. I guess I just needed to sound off of someone.
:) Thanks to you. I'd say Lua is on a higher "enlightment level" than languages we come from. Really. I continuously find myself learning about the best ways to do things with it. Normally, they lead to _very_ short implementations, and seem obvious once there. Happy journey!
-asko
best, wes On 1/1/07, Asko Kauppi <askok@dnainternet.net> wrote:What exactly is your end goal on this, that is _why_ do you need to separate them? Token filtering won't help, since numbers have already been tokenized prior to coming to the filter. So you'll get "<number>"+X or "<string>"+Y or "for" and other tokens. If you require different behaviour, you'll probably need to do a dbl () function (s.a. dbl(255)) that would wrap the number into a userdata. I'd hate to do such in my code! But let's hear, what is your actual problem? :) -asko Wesley Smith kirjoitti 2.1.2007 kello 1.25: > Hi,> Is there a way to use token filtering in Lua to distinguish {255, 1,> 1, 255} from {255., 1., 1., 255.} in C? I'd like the former to > resolve as int and the later to resolve as floats. > > thanks, > wes