1. pretty_print bug
- Posted by Brian Broker <bkb at cnw.com> Jun 25, 2004
- 471 views
include misc.e constant n = {536870912,4294934783,3735928559,2164260736,1073741824,1073741823} printf(1,"{%x,%x,%x,%x,%x,%x}\n",n) pretty_print(1, n, {0,2,1,78,"%x"} )
Output: {20000000,FFFF80FF,DEADBEEF,80FFFF80,40000000,3FFFFFFF} {20000000,4294934783,3735928559,2164260736,1073741824,3FFFFFFF}
2. Re: pretty_print bug
- Posted by Al Getz <Xaxo at aol.com> Jun 26, 2004
- 468 views
Hello, It appears that Misc.e confuses a Euphoria integer with an actual whole number, something that is a bit of an annoyance One way around this is to do 'something' like this: around line 110 in misc.e... in function rPrint(object a)... replace:
if integer(a) then sbuff = sprintf(pretty_int_format, a)
with:
if a-floor(a)=0 and -#FFFFFFFF<=a and a<=#FFFFFFFF then sbuff = sprintf(pretty_int_format, a)
I'll have to do something like that in my "pretty_sequence" include file also and resubmit it to RDS. It's good that you found this problem! Take care, Al And, good luck with your Euphoria programming! My bumper sticker: "I brake for LED's"
3. Re: pretty_print bug
- Posted by Al Getz <Xaxo at aol.com> Jun 26, 2004
- 448 views
In addition to the previous post... or simply:
if a-floor(a)=0
for integers that dont have to print in hex. Take care, Al And, good luck with your Euphoria programming! My bumper sticker: "I brake for LED's"
4. Re: pretty_print bug
- Posted by Robert Craig <rds at RapidEuphoria.com> Jun 26, 2004
- 470 views
Brian Broker wrote: > > <font color="#330033"></font> > <font color="#0000FF">include </font><font color="#330033">misc.e</font> > <font color="#330033"></font> > <font color="#0000FF">constant</font> > <font color="#330033">n = > {536870912,4294934783,3735928559,2164260736,1073741824,1073741823}</font> > <font color="#330033"></font> > <font color="#FF00FF">printf</font><font color="#330033">(1,</font><font > color="#00A033">"{%x,%x,%x,%x,%x,%x}\n"</font><font color="#330033">,n)</font> > <font color="#330033">pretty_print(1, n, </font><font > color="#993333">{</font><font color="#330033">0,2,1,78,</font><font > color="#00A033">"%x"</font><font color="#993333">} </font><font > color="#330033">)</font> > <font color="#330033"></font> > > Output: > {20000000,FFFF80FF,DEADBEEF,80FFFF80,40000000,3FFFFFFF} > {20000000,4294934783,3735928559,2164260736,1073741824,3FFFFFFF} pretty_print() uses integer() (31-bit numbers) to determine if something is an integer, whereas printf() tries to handle 32-bit values as well. Quirky, inconsistent, but I don't plan to change it. Regards, Rob Craig Rapid Deployment Software http://www.RapidEuphoria.com
5. Re: pretty_print bug
- Posted by Brian Broker <bkb at cnw.com> Jun 26, 2004
- 465 views
Robert Craig wrote: > > Brian Broker wrote: > > > > <font color="#330033"></font> > > <font color="#0000FF">include </font><font color="#330033">misc.e</font> > > <font color="#330033"></font> > > <font color="#0000FF">constant</font> > > <font color="#330033">n = > > {536870912,4294934783,3735928559,2164260736,1073741824,1073741823}</font> > > <font color="#330033"></font> > > <font color="#FF00FF">printf</font><font color="#330033">(1,</font><font > > color="#00A033">"{%x,%x,%x,%x,%x,%x}\n"</font><font color="#330033">,n)</font> > > <font color="#330033">pretty_print(1, n, </font><font > > color="#993333">{</font><font color="#330033">0,2,1,78,</font><font > > color="#00A033">"%x"</font><font color="#993333">} </font><font > > color="#330033">)</font> > > <font color="#330033"></font> > > > > Output: > > {20000000,FFFF80FF,DEADBEEF,80FFFF80,40000000,3FFFFFFF} > > {20000000,4294934783,3735928559,2164260736,1073741824,3FFFFFFF} > > pretty_print() uses integer() (31-bit numbers) to determine if > something is an integer, whereas printf() tries to handle 32-bit > values as well. Quirky, inconsistent, but I don't plan to change it. > > Regards, > Rob Craig > Rapid Deployment Software > <a href="http://www.RapidEuphoria.com">http://www.RapidEuphoria.com</a> > How quirky, inconsistant, and unfortunate... wrong answer imho. -- B
6. Re: pretty_print bug
- Posted by Brian Broker <bkb at cnw.com> Jun 26, 2004
- 486 views
Brian Broker wrote: > > Robert Craig wrote: > > > > Brian Broker wrote: > > > > > > <font color="#330033"></font> > > > <font color="#0000FF">include </font><font color="#330033">misc.e</font> > > > <font color="#330033"></font> > > > <font color="#0000FF">constant</font> > > > <font color="#330033">n = > > > {536870912,4294934783,3735928559,2164260736,1073741824,1073741823}</font> > > > <font color="#330033"></font> > > > <font color="#FF00FF">printf</font><font color="#330033">(1,</font><font > > > color="#00A033">"{%x,%x,%x,%x,%x,%x}\n"</font><font color="#330033">,n)</font> > > > <font color="#330033">pretty_print(1, n, </font><font > > > color="#993333">{</font><font color="#330033">0,2,1,78,</font><font > > > color="#00A033">"%x"</font><font color="#993333">} </font><font > > > color="#330033">)</font> > > > <font color="#330033"></font> > > > > > > Output: > > > {20000000,FFFF80FF,DEADBEEF,80FFFF80,40000000,3FFFFFFF} > > > {20000000,4294934783,3735928559,2164260736,1073741824,3FFFFFFF} > > > > pretty_print() uses integer() (31-bit numbers) to determine if > > something is an integer, whereas printf() tries to handle 32-bit > > values as well. Quirky, inconsistent, but I don't plan to change it. > > > > Regards, > > Rob Craig > > Rapid Deployment Software > > <a href="http://www.RapidEuphoria.com">http://www.RapidEuphoria.com</a> > > > > How quirky, inconsistant, and unfortunate... wrong answer imho. oh, and I forgot to ask... why not? I haven't studied the code in-depth for myself but Al has already made suggestions. So why not take them? Too close to release time to accidentally break something? Just curious, -- Brian
7. Re: pretty_print bug
- Posted by Pete Lomax <petelomax at blueyonder.co.uk> Jun 26, 2004
- 471 views
On Fri, 25 Jun 2004 22:10:39 +0000, Brian Broker <bkb at cnw.com> wrote: >pretty_print(1, n, {0,2,1,78,"%x"} ) Try pretty_print(1, n, {0,2,1,78,"%x","%x"} ) Regards, Pete
8. Re: pretty_print bug
- Posted by Al Getz <Xaxo at aol.com> Jun 26, 2004
- 469 views
Hmmm, some people cant read Take care, Al And, good luck with your Euphoria programming! My bumper sticker: "I brake for LED's"
9. Re: pretty_print bug
- Posted by Robert Craig <rds at RapidEuphoria.com> Jun 26, 2004
- 476 views
Brian Broker wrote: > oh, and I forgot to ask... why not? I haven't studied the code in-depth for > myself but Al has already made suggestions. So why not take them? Too close > to release time to accidentally break something? I think Pete Lomax's solution makes sense for your situation. It requires no changes to pretty_print(). pretty_print() lets you choose a format for numbers that are in the Euphoria integer() range, and another format for all other numbers. I don't want to add a third range, i.e. numbers that are integer-valued but are just outside Euphoria's 31-bit integers. And I don't want Al Getz's solution. It would choose a different format for any huge floating-point number that just happened to be a mathematical integer. Few people would want their printouts of large floating-point numbers to occasionally and unexpectedly flip into a different format. It's not my intention to make pretty_print() do all things for all people. I'm just trying to cover simple, common cases, and I'm trying to keep the documentation and the code reasonably short and understandable. If you want to add a bell or whistle to pretty_print(), you can copy it and edit it to your heart's content. Regards, Rob Craig Rapid Deployment Software http://www.RapidEuphoria.com
10. Re: pretty_print bug
- Posted by Pete Lomax <petelomax at blueyonder.co.uk> Jun 26, 2004
- 465 views
On Sat, 26 Jun 2004 07:24:40 -0700, Al Getz <guest at RapidEuphoria.com> wrote: >Hmmm, some people cant read Can't read what?
11. Re: pretty_print bug
- Posted by Brian Broker <bkb at cnw.com> Jun 27, 2004
- 451 views
Pete Lomax wrote: > > On Sat, 26 Jun 2004 07:24:40 -0700, Al Getz <guest at RapidEuphoria.com> > wrote: > > >Hmmm, some people cant read > > Can't read what? Yeah, I was wondering the same thing... Is this directed at anybody in particular or are you speaking to the Euphoria community as a whole? ;) -- Brian
12. Re: pretty_print bug
- Posted by Pete Lomax <petelomax at blueyonder.co.uk> Jun 28, 2004
- 479 views
On Sat, 26 Jun 2004 10:17:25 -0700, Robert Craig <guest at RapidEuphoria.com> wrote: >I think Pete Lomax's solution makes sense for your situation. I want to make it clear: that was a quick & dirty answer, not necessarily a good or correct one. I only said "Try" >It requires no changes to pretty_print(). Hmm, see below. >pretty_print() lets you choose a format for numbers that are >in the Euphoria integer() range, and another format for >all other numbers. I don't want to add a third range, i.e. >numbers that are integer-valued but are just outside >Euphoria's 31-bit integers. I have to (reluctantly) agree. Euphoria has 31-bit integers. Try and ignore that and you risk opening up a world of pain. > And I don't want Al Getz's >solution. It would choose a different format for >any huge floating-point number that just happened to be >a mathematical integer. Few people would want their >printouts of large floating-point numbers to occasionally and >unexpectedly flip into a different format. Rob, that *is* a knee-jerk reaction. Al's solution is perfectly fine in terms of pretty_print. I can't see a problem with it anyway ( bar foot-in-the-door for 32-bit integer support ). >It's not my intention to make pretty_print() do all things >for all people. I'm just trying to cover simple, common cases, >and I'm trying to keep the documentation and the code >reasonably short and understandable. Absolutely agree, 100%. >If you want to add >a bell or whistle to pretty_print(), you can copy it >and edit it to your heart's content. Ditto, this is trivial. However, I do want to stress: Anyone bar Rob making changes to Euphoria\include\misc.e\pretty_print() itself I would *STRONGLY* discourage. There is nothing like making such a change to your own machine and then weeks, months, or years later wondering why the same program fails miserably on an apparently identical machine. Editing a *copy* of that file is, of course, fine. Even if 2.5 is looming too close, I see nothing even slightly worrying with the following (though I doubt it will ever help anyone much): if integer(a) then -- By Al Getz 26/5/2004: to print 32-bit ints, make a copy of this -- file, and replace the above line with: -- if a-floor(a)=0 and -#FFFFFFFF<=a and a<=#FFFFFFFF then Regards, Pete
13. Re: pretty_print bug
- Posted by "Juergen Luethje" <j.lue at gmx.de> Jun 28, 2004
- 454 views
Pete wrote: > On Sat, 26 Jun 2004 10:17:25 -0700, Robert Craig wrote: <snip> >> It's not my intention to make pretty_print() do all things >> for all people. I'm just trying to cover simple, common cases, >> and I'm trying to keep the documentation and the code >> reasonably short and understandable. > Absolutely agree, 100%. > >> If you want to add >> a bell or whistle to pretty_print(), you can copy it >> and edit it to your heart's content. > Ditto, this is trivial. > > However, I do want to stress: Anyone bar Rob making changes to > Euphoria\include\misc.e\pretty_print() itself I would *STRONGLY* > discourage. There is nothing like making such a change to your own > machine and then weeks, months, or years later wondering why the same > program fails miserably on an apparently identical machine. > > Editing a *copy* of that file is, of course, fine. <snip> Obviously, you didn't want to say it yourself, but I'll do so: A very good replacement for preetty_print() is of course your 'ppp.e'. Pete, I suggest to put it on the User Contributions page. Also, Derek recently released his 'print.e' (which I haven't tried yet). Regards, Juergen
14. Re: pretty_print bug
- Posted by Al Getz <Xaxo at aol.com> Jun 28, 2004
- 475 views
Brian: I posted a suggestion which seemed to get ignored that's all. Pete: I agree,,,and my solution isnt perfect either. I think this whole thing needs to be thought through a little better. Yeah, Eu's 'integer' of 31 bits is the real culprit again! I dont have a single app (out of hundreds now) that requires a 31 bit integer over a 32 bit integer. Long ago, i wrote a small language on a now old machine that used mostly 16 bit integers, and i was going to use 15 bit integers saving the 16th bit for testing. Floats and longer ints would set this bit to 0 so it would be fast to test for this type. I found out in the long run that it was a complete waste of a bit. Maybe it's time for Euphoria to move to 32 bit integers. Until then, i guess i'll make up my own misc.e file and call it miscX.e or something and include that instead of misc.e . I'll probably add more tests to the nest to determine the right way to print. Not sure what to do with PrettySeq.e yet though :) Take care, Al And, good luck with your Euphoria programming! My bumper sticker: "I brake for LED's"