strings 
Author Message
 strings

Ok, I am new to perl,  But do make a good effort I think.

Anyways, here is my problem:

$price = "2,450";

if ($price <= "99")
  {
  ....
  ....
  }

what happend is it thinks 2,450 is smaller than 99, i know this is
becouse of the comma.

My question is how do i remove the comma from a string?

please, any help would help.

Mike



Thu, 25 Jan 2001 03:00:00 GMT  
 strings
: Anyways, here is my problem:
:
: $price = "2,450";
:
: if ($price <= "99")
:
: what happend is it thinks 2,450 is smaller than 99, i know this is
: becouse of the comma.
:
: My question is how do i remove the comma from a string?

  $price =~ tr/,//d;

Or, if you want to keep groups of three digits separated, Perl ignores _
inside numbers.  So you can do

  $price =~ tr/,/_/;

to turn $price into '2_450', then work with that.  That makes doing a
reverse tr back to commas trivial, should you need to redisplay $price
later with commas again.

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

 --*--    Home Page: http://www.cinenet.net/users/cberry/home.html
   |      Member of The HTML Writers Guild: http://www.hwg.org/  
       "Every man and every woman is a star."



Thu, 25 Jan 2001 03:00:00 GMT  
 strings

Quote:
>:
>: My question is how do i remove the comma from a string?
>  $price =~ tr/,//d;

Thank you! this did it perfect!
Mike


Thu, 25 Jan 2001 03:00:00 GMT  
 strings

19:00:18 GMT, Craig Berry (a) felt the following information to
be of use:

Quote:

> Or, if you want to keep groups of three digits separated, Perl ignores _
> inside numbers.  So you can do

>   $price =~ tr/,/_/;

> to turn $price into '2_450', then work with that.  That makes doing a
> reverse tr back to commas trivial, should you need to redisplay $price
> later with commas again.

From Programming Perl, page 39:

        ...The underscore only works within literal numbers                              
          specified in your program, not for strings functioning          
          as numbers or data read from somewhere else...

$_ = 2_345;   # A number, not a string
print $_+1;   # Prints 2346

$_ = '2_345'; # A string, not a number
print $_+1;   # Prints 3

It's my understanding that the _ is removed at assignment (or
compile time?)...

Hope this helps!

--Matthew



Thu, 25 Jan 2001 03:00:00 GMT  
 strings

: 19:00:18 GMT, Craig Berry (a) felt the following information to
: be of use:
: > Or, if you want to keep groups of three digits separated, Perl ignores _
: > inside numbers.  So you can do
: >
: >   $price =~ tr/,/_/;
: >
: > to turn $price into '2_450', then work with that.  That makes doing a
: > reverse tr back to commas trivial, should you need to redisplay $price
: > later with commas again.
:
: From Programming Perl, page 39:
:
:       ...The underscore only works within literal numbers                              
:           specified in your program, not for strings functioning          
:           as numbers or data read from somewhere else...

Oops, right you are.  Seems a silly way to have implemented things, but
that's the way it is.  Ignore my tr/,/_/ recommendation, please.

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

 --*--    Home Page: http://www.cinenet.net/users/cberry/home.html
   |      Member of The HTML Writers Guild: http://www.hwg.org/  
       "Every man and every woman is a star."



Thu, 25 Jan 2001 03:00:00 GMT  
 strings


Quote:

> Seems a silly way to have implemented things,

It seems to me that it's exactly the same as this:

        while (<DATA>) {
          print $_+1, "\n";
        }

        __DATA__
        077

... which prints `78', and not `0100'.

Code and data aren't the same thing.

Anyway, the underscores weren't allowed in literal constants until
recently, but changing the way string-to-number conversions are
performed in data would have broken many programs.



Fri, 26 Jan 2001 03:00:00 GMT  
 strings


Quote:

>Ok, I am new to perl,  But do make a good effort I think.

>Anyways, here is my problem:

>$price = "2,450";

>if ($price <= "99")
>  {
>  ....
>  ....
>  }

>what happend is it thinks 2,450 is smaller than 99, i know this is
>becouse of the comma.

>My question is how do i remove the comma from a string?

The problem is not the comma.

Problem 1 is: you don't use the -w option.
   -w would tell you: Argument "2,450" isn't numeric in le at ...

So you can rewrite the code to
$price = 2,450;
if ($price <= 99)
  {
  ....
  ....
  }

This will cause then error: Useless use of a constant in void context
at ...

So you can rewrite the code to
$price = 2450;    # or $price = 2.450; ?
if ($price <= 99)
  {
  ....
  ....
  }

Ronald



Fri, 26 Jan 2001 03:00:00 GMT  
 strings


: > Seems a silly way to have implemented things,
:
: It seems to me that it's exactly the same as this:
:
:       while (<DATA>) {
:         print $_+1, "\n";
:       }
:
:       __DATA__
:       077
:
: ... which prints `78', and not `0100'.
:
: Code and data aren't the same thing.

I guess my time in the Lisp world made me question that assumption. :)
Seriously, I think it's a reasonable goal that, where possible, code and
data *should* use the same formats and conventions.  And, indeed, I've
often wished that 077 and 0xCA in input data would parse as octal and hex
respectively.

: Anyway, the underscores weren't allowed in literal constants until
: recently, but changing the way string-to-number conversions are
: performed in data would have broken many programs.

That's the stronger argument, of course, though it's sad how every
language and OS become gradually encumbered by the weight of past
practice.  Then again, I suppose that's (one reason) why new languages and
OSs appear from time to time.

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

 --*--    Home Page: http://www.cinenet.net/users/cberry/home.html
   |      Member of The HTML Writers Guild: http://www.hwg.org/  
       "Every man and every woman is a star."



Fri, 26 Jan 2001 03:00:00 GMT  
 strings

Quote:

>Seriously, I think it's a reasonable goal that, where possible, code and
>data *should* use the same formats and conventions.  And, indeed, I've
>often wished that 077 and 0xCA in input data would parse as octal and hex
>respectively.

I don't think you've thought this through.  It would be an incredible
disaster.  You'd be reading in your file of zip code, and you'd get to

        TPJ,POB 54,Boston,MA,02101

and you'd discover that the zip code had been interpreted as `1089'.

It's much better to call an explicit conversion function if you want
the 1089.  In this case, the function is called `oct'.

And of course, it's not hard to build such a conversion function:

        if (numval("2,342") < 7) {
          ...
        }

As you pointed out, Lisp does have such features---all invoked through
explicit conversion functions of one kind or another.  The most
powerful and well-known of these conversion functions is `eval'.

Perl has `eval' too.  If you want underscores in your numbers, then

        if (eval "2_342" < 7) {
          ...
        }

will work just fine.

Quote:
>it's sad how every language and OS become gradually encumbered by the
>weight of past practice.

While I would agree with you in general, I think that this is not a
sad example.  I think this is an example of how a good designer can
get things right the first time and not have to change them later.


Fri, 26 Jan 2001 03:00:00 GMT  
 strings


: >Seriously, I think it's a reasonable goal that, where possible, code and
: >data *should* use the same formats and conventions.  And, indeed, I've
: >often wished that 077 and 0xCA in input data would parse as octal and hex
: >respectively.
:
: I don't think you've thought this through.  It would be an incredible
: disaster.  You'd be reading in your file of zip code, and you'd get to
:
:       TPJ,POB 54,Boston,MA,02101
:
: and you'd discover that the zip code had been interpreted as `1089'.

Well, one could argue that the zip code should be treated as a string
value, not a numeric value.  If treated as a string, the original
representation would be retained.  Only if the zip code were treated as an
operand in a numeric operation would the conversion occur.

But I agree in the general case that this could cause some very serious
problems.

: As you pointed out, Lisp does have such features---all invoked through
: explicit conversion functions of one kind or another.  The most
: powerful and well-known of these conversion functions is `eval'.

I was referring (a bit elliptically, true) more to Lisps use of list
representation for both data and code, and the resulting easy blurring of
the two.  The formats for external scalar representation are indeed
subject to similar explicit manipulation in Perl and Lisp.

: >it's sad how every language and OS become gradually encumbered by the
: >weight of past practice.
:
: While I would agree with you in general, I think that this is not a
: sad example.  I think this is an example of how a good designer can
: get things right the first time and not have to change them later.

Quite probably so wrt octal and hex interpretations, possibly not so wrt _
as a thousands separator, and certainly a minor enough nit (with easy
enough workarounds) that it does not noticeably dim Perl's brilliant glow.

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

 --*--    Home Page: http://www.cinenet.net/users/cberry/home.html
   |      Member of The HTML Writers Guild: http://www.hwg.org/  
       "Every man and every woman is a star."



Fri, 26 Jan 2001 03:00:00 GMT  
 strings

1998 18:22:54 +0200, Ronald G?ggel (a) felt the following
information to be of use:

Quote:

> The problem is not the comma.

> Problem 1 is: you don't use the -w option.
>    -w would tell you: Argument "2,450" isn't numeric in le at ...

> So you can rewrite the code to
> $price = 2,450;
> if ($price <= 99)
>   {
>   ....
>   ....
>   }

The problem _is_ the comma.  Perl automatically changes the
string to a number, and vice-versa when needed.  IIRC, Perl uses
something similar (perhaps the very ones?) to C's atoi, atof, etc
functions, so translation to a number stops at the first non-
digit.  Hence, comparing '2,450' <= 99 is equiv to saying '2' <=
99, which is, of course, true.

Removing the , from the string works fine (in this example).  

Consider:

#!/usr/bin/perl -w

$_ = '2,450';

if ( $_ < 99 ) {print "(1) Less than 99!\n";}
else           {print "(1) Greater than 99!\n";}

tr/,//d;

if ( $_ < 99 ) {print "(2) Less than 99!\n";}
else           {print "(2) Greater than 99!\n";}

__END__

Gives me:

Argument "2,450" isn't numeric in lt at temp line 5.
(1) Less than 99!
(2) Greater than 99!

Hope this helps!

--Matthew



Sat, 27 Jan 2001 03:00:00 GMT  
 strings

Quote:

>Well, one could argue that the zip code should be treated as a string
>value, not a numeric value.

Well, it *is* being treated as a string value, not a numeric value,
but that's exactly what you said you didn't want.  You just said you
wanted it to parse as octal:

Quote:
>: >I've often wished that 077 and 0xCA in input data would parse as
>: >octal and hex respectively.

Since you seem to be professing two contradictory opinions, I'm going
to stick with my assessment that you haven't thought it through.

Quote:
>I was referring (a bit elliptically, true) more to Lisps use of list
>representation for both data and code, and the resulting easy blurring of
>the two.

There are two parts to that.  One part, the wonderful and important
part, has to do with closures and their use in object-oriented
programming, that you use to write things like this:

  ;; Make a counter object that supports `increment' and `get' methods
  ;; Please pardon my syntax errors if there are any
  (defun make-counter ()
    ( let ((x 0))
      (lambda (operation)
       (cond ((eq operation 'increment)
              (setq x (+ x 1)))
             ((eq operation 'get)
              x)
             (t
              (error "Unknown operation: " (make-string operation)))
        )
    )))

   ;; Convenience methods for counters
   ;; Is x data?  Or is it code?  Who knows?  Who cares?
   (defun increment (x) (x 'increment))
   (defun get (x) (x 'get))

   ;; Try them out
   (setq c1 (make-counter))
   (setq c2 (make-counter))
   (increment c1)
   (increment c1)       ; Is c1 a data object?  Or a function?  Whatever!
   (increment c1)
   (get c2)             ; yields 0
   (get c1)             ; yields 3

But it seemed to me that your complaint didn't have anything to do
with this; instead it was about treatment of input data and of literal
constants in the source, and had a lot more to do with eval and
backquote and string->symbol and the like.  These are important
features of Lisp, but not nearly as central or as important to the
`data as code' notion as the use of closures is.

I sent followups to comp.programming since this no longer appears to
have anything to do with Perl.



Sat, 27 Jan 2001 03:00:00 GMT  
 
 [ 12 post ] 

 Relevant Pages 

1. $:, breaking a string after a string

2. Replace a String in a File with an other String both in variables

3. the fastest way to test String A included by String B

4. newbie question regarding s/<old string>/<new string>/g

5. finding files containing string x but not string y

6. extract string from another string

7. Working out if string A is related to string B

8. Converting undefined strings to null strings

9. regular expression to extract a string between 2 other strings

10. changing a single quote string to a double quote string

11. split a string not only by a single char but also by a string

12. Newbie: sprintf ('%-20s', 48 char string) returns 48 not 20 length string

 

 
Powered by phpBB® Forum Software