Defining a float array
BlitzMax Forums/BlitzMax Programming/Defining a float array
| ||
This throws an error:Local poly:float = [0, -50, 50, 0, 0, 0] This works, but is ugly: Local poly:float = [0.0, -50.0, 50.0, 0.0, 0.0, 0.0] DrawPoly complains if I instead use an Int array. Is there any other way of doing this that means I don't have to explicitly tell it that each individual value is a float? |
| ||
| I think you do have to make each number a float, which has always annoyed me. It's especially silly because you can't mix numeric types, like [ 5.0, 10 ]. If they all have to be the same why not just use the first one to determine the type? Luckily search and replace will handle most of this. Start with the integer array and replace "," with ".0,". |
| ||
| Hm... that's what I thought. Though I guess in the real world I'd be loading the vertices from an external source anyway and casting them to floats as they arrive, so, probably no biggie. |
| ||
You can also do:Local poly#[] = [0#, -50#, 50#, 0#, 0#, 0#] |
| ||
| Well, it's a bit more readable! |
| ||
| If you could pass Ints to a Float array, (Which is a reasonable thing to ask for), would there not be a auto cast overhead? If so, is it not better the need to be explicit? |
| ||
| This isn't something you'd really do on-the-fly. |
| ||
| Depends on what you need it for, but if its just for DrawPoly calls id consider rewriting the module code to have it accept int arrays instead. |
| ||
| Nah, it's really not worth the hassle - just wondered if there was a way of going "look, all these elements? They're ALL floats"! |
| ||
| @need to be explicit? Why should it? you can translate ints to floats without losing data. As this does not work yet (@ Brucey, same for NG) You either manually cast your numbers to the correct format or you use something like a wrapper SuperStrict local floatArray:Float[] = IntToFloatArray([1,2,3,4,5]) Function IntToFloatArray:Float[](intArray:Int[]) local res:Float[] For local i:int = eachin intArray res :+ [float(i)] Next return res End Function bye Ron |
| ||
| Its not data I was worried about, but CPU time, overhead cost in terms of work. Look at the code you posted, that entire function is overhead you avoid simply by being being Exact in data type. That is not to say you code is in anyway incorrect, just that it shouldn't be the default mechanic. |
| ||
| just that it shouldn't be the default mechanic. I agree with yourself here with respect to integers and floats, but then aren't we getting into the realms of 'type inference'? In which case the rest of the language would need adhere to the type inference model? |
| ||
| In the case of statically prefilled arrays such things could happen during compilation-time ("optimizing"). @Overhead I know that my function is pure overhead - was just another option if you want to have "more clear" statements (1 function(...) instead of cast(x),cast(y),...). That CPU time is saved when getting rid of type checks is ok ... but as other also often used things (assignments like "local i:float = integerVariable") allow this things ... it is more of a "missing feature" than an "optimization thing". bye Ron |
   |