 |
Author |
Topic: data type conversions vs. casting (Read 570 times) |
|
kevinP
|
data type conversions vs. casting
« on: Feb 22nd, 2004, 2:53pm » |
|
Hi,
Things like these:
println(600/3654);
scale(600/3654);
do not throw an error or give a warning, even though the result (zero) is illogical. I realize that the reason java complains about:
int number = floatNumber;
is not because it really cares about my precision but because its pointer needs to know how much memory to allocate, but getting these error messages causes me to then expect the same thing when I do something dumb like:
scale(intNumber/intNumber2); // i.e. 200/2654
Since there is no assignment going on, couldn't scale() and println() do automatic casting (or is this then too non-java-like)?
Recasting works:
println((float)600/3654);
but I initially thought this should, too:
println(float(600/3654));
Well, it does (you get 0.0).  Perhaps one could at least expand the Processing reference for datatype conversions to point out the difference between casting and conversion.
-K
|
| « Last Edit: Feb 22nd, 2004, 2:56pm by kevinP » |
|
Kevin Pfeiffer
|
|
|
toxi_
Guest
|
Re: data type conversions vs. casting
« Reply #1 on: Feb 22nd, 2004, 8:03pm » |
|
kevin, the whole point of having a choice of number types is that you can choose them to fit your needs. if you need to work with non-integer values, simply don't use integers in the first place! this is an easy decision for a human. what you mentioned are special cases, whereas a language needs to be build in the most general manner possible. what about all the cases when you do want an integer as result?
the reason why float(int/int) only yields a float version of the integer result is because the expression is enclosed in brackets and everything within brackets is always executed first (starting with the innermost brackets if there are nested ones), which in this case is an integer division. only the result of which will be cast into a float value.
on the other hand, a standard casting only converts the 1st expression/item immediately following the operator, which in the case of (float)int1/int2 then equals to float1/int2. a float devided by an int remains a float value. makes sense?
|
|
|
|
|
mm
Guest
|
Re: data type conversions vs. casting
« Reply #2 on: Feb 22nd, 2004, 9:30pm » |
|
yah i agree but doing it without using the asInt is nice.
|
|
|
|
|
kevinP
|
Re: data type conversions vs. casting
« Reply #3 on: Feb 22nd, 2004, 11:46pm » |
|
I guess it's just my Perl roots ("do what I mean"). But I still think that 2 /5 should at least give me a warning instead of zero.
|
Kevin Pfeiffer
|
|
|
toxi_
Guest
|
Re: data type conversions vs. casting
« Reply #4 on: Feb 23rd, 2004, 12:34am » |
|
but why a warning? 2/5 does equal 0 (with a remainder) in mathematics if you're dealing with whole numbers only. there's nothing fishy about it at all... the machine can't possibly know you want a real (fractional) number as result, if you only feed it (and declared) whole numbers.
|
|
|
|
|
fry
|
Re: data type conversions vs. casting
« Reply #5 on: Feb 23rd, 2004, 2:16am » |
|
on Feb 22nd, 2004, 11:46pm, K wrote:| I guess it's just my Perl roots ("do what I mean"). But I still think that 2 /5 should at least give me a warning instead of zero. |
|
nah, because there are perfectly legitimate times that you want to divide 5 by 2 to get 2. for instance to go from an index into a pixel array to get the row/column:
int index = 12000;
int row = 12000 / width;
int col = 12000 % width;
also, the lack of typing in perl/actionscript/python is part of the reason for the speed loss when doing math-intensive operations--p5 uses java as a reasonable intermediate for the balance of speed (c being fastest) versus learnability (python or other scripting languages being easier).
|
|
|
|
|
kevinP
|
Re: data type conversions vs. casting
« Reply #6 on: Feb 23rd, 2004, 3:21am » |
|
Okay, okay. I'm writing this all down.
|
Kevin Pfeiffer
|
|
|
amoeba
|
Re: data type conversions vs. casting
« Reply #7 on: Feb 23rd, 2004, 10:48am » |
|
besides, all you need to do is say:
println(600.0/3654.0);
scale(600.0/3654.0);
which prints 0.16420361 just fine.
|
marius watz // amoeba
http://processing.unlekker.net/
|
|
|
arielm
|
Re: data type conversions vs. casting
« Reply #8 on: Feb 23rd, 2004, 8:39pm » |
|
600.0/3654.0 may solve the problem but it's the easy case...
anxiety and haid scratching generally arrise when you use variables, e.g:
a / b --> will it give a float or an int?
no magic formula here i guess: you have to be aware of the nature of all your variables, and sometimes, the use of casting is the only solution!
|
Ariel Malka | www.chronotext.org
|
|
|
toxi_
Guest
|
Re: data type conversions vs. casting
« Reply #9 on: Feb 24th, 2004, 2:18pm » |
|
on Feb 23rd, 2004, 8:39pm, arielm wrote:| you have to be aware of the nature of all your variables |
|
this is really what it boils down to: you're the programmer (even if you're not  ) and you tell the machine what to do, not the way round... programming is like telling your idea in a more or less foreign language, but like every good story teller, you're the one responsible for keeping track of the "red thread" leading to the result/finish/happy end/disaster/crash <insert options here>...
|
|
|
|
|
|
