5 views

Skip to first unread message

May 31, 1999, 3:00:00 AM5/31/99

to

While reading some docs for another language, I came across a flash

of insight about fixing the octal problem in an "easy" manner.

What about adding dec(int), oct(int), hex(int) and base(1..36,int)

to the expr command? Since people are only really seem to be

encountering this problem in exprs anyway, it seems like a good

fit. For most, you would just wrap the desired number in dec()

(or base(10,int)) to make sure it was interpreted as a decimal num.

of insight about fixing the octal problem in an "easy" manner.

What about adding dec(int), oct(int), hex(int) and base(1..36,int)

to the expr command? Since people are only really seem to be

encountering this problem in exprs anyway, it seems like a good

fit. For most, you would just wrap the desired number in dec()

(or base(10,int)) to make sure it was interpreted as a decimal num.

That way people only have to know that possibly suspicious numbers

(like those entered by users) that are meant to be decimals can

be guaranteed to be interpreted as such with the above.

--

** Jeffrey Hobbs jeff.hobbs @SPAM acm.org **

** I'm really just a Tcl-bot My opinions are MY opinions **

May 31, 1999, 3:00:00 AM5/31/99

to

Jeffrey Hobbs wrote:

>

> While reading some docs for another language, I came across a flash

> of insight about fixing the octal problem in an "easy" manner.

> What about adding dec(int), oct(int), hex(int) and base(1..36,int)

> to the expr command? Since people are only really seem to be

> encountering this problem in exprs anyway, it seems like a good

> fit. For most, you would just wrap the desired number in dec()

> (or base(10,int)) to make sure it was interpreted as a decimal num.

>

> That way people only have to know that possibly suspicious numbers

> (like those entered by users) that are meant to be decimals can

> be guaranteed to be interpreted as such with the above.

Great!>

> While reading some docs for another language, I came across a flash

> of insight about fixing the octal problem in an "easy" manner.

> What about adding dec(int), oct(int), hex(int) and base(1..36,int)

> to the expr command? Since people are only really seem to be

> encountering this problem in exprs anyway, it seems like a good

> fit. For most, you would just wrap the desired number in dec()

> (or base(10,int)) to make sure it was interpreted as a decimal num.

>

> That way people only have to know that possibly suspicious numbers

> (like those entered by users) that are meant to be decimals can

> be guaranteed to be interpreted as such with the above.

One could even think of the same stuff for doubles.

Greetings!

Volker

May 31, 1999, 3:00:00 AM5/31/99

to

As much as I appreciate the suggestion, it seems like

a band-aid. The worst aspect of the "octal problem" is that

it takes people by surprise; "dec()" doesn't help that situation

at all.

a band-aid. The worst aspect of the "octal problem" is that

it takes people by surprise; "dec()" doesn't help that situation

at all.

Sometimes historical baggage should just be jettisoned.

My favorite is add a switch to preserve the old behavior and

let the people who know and care about octal handle it. I'm sure

they're capable.

-Roy

Jeffrey Hobbs wrote:

>

> While reading some docs for another language, I came across a flash

> of insight about fixing the octal problem in an "easy" manner.

> What about adding dec(int), oct(int), hex(int) and base(1..36,int)

> to the expr command? Since people are only really seem to be

> encountering this problem in exprs anyway, it seems like a good

> fit. For most, you would just wrap the desired number in dec()

> (or base(10,int)) to make sure it was interpreted as a decimal num.

>

> That way people only have to know that possibly suspicious numbers

> (like those entered by users) that are meant to be decimals can

> be guaranteed to be interpreted as such with the above.

>

May 31, 1999, 3:00:00 AM5/31/99

to

Jeffrey Hobbs <Jeffre...@icn.siemens.de> writes:

> While reading some docs for another language, I came across a flash

> of insight about fixing the octal problem in an "easy" manner. What

> about adding dec(int), oct(int), hex(int) and base(1..36,int) to the

> expr command?

I like it.

> encountering this problem in exprs anyway,

Or 'incr'.

--

Sincerely,

Andreas Kupries <a.ku...@westend.com>

<http://www.westend.com/~kupries/>

-------------------------------------------------------------------------------

May 31, 1999, 3:00:00 AM5/31/99

to

Volker Hetzer <volker...@abg1.siemens.de> writes:

> Jeffrey Hobbs wrote:

>> While reading some docs for another language, I came across a flash

>> of insight about fixing the octal problem in an "easy" manner.

>> What about adding dec(int), oct(int), hex(int) and base(1..36,int)

>> to the expr command? Since people are only really seem to be

>> encountering this problem in exprs anyway, it seems like a good

>> fit. For most, you would just wrap the desired number in dec() (or

>> base(10,int)) to make sure it was interpreted as a decimal num.

>> That way people only have to know that possibly suspicious numbers

>> (like those entered by users) that are meant to be decimals can be

>> guaranteed to be interpreted as such with the above.

> Great!

> One could even think of the same stuff for doubles.

Hm, we already have conversion functions in 'expr' for this:

double(arg)

If arg is a floating value, returns arg, otherwise

converts arg to floating and returns the converted

value.

and

int(arg)

If arg is an integer value, returns arg, otherwise

converts arg to integer by truncation and returns

the converted value.

Jun 1, 1999, 3:00:00 AM6/1/99

to

> > [Solution to the octal problem]

> > Great!

> > One could even think of the same stuff for doubles.

>

> Hm, we already have conversion functions in 'expr' for this:

>

> double(arg)

> If arg is a floating value, returns arg, otherwise

> converts arg to floating and returns the converted

> value.

Yes, but what about a floating hex number?

double(0xAF.E), or double(0xAF.FE-15)?

Jeffs solution would work if it would scan for the . and the exponent.

hex(AF.ee-15) could return an appropriate double. I see applications

of this in embedded solutions.

> > Great!

> > One could even think of the same stuff for doubles.

>

> Hm, we already have conversion functions in 'expr' for this:

>

> double(arg)

> If arg is a floating value, returns arg, otherwise

> converts arg to floating and returns the converted

> value.

double(0xAF.E), or double(0xAF.FE-15)?

Jeffs solution would work if it would scan for the . and the exponent.

hex(AF.ee-15) could return an appropriate double. I see applications

of this in embedded solutions.

Greetings!

Volker

Jun 6, 1999, 3:00:00 AM6/6/99

to

In article <3752E731...@earthlink.net>,

Roy Terry <royt...@earthlink.net> wrote:

> As much as I appreciate the suggestion, it seems like

> a band-aid. The worst aspect of the "octal problem" is that

> it takes people by surprise; "dec()" doesn't help that situation

> at all.

>

> Sometimes historical baggage should just be jettisoned.

> My favorite is add a switch to preserve the old behavior and

> let the people who know and care about octal handle it. I'm sure

> they're capable.

>

> -Roy

I agree with this.

Roy Terry <royt...@earthlink.net> wrote:

> As much as I appreciate the suggestion, it seems like

> a band-aid. The worst aspect of the "octal problem" is that

> it takes people by surprise; "dec()" doesn't help that situation

> at all.

>

> Sometimes historical baggage should just be jettisoned.

> My favorite is add a switch to preserve the old behavior and

> let the people who know and care about octal handle it. I'm sure

> they're capable.

>

> -Roy

The original "octal problem" is "unwanted octal conversions" performed

by the expr command. Basicly, since expr performs substitutions before

number conversions, expr converts numbers stored in variables to decimal

in addition to literals. There was another thread that seemed to have

this problem solved by eliminating octal conversions from expr.

Once expr no longer performs octal conversions, and if people still need

to use octal numbers, there needs to be a way to do it. scan can be

used and this may be sufficient since octal numbers are littled used.

If you want to look at the way other languages handle this, look at C.

When an octal literal is coded in C it is converted to an integer and

used in context. This would be typically in expressions, simple

replacements (i=017) and as function arguments.

Now consider what tcl does. For example:

1) set foo 0177

2) set result [expr $foo+24]

tcl performs the conversions in expr after substitution. This creates

the illusion that a conversion was performed at 1). Of course there was

no conversion at 1). The price of this illusion is high since it

introduces the problem that the contents of all variables are subjected

to base conversions.

A way to make tcl perform like C in this respect is to add a 'base'

command that converts numbers in other bases to decimal. The 'base'

command would also create lists when a list of numbers is provided as

arguments. For example:

set foo [base 0177] ;# initialization or simple replacement

set num_list [base 0177 0xA1 99];# convert a list of numbers to decimal

set result [expr $foo+24+[base 0xBC2]] ;# expr does no conversions

foobar [base 0xAB13] "a string" # function(proc) call argument

While this is more verbose than other languages it lets you make the

convesions you need explicitly and put them where they need to go. The

verboseness is the price of a minimal interpreter has a minor benefit of

improved readability.

Of course you can't really get rid of the 0x conversions done by expr

because they are already heavily used and this will cause code breakage.

Bob

>

> Jeffrey Hobbs wrote:

> >

> > While reading some docs for another language, I came across a flash

> > of insight about fixing the octal problem in an "easy" manner.

> > What about adding dec(int), oct(int), hex(int) and base(1..36,int)

> > to the expr command? Since people are only really seem to be

> > encountering this problem in exprs anyway, it seems like a good

> > fit. For most, you would just wrap the desired number in dec()

> > (or base(10,int)) to make sure it was interpreted as a decimal num.

> >

> > That way people only have to know that possibly suspicious numbers

> > (like those entered by users) that are meant to be decimals can

> > be guaranteed to be interpreted as such with the above.

> >

> > --

> > ** Jeffrey Hobbs jeff.hobbs @SPAM acm.org **

> > ** I'm really just a Tcl-bot My opinions are MY opinions **

>

>

Sent via Deja.com http://www.deja.com/

Share what you know. Learn what you don't.

Reply all

Reply to author

Forward

0 new messages

Search

Clear search

Close search

Google apps

Main menu