|
View:
New views
14 Messages
—
Rating Filter:
Alert me
|
|
|
When integers go badHi -
SC goes a bit strange when integers go off the scale: 1410889248 * 99; // Results in -2055885216 Is this as designed? Since it returns an Integer, it's pretty dangerous since it can continue to be used in calculations and can corrupt. Would be better if it returned inf, or perhaps even threw some kind of exception. Is that feasible? Thanks Dan _______________________________________________ Sc-devel mailing list Sc-devel@... http://lists.create.ucsb.edu/mailman/listinfo/sc-devel |
|
|
Re: When integers go badThis is standard behavior for integer arithmetic. Keeping it simple,
if you have 8 bits only: 2r01111111 == 127 +1 ---- 2r10000000 == -128 Actually, n - 1 works by addition. 5 - 1 = 5 + (-1) = 5 + (2^8 - 1) 2r00000101 + 2r11111111 = 2r00000100 or 4. I think it's more a matter of being careful, or of .asFloat'ing everything when the range might get very large. hjh On Tue, Feb 26, 2008 at 4:53 PM, Dan Stowell <danstowell@...> wrote: > Hi - > > SC goes a bit strange when integers go off the scale: > > 1410889248 * 99; // Results in -2055885216 > > Is this as designed? Since it returns an Integer, it's pretty > dangerous since it can continue to be used in calculations and can > corrupt. Would be better if it returned inf, or perhaps even threw > some kind of exception. Is that feasible? -- James Harkins /// dewdrop world jamshark70@... http://www.dewdrop-world.net "Come said the Muse, Sing me a song no poet has yet chanted, Sing me the universal." -- Whitman _______________________________________________ Sc-devel mailing list Sc-devel@... http://lists.create.ucsb.edu/mailman/listinfo/sc-devel |
|
|
Re: When integers go badHm, OK, well maybe I'm just spoilt by environments like Octave or
Matlab that give you inf when you go off the scale, which is a really useful warning that you've hit the buffers! (Maybe they use floats implicitly even for integers.) Thanks Dan 2008/2/26, James Harkins <jamshark70@...>: > This is standard behavior for integer arithmetic. Keeping it simple, > if you have 8 bits only: > > 2r01111111 == 127 > +1 > ---- > 2r10000000 == -128 > > Actually, n - 1 works by addition. 5 - 1 = 5 + (-1) = 5 + (2^8 - 1) > > 2r00000101 + 2r11111111 = 2r00000100 or 4. > > I think it's more a matter of being careful, or of .asFloat'ing > everything when the range might get very large. > hjh > > > > On Tue, Feb 26, 2008 at 4:53 PM, Dan Stowell <danstowell@...> wrote: > > Hi - > > > > SC goes a bit strange when integers go off the scale: > > > > 1410889248 * 99; // Results in -2055885216 > > > > Is this as designed? Since it returns an Integer, it's pretty > > dangerous since it can continue to be used in calculations and can > > corrupt. Would be better if it returned inf, or perhaps even threw > > some kind of exception. Is that feasible? > > > > -- > James Harkins /// dewdrop world > jamshark70@... > http://www.dewdrop-world.net > > "Come said the Muse, > Sing me a song no poet has yet chanted, > Sing me the universal." -- Whitman > _______________________________________________ > Sc-devel mailing list > Sc-devel@... > http://lists.create.ucsb.edu/mailman/listinfo/sc-devel > -- http://www.mcld.co.uk _______________________________________________ Sc-devel mailing list Sc-devel@... http://lists.create.ucsb.edu/mailman/listinfo/sc-devel |
|
|
Re: When integers go badI also think this is not optimal. I've had hard to find bugs with
integer arithmetics because of this. >Hm, OK, well maybe I'm just spoilt by environments like Octave or >Matlab that give you inf when you go off the scale, which is a really >useful warning that you've hit the buffers! (Maybe they use floats >implicitly even for integers.) > >Thanks >Dan > > >2008/2/26, James Harkins <jamshark70@...>: >> This is standard behavior for integer arithmetic. Keeping it simple, >> if you have 8 bits only: >> >> 2r01111111 == 127 >> +1 >> ---- >> 2r10000000 == -128 >> >> Actually, n - 1 works by addition. 5 - 1 = 5 + (-1) = 5 + (2^8 - 1) >> >> 2r00000101 + 2r11111111 = 2r00000100 or 4. >> >> I think it's more a matter of being careful, or of .asFloat'ing >> everything when the range might get very large. >> hjh >> >> >> >> On Tue, Feb 26, 2008 at 4:53 PM, Dan Stowell <danstowell@...> wrote: >> > Hi - >> > >> > SC goes a bit strange when integers go off the scale: >> > >> > 1410889248 * 99; // Results in -2055885216 >> > >> > Is this as designed? Since it returns an Integer, it's pretty >> > dangerous since it can continue to be used in calculations and can >> > corrupt. Would be better if it returned inf, or perhaps even threw >> > some kind of exception. Is that feasible? >> >> >> >> -- >> James Harkins /// dewdrop world >> jamshark70@... >> http://www.dewdrop-world.net >> >> "Come said the Muse, >> Sing me a song no poet has yet chanted, >> Sing me the universal." -- Whitman >> _______________________________________________ >> Sc-devel mailing list >> Sc-devel@... >> http://lists.create.ucsb.edu/mailman/listinfo/sc-devel >> > > >-- >http://www.mcld.co.uk >_______________________________________________ >Sc-devel mailing list >Sc-devel@... >http://lists.create.ucsb.edu/mailman/listinfo/sc-devel -- . _______________________________________________ Sc-devel mailing list Sc-devel@... http://lists.create.ucsb.edu/mailman/listinfo/sc-devel |
|
|
Re: When integers go badYou're free to investigate in PyrMathPrim.cpp if you like, but I think James McCartney should have the final say on a behavior change like this. Floating point numbers (IEEE 754) have, built-in, a way to encode infinity and NaN. Binary integers don't. So the primitives would have to check for an out of range result (which could be tricky -- in floating point math, the calculation result tells you if it's not a valid number, but the result of integer arithmetic is always a legitimate integer, it even if it isn't the integer you thought you were going to get). I don't have any strong objection to it. I just think it might be a trickier problem than you expect. I would have an objection if it adds too much weight to math operations and slows down performance in the language. hjh On Feb 26, 2008, at 5:40 PM, Dan Stowell wrote:
: H. James Harkins : http://www.dewdrop-world.net .::!:.:.......:.::........:..!.::.::...:..:...:.:.:.:..: "Come said the Muse, Sing me a song no poet has yet chanted, Sing me the universal." -- Whitman _______________________________________________ Sc-devel mailing list Sc-devel@... http://lists.create.ucsb.edu/mailman/listinfo/sc-devel |
|
|
Re: When integers go badThen don't use integers. You'll get the behavior you want (infinities)
and a much larger range of integers if you use Float. --- james mccartney @ iphone On Feb 26, 2008, at 2:48 PM, Julian Rohrhuber <rohrhuber@uni- hamburg.de> wrote: > I also think this is not optimal. I've had hard to find bugs with > integer arithmetics because of this. > >> Hm, OK, well maybe I'm just spoilt by environments like Octave or >> Matlab that give you inf when you go off the scale, which is a really >> useful warning that you've hit the buffers! (Maybe they use floats >> implicitly even for integers.) >> >> Thanks >> Dan >> >> >> 2008/2/26, James Harkins <jamshark70@...>: >>> This is standard behavior for integer arithmetic. Keeping it simple, >>> if you have 8 bits only: >>> >>> 2r01111111 == 127 >>> +1 >>> ---- >>> 2r10000000 == -128 >>> >>> Actually, n - 1 works by addition. 5 - 1 = 5 + (-1) = 5 + (2^8 - 1) >>> >>> 2r00000101 + 2r11111111 = 2r00000100 or 4. >>> >>> I think it's more a matter of being careful, or of .asFloat'ing >>> everything when the range might get very large. >>> hjh >>> >>> >>> >>> On Tue, Feb 26, 2008 at 4:53 PM, Dan Stowell >>> <danstowell@...> wrote: >>>> Hi - >>>> >>>> SC goes a bit strange when integers go off the scale: >>>> >>>> 1410889248 * 99; // Results in -2055885216 >>>> >>>> Is this as designed? Since it returns an Integer, it's pretty >>>> dangerous since it can continue to be used in calculations and can >>>> corrupt. Would be better if it returned inf, or perhaps even threw >>>> some kind of exception. Is that feasible? >>> >>> >>> >>> -- >>> James Harkins /// dewdrop world >>> jamshark70@... >>> http://www.dewdrop-world.net >>> >>> "Come said the Muse, >>> Sing me a song no poet has yet chanted, >>> Sing me the universal." -- Whitman >>> _______________________________________________ >>> Sc-devel mailing list >>> Sc-devel@... >>> http://lists.create.ucsb.edu/mailman/listinfo/sc-devel >>> >> >> >> -- >> http://www.mcld.co.uk >> _______________________________________________ >> Sc-devel mailing list >> Sc-devel@... >> http://lists.create.ucsb.edu/mailman/listinfo/sc-devel > > > -- > > > > > > . > _______________________________________________ > Sc-devel mailing list > Sc-devel@... > http://lists.create.ucsb.edu/mailman/listinfo/sc-devel Sc-devel mailing list Sc-devel@... http://lists.create.ucsb.edu/mailman/listinfo/sc-devel |
|
|
Re: When integers go badbefore you get infinities, you get degraded precision.
a = 3; b = 2147483647.0; b ** a ** (1/a) - b -2.6226043701172e-06 >Then don't use integers. You'll get the behavior you want (infinities) >and a much larger range of integers if you use Float. > >--- james mccartney @ iphone > >On Feb 26, 2008, at 2:48 PM, Julian Rohrhuber <rohrhuber@uni- >hamburg.de> wrote: > >> I also think this is not optimal. I've had hard to find bugs with >> integer arithmetics because of this. >> >>> Hm, OK, well maybe I'm just spoilt by environments like Octave or >>> Matlab that give you inf when you go off the scale, which is a really >>> useful warning that you've hit the buffers! (Maybe they use floats >>> implicitly even for integers.) >>> >>> Thanks >>> Dan >>> >>> >>> 2008/2/26, James Harkins <jamshark70@...>: >>>> This is standard behavior for integer arithmetic. Keeping it simple, >>>> if you have 8 bits only: >>>> >>>> 2r01111111 == 127 >>>> +1 >>>> ---- >>>> 2r10000000 == -128 >>>> >>>> Actually, n - 1 works by addition. 5 - 1 = 5 + (-1) = 5 + (2^8 - 1) >>>> >>>> 2r00000101 + 2r11111111 = 2r00000100 or 4. >>>> >>>> I think it's more a matter of being careful, or of .asFloat'ing >>>> everything when the range might get very large. >>>> hjh >>>> >>>> >>>> >>>> On Tue, Feb 26, 2008 at 4:53 PM, Dan Stowell >>>> <danstowell@...> wrote: >>>>> Hi - >>>>> >>>>> SC goes a bit strange when integers go off the scale: >>>>> >>>>> 1410889248 * 99; // Results in -2055885216 >>>>> >>>>> Is this as designed? Since it returns an Integer, it's pretty >>>>> dangerous since it can continue to be used in calculations and can >>>>> corrupt. Would be better if it returned inf, or perhaps even threw >>>>> some kind of exception. Is that feasible? >>>> >>>> >>>> >>>> -- >>>> James Harkins /// dewdrop world >>>> jamshark70@... >>>> http://www.dewdrop-world.net >>>> >>>> "Come said the Muse, >>>> Sing me a song no poet has yet chanted, >>>> Sing me the universal." -- Whitman >>>> _______________________________________________ >>>> Sc-devel mailing list >>>> Sc-devel@... >>>> http://lists.create.ucsb.edu/mailman/listinfo/sc-devel >>>> >>> >>> >>> -- >>> http://www.mcld.co.uk >>> _______________________________________________ >>> Sc-devel mailing list >>> Sc-devel@... >>> http://lists.create.ucsb.edu/mailman/listinfo/sc-devel >> >> >> -- >> >> >> >> >> >> . >> _______________________________________________ >> Sc-devel mailing list >> Sc-devel@... >> http://lists.create.ucsb.edu/mailman/listinfo/sc-devel >_______________________________________________ >Sc-devel mailing list >Sc-devel@... >http://lists.create.ucsb.edu/mailman/listinfo/sc-devel -- . _______________________________________________ Sc-devel mailing list Sc-devel@... http://lists.create.ucsb.edu/mailman/listinfo/sc-devel |
|
|
Re: When integers go badI like Ruby's solution, which is that integers get promoted to BigNums
transparently as needed: irb(main):010:0> a = 1000000000 => 1000000000 irb(main):013:0> a.class => Fixnum irb(main):011:0> b = 1000 => 1000 irb(main):014:0> b.class => Fixnum irb(main):015:0> c = a * b => 1000000000000 irb(main):016:0> c.class => Bignum irb(main):017:0> c * c => 1000000000000000000000000 I have no idea how hard this would be to implement, or what the performance implications would be. But it's nifty. -- Tim Walters | http://doubtfulpalace.com _______________________________________________ Sc-devel mailing list Sc-devel@... http://lists.create.ucsb.edu/mailman/listinfo/sc-devel |
|
|
|
|
|
|
|
|
Re: When integers go badWell that's fine, but initially I was just wondering if it was by
design or by accident, because Octave/Ruby/others insulate their integers against that weirdness. My guess would be that the CPU overhead needed for that insulation wouldn't be popular in SC, so I'm OK to live with it if that's the design. But it's interesting to discuss this topic. I don't think it's entirely fair to dismiss this thread as "bickering", I wouldn't call it that (yet). Dan 2008/2/27, James Harkins <jamshark70@...>: > My feeling is, it's well known where the math primitives live, so if > you want a difference in behavior, write the code and post a diff so > we can see if it's worth it. I don't see the value in bickering about > it further :) ... just show me some code that works. Propose > something, then we have something that's really productive to discuss. > > Sorry if this is too blunt.... not a good day at work. I shouldn't > take it out on you folks... > hjh > > On Wed, Feb 27, 2008 at 2:12 PM, Julian Rohrhuber > > <rohrhuber@...> wrote: > > > before you get infinities, you get degraded precision. > > > > a = 3; b = 2147483647.0; b ** a ** (1/a) - b > > > > -2.6226043701172e-06 > > > > > -- > > James Harkins /// dewdrop world > jamshark70@... > http://www.dewdrop-world.net > > "Come said the Muse, > Sing me a song no poet has yet chanted, > Sing me the universal." -- Whitman > _______________________________________________ > Sc-devel mailing list > Sc-devel@... > http://lists.create.ucsb.edu/mailman/listinfo/sc-devel > -- http://www.mcld.co.uk _______________________________________________ Sc-devel mailing list Sc-devel@... http://lists.create.ucsb.edu/mailman/listinfo/sc-devel |
|
|
Re: When integers go badI don't think that is appropriate for a real time language.
On Wed, Feb 27, 2008 at 11:32 AM, Tim Walters <walters@...> wrote: > I like Ruby's solution, which is that integers get promoted to BigNums > transparently as needed: > > irb(main):010:0> a = 1000000000 > => 1000000000 > irb(main):013:0> a.class > => Fixnum > irb(main):011:0> b = 1000 > => 1000 > irb(main):014:0> b.class > => Fixnum > irb(main):015:0> c = a * b > => 1000000000000 > irb(main):016:0> c.class > => Bignum > irb(main):017:0> c * c > => 1000000000000000000000000 > > I have no idea how hard this would be to implement, or what the > performance implications would be. But it's nifty. > > -- > Tim Walters | http://doubtfulpalace.com > > > > > _______________________________________________ > Sc-devel mailing list > Sc-devel@... > http://lists.create.ucsb.edu/mailman/listinfo/sc-devel > -- --- james mccartney _______________________________________________ Sc-devel mailing list Sc-devel@... http://lists.create.ucsb.edu/mailman/listinfo/sc-devel |
|
|
Re: When integers go badMy opinion now is that I should have done what Lua and puredata did
which is to leave out integers entirely. _______________________________________________ Sc-devel mailing list Sc-devel@... http://lists.create.ucsb.edu/mailman/listinfo/sc-devel |
|
|
Re: When integers go badOn Wed, Feb 27, 2008 at 6:55 PM, James McCartney <asynth@...> wrote:
> My opinion now is that I should have done what Lua and puredata did > which is to leave out integers entirely. Bitwise arithmetic is useful so I do like having integers around for that. hjh -- James Harkins /// dewdrop world jamshark70@... http://www.dewdrop-world.net "Come said the Muse, Sing me a song no poet has yet chanted, Sing me the universal." -- Whitman _______________________________________________ Sc-devel mailing list Sc-devel@... http://lists.create.ucsb.edu/mailman/listinfo/sc-devel |
| Free embeddable forum powered by Nabble | Forum Help |