OpenEuphoria

1. Documentation and output of pretty_print()

• Posted by "Juergen Luethje" <j.lue at gmx.de> Sep 05, 2004
• 543 views

Hi Rob and all,

I accidently discoverd something concerning pretty_print(), that is
shown by the following code snippet:

include misc.e
atom a

a = power(2,30) - 1     -- 30 bit
pretty_print(1, a, {0,3,1,78,"#%x ('integer')", "#%x ('floating-point
number')"})
a = power(2,30)         -- 31 bit
pretty_print(1, a, {0,3,1,78,"#%x ('integer')", "#%x ('floating-point
number')"})

a) Options #5 and #6 can not only take format strings, but those strings
   can contain additional text, like in printf(). Very nice! This should
   be documented, I certainly had used it before, if I had known it.

b) Integer values > 30 bit seem to be treated as floating-point numbers.
   This is somehow confusing for me. Can this be changed without
   drawbacks?

Regards,
   Juergen

-- 
A: Because it considerably reduces the readability of the text.
Q: Why?
A: Top posting.
Q: What is annoying in e-mail and news?

3. Re: Documentation and output of pretty_print()

• Posted by "Juergen Luethje" <j.lue at gmx.de> Sep 06, 2004
• 494 views

Robert Craig wrote:

> Juergen Luethje wrote:

<snip>

>> a) Options #5 and #6 can not only take format strings, but those strings
>>    can contain additional text, like in printf(). Very nice! This should
>>    be documented, I certainly had used it before, if I had known it.
>
> I'll mention that in the docs. Thanks.

Thanks.

>> b) Integer values > 30 bit seem to be treated as floating-point numbers.
>>    This is somehow confusing for me. Can this be changed without
>>    drawbacks?
>
> I simply test for integer(). I don't want set up a third
> category for integer values in the 32-bit range.

I don't want that, too. :o)

How about changing the docs from currently
    [6] format to use for floating-point numbers - default: "%.10g"
to something like
    [6] format to use for numbers other than integer() - default: "%.10g"

<snip>

Regards,
   Juergen

5. Re: Documentation and output of pretty_print()

• Posted by "Juergen Luethje" <j.lue at gmx.de> Sep 06, 2004
• 504 views

Pete Lomax wrote:

> On Sun, 05 Sep 2004 13:40:56 +0200, Juergen Luethje <j.lue at gmx.de>
> wrote:
>
>> Hi Rob and all,
>>
>> I accidently discoverd something concerning pretty_print(),
>  You were using pretty_print? You TRAITOR! )

You've got me there. :o)

>> that is ALSO shown by the following code snippet:
>>
> }}}
<eucode>
> include ppp.e
> atom a
>
> ppOpt({pp_IntFmt,"#%x ('integer')"})
> ppOpt({pp_FltFmt,"#%x ('floating-point number')"})
>
> a = power(2,30) - 1     -- 30 bit
> pp(a)
> a = power(2,30)         -- 31 bit
> pp(a)
> </eucode>
{{{

>>
>> a) Options #5 and #6 can not only take format strings, but those strings
>>    can contain additional text, like in printf(). Very nice! This should
>>    be documented, I certainly had used it before, if I had known it.
> I didn't realise ppp.e would do this as well, I'll mention it
> somewhere, thanks

I think it's especially useful for expressions such as "#%x", "%.2f EUR",
"%.10g km".

>> b) Integer values > 30 bit seem to be treated as floating-point numbers.
>>    This is somehow confusing for me. Can this be changed without
>>    drawbacks?
> Ditto, I just use integer(), I suppose that could be changed (but not
> right now).

Right now is not necessary, tomorrow will be OK. :o)

Regards,
   Juergen

-- 
 /"\  ASCII ribbon campain  |  Money is the root of all evil.
 \ /  against HTML in       |  Send 20 Dollars for more info.
  X   e-mail and news,      |
 / \  and unneeded MIME     |  http://home.arcor.de/luethje/prog/

7. Re: Documentation and output of pretty_print()

• Posted by "Juergen Luethje" <j.lue at gmx.de> Sep 12, 2004
• 484 views
• Last edited Sep 13, 2004

Pete Lomax wrote:

> On Mon, 06 Sep 2004 20:07:18 +0200, Juergen Luethje <j.lue at gmx.de>
> wrote:
>
>> Pete Lomax wrote:
>>>> b) Integer values > 30 bit seem to be treated as floating-point numbers.
>>>>    This is somehow confusing for me. Can this be changed without
>>>>    drawbacks?
>>> Ditto, I just use integer(), I suppose that could be changed (but not
>>> right now).
>>
>> Right now is not necessary, tomorrow will be OK. :o)
> I've uploaded a new version.
> http://palacebuilders.pwp.blueyonder.co.uk/ppp.ZIP

Thanks.
Please try this:

include ppp.e
ppOpt({pp_IntFmt, "#%x"})
pp({ #FFFFFFFF})            -- 1) biggest unsigned 32-bit integer
pp({ #7FFFFFFF})            -- 2) biggest   signed 32-bit integer
pp({-#80000000})            -- 3) smallest  signed 32-bit integer

1) does not work as I expected, so you targeted at *signed* 32-bit
   integers only?
3) loses the '-' sign.

Regards,
   Juergen

9. Re: Documentation and output of pretty_print()

• Posted by "Juergen Luethje" <j.lue at gmx.de> Sep 13, 2004
• 493 views

Pete Lomax wrote:

> On Sun, 12 Sep 2004 23:39:54 +0200, Juergen Luethje <j.lue at gmx.de>
> wrote:
>
>> Pete Lomax wrote:
>>> I've uploaded a new version.
>>> http://palacebuilders.pwp.blueyonder.co.uk/ppp.ZIP
>>
>> 1) does not work as I expected, so you targeted at *signed* 32-bit
>>   integers only?
>> 3) loses the '-' sign.
> Both should be ok now.

I'm in a hurry now, and will try it out when I'm back home from work.

I just realized that both Eu's printf() and pretty_print() also lose the
'-' sign.
And there probably is another problem. In order to be able to re-use an
output from e.g.

printf(1, "%x", {a})

I think it's actually much better to use

printf(1, "#%x", {a})

so that the printed value still can be recognized as hex number.

The problem arises with negative numbers. Currently, the '-' sign is
lost, I think that's a bug. But when the minus sign wil be included in
the output, using the suggested format, then there will be output
strings such as

#-FF

This raises the error "hex number not formed correctly". Here is a small
demo program:

include misc.e
include ppp.e

sequence fmt
atom a
a = -#80000000            -- smallest 32-bit integer

fmt = "%x\n"
printf(1, fmt, {a})
pretty_print(1, a, {0,3,1,78,fmt,fmt})
ppOpt({pp_IntFmt, fmt})
pp(a)

puts(1, "------------------------------\n")

fmt = "#%x\n"
printf(1, fmt, {a})
pretty_print(1, a, {0,3,1,78,fmt,fmt})
ppOpt({pp_IntFmt, fmt})
pp(a)

So what to do now?

Regards,
   Juergen

11. Re: Documentation and output of pretty_print()

• Posted by "Juergen Luethje" <j.lue at gmx.de> Sep 13, 2004
• 490 views

Pete Lomax wrote:

> On Mon, 13 Sep 2004 08:08:02 +0200, Juergen Luethje <j.lue at gmx.de>
> wrote:
>
>> I just realized that both Eu's printf() and pretty_print() also lose the
>> '-' sign.
> Yup.
>> The problem arises with negative numbers. Currently, the '-' sign is
>> lost, I think that's a bug.
> Maybe it is a bug, maybe it is not. Technically, if the number has a
> sign, then the hex just needs to show a set bit where the sign bit is.
> One of the reasons I previously went with signed 32-bit numbers only
> was to make the hex output unambiguous:
>
> }}}
<eucode>
> 	printf(1,"%x %x",{4294967295,-1})
> </eucode>
{{{

>
> will output "FFFFFFFF FFFFFFFF". That is why the previous version
> restricted integers from #80000000 (-2147483648) to #7FFFFFFF
> (+2147483647), with the sign implied from the hex, if you see what I
> mean. I suppose that technically it now prints 33-bit numbers 

I see what you mean, at least I hope so. :o)
IIRC, things actually work like this for instance in PowerBASIC:
E.g. when 'a' is a signed 16-bit integer variable, and 'a = FFFF', then
'a' has a negative value, because the highest order bit is set.
When 'a' is a 32-bit integer variable, and also 'a = FFFF', then it
actually is here 'a = 0000FFFF'. So we see, that now the highest order
bit is not set, and thus 'a' has a positive value.

But when I learned to know Euphoria, I had the impression that
hexadecimal numbers work different in Euphoria. From my experience,
in Euphoria hexadecimal numbers (without the '-' sign!) always represent
positive values. That's why I write weird stuff like above. :o)
Is this true or not?

Here are the examples from 'refman_2.htm#1' (Eu 2.4):
    #FE             -- 254
    #A000           -- 40960
    #FFFF00008      -- 68718428168
   -#10             -- -16

The '-' sign is explicitely used here to indicate a negative number.

For instance in PowerBASIC for DOS 3.2, the following code
<pbcode>        :o)
? hex$(-16)
</pbcode>

prints 'FFF0' and

<pbcode>
? &hFFF0
</pbcode>

prints -16.

While in Euphoria

? #FFF0

prints 65520 instead.

Are there actually hex numbers in Euphora without a '-' sign, that
represent negative numbers??

printf(1, "%x", -16)        -- prints 'FFFFFFF0', so
printf(1, "%d", #FFFFFFF0)  -- should print '-16', but it prints 4294967280!
This is a bug, no??

> Anyway, the last version had
>
> }}}
<eucode>
> 	elsif cl<0 then
> 		txt='-'&sprintf(ppp_IntFmt,-cl)
> </eucode>
{{{

>
> which makes pp({4294967295,-1}) output {#FFFFFFFF,-#1}.
> (assuming of course that pp_IntFmt is "%x")
>
>> But when the minus sign wil be included in
>> the output, using the suggested format, then there will be output
>> strings such as
>> }}}
<eucode>
>> #-FF
>> </eucode>
{{{

> The code above causes "-#FF" to be printed (for -255).

So pp() is smart enough not to print "#-FF". Cool!

> I can accept someone might expect #FFFFFF01 instead.

Yes, that's what printf() and pretty_print() are printing.
But  '? -#FF'  prints '-255' again. This is what a naive person would
expect IMHO. So I, personally, thank you for making pp() behave this way!

> I feel another option coming on to enable/disable the two lines of
> code for negative integer handling above, and/or limit the integer
> range to avoid ambiguity... I will probably wait until someone asks
> for it though )
>
> <snip>
>> fmt = "%x\n"
> I trust you don't normally put \n's in pp_IntFmt or pp_FltFmt as they
> completely mangle the output. Pretty much the whole point of ppp.e is
> to automatically put in \n's in the right places for you!

In the sample code that I provided in my previous code, it actually made
sense. You can easily test it by removing \n from the format strings and
see what happens.
No, normally I don't do so. Thanks for the advice anyway.

> <snip>
>> This raises the error "hex number not formed correctly".
>> So what to do now?
> If you want machine-readable output, I suggest you avoid hex formats;
> %d (the default) will do just as well. What exactly is it that must be
> nicely formatted for human consumption and also machine readable?

My Eu code must be machine readable in any case. And source code should
be as good readable by humans as possible, in order to find bugs, and
maintain the code. Say there are some constants or variables, that mean
certain years, then I'd prefer to write 2003, 2004, etc. rather than
their hexadecimal equivalents. As you know, on the other hand
hexadecimal numbers are often preferable, when dealing with bits and
bytes.
For instance "constant CRC_TABLE" in my library 'bit.e' was written by
a little utility program, and I wanted the entries in "constant
CRC_TABLE" to be hex numbers.
I believe the bottom line is, that I want to have as much control as
possible, when writing programs. That's why I learned programming anyway,
because I want to tell the PC what to do, rather than the other way
round. 

Regards,
   Juergen