 Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me. |
Forum Index : Microcontroller and PC projects : Maximite color: found little bug
| Author | Message | ||||
Juri74 Senior Member  Joined: 06/02/2012 Location: ItalyPosts: 162 |
hello! i think i found a bug in v4.3 try this code: print hex$(16777212)
FFFFFC print hex$(16777213) FFFFFE print hex$(16777214) FFFFFE print hex$(16777215) 1000000 print hex$(16777216) 1000000 and so on.... please could be fixed in the next firmware release? thanks  |
||||
| aargee Senior Member Joined: 21/08/2008 Location: AustraliaPosts: 255 |
As well as posting here you might want to send Geoff an email directly at: projects@geoffg.net - Rob. For crying out loud, all I wanted to do was flash this blasted LED. |
||||
CircuitGizmos Guru  Joined: 08/09/2011 Location: United StatesPosts: 1425 |
You are at the limit of the way a number is represented. Not in hex it looks like this: print 16777212 print 16777213 print 16777214 print 16777215 print 16777216 > run 1.67772e+07 1.67772e+07 1.67772e+07 1.67772e+07 1.67772e+07 > From the manual: The range of integers (whole numbers) that can be manipulated without loss of accuracy is ±16777100. Micromites and Maximites! - Beginning Maximite |
||||
| shoebuckle Senior Member Joined: 21/01/2012 Location: AustraliaPosts: 189 |
However if you write it as Print Format$(16777212,"%8.0f") Print Format$(16777213,"%8.0f") Print Format$(16777214,"%8.0f") Print Format$(16777215,"%8.0f") you get 16777212 16777213 16777214 16777215 @geoffg Incidentally I just checked the Hex to numeric conversion and we get a similar problem in v4.3. Hex FFFFFD is converted incorrectly. Print Format$(Val(&HFFFFFC"),"%8.0f") Print Format$(Val(&HFFFFFD"),"%8.0f") Print Format$(Val(&HFFFFFE"),"%8.0f") Print Format$(Val(&HFFFFFF"),"%8.0f") Gives 16777212 16777214 16777214 16777216 Cheers, Hugh |
||||
| Juri74 Senior Member Joined: 06/02/2012 Location: ItalyPosts: 162 |
i read that in the manual, and it looked very strange.. i tough that the numeric accuracy would cover the entire 24 bit range... too bad, i've to rethink entirely my next app... thank you all |
||||
Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3194 |
This is not a bug, it is the inherent inaccuracy when you try to store too large an integer in a floating point number. Use a smaller number and there will not be an error. Geoff Graham - http://geoffg.net |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 3802 |
It's what I'd call a bug. For IEEE754 binary32 (old name single-precision), Hex FFFFFD ought to end up as the 4 hex bytes (little endian) FD FF 7F 4B so that sign bit is zero, exponent 23 and so on. It should then print properly, too, i.e. as 16777213. Similarly, Hex FFFFFF ought to work and be 16777215 (again, internally exponent 23). I can't tell from what's reported whether VAL doesn't quite work or FORMAT$ doesn't (possibly both). Unless I've missed something. Now... it's hard to get these worst-case values right and the doc says what's allowed, so in a way it's not a bug... John |
||||
| shoebuckle Senior Member Joined: 21/01/2012 Location: AustraliaPosts: 189 |
Fair enough. I hadn't thought of that. Hugh |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 3802 |
Except it's wrong. John |
||||
MicroBlocks Guru Joined: 12/05/2012 Location: ThailandPosts: 2209 |
I would 'vote' for an overflow error as it is an error condition. It is an artifact of using a float to represent an integer. by range checking this error can be trapped. Microblocks. Build with logic. |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 3802 |
There's no overflow in the values I posted about. John |
||||
 Print this page |
