Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Perl > Perl Misc > Elegant ways to convert '' or 'number' to a number

Reply
Thread Tools

Elegant ways to convert '' or 'number' to a number

 
 
Rainer Weikusat
Guest
Posts: n/a
 
      02-16-2012
http://www.velocityreviews.com/forums/(E-Mail Removed) (Tim McDaniel) writes:
> Rainer Weikusat <(E-Mail Removed)> wrote:
>>(E-Mail Removed) (Tim McDaniel) writes:
>>> Rainer Weikusat <(E-Mail Removed)> wrote:
>>>>(E-Mail Removed) (Tim McDaniel) writes:


[...]

>>>>>>By 'null string' you mean an empty string, not undef, right?
>>>>>
>>>>> Yes. I agree with Cerebron on dragons: the concepts ought to be
>>>>> kept rigidly distinct.
>>>>
>>>>They are not different concepts and Perl and have never been
>>>>different concepts in Perl
>>>
>>> They can be distinguished via defined(). They cause different
>>> warnings (uninitialized value).

>>
>>They are not disinguishable for their 'string value' because
>>automatic conversions are done by Perl as required

>
> Nevertheless, they are different concepts, although there is only one
> place (defined()) where code can tell the difference, so far as I
> know.


They are 'something different' at the perl implementation level. If
they are also 'something different' for a particular application of
Perl to some problem depends on the problem: Values usually have types
and such a type is the set of all valid values for a particular
'thing'. If this set includes some kind of 'null value', something
which is technically legitimate but no operations save than comparing
it to other valid values may be used on it and the result will always
be "it's differen", Perl default-value scalars can be used to
represent this 'null value'. An example of that would be DBI which
represents the SQL concept of 'the null value' in this way. OTOH, if
I'm dealing with the values from the mod 256 factor ring, treating the
same default value scalar as a variable which is automatically
initialized to a value of 0 will often be more convenient, no matter
how thoroughly the very idea combs zealous beancounters against the
grain (I have no idea if this works in English, just some web-research
based hopes that it does).

 
Reply With Quote
 
 
 
 
ccc31807
Guest
Posts: n/a
 
      02-16-2012
On Feb 15, 6:10*pm, (E-Mail Removed) (Tim McDaniel) wrote:
> >What's wrong with using int(),

>
> The part about "without producing a warning if it happens to be a null string".


Sorry, I guess I didn't notice that.

Here is a common idiom that I employ a lot:

$x ||= 0;

Obviously, this only applies when $x does not contain any value.

When validating data, for example, ensuring that a field contains
something similar to an email address, I do this a lot:

$x ||- '(E-Mail Removed)';

or

$x = '(E-Mail Removed)' unless $x =~ /\w+\@.\w+/;

Finally, if you automate your scripts, perhaps by using a cron job or
a scheduled task, no one sees the warnings. In many (most?) of my
production scripts, I don't disable warnings. My users never see the
warnings, but only the output -- however, when I run the scripts in
real time, I see the warnings, and somehow that reassures me that
everything's right with the world.

CC.
 
Reply With Quote
 
 
 
 
Rainer Weikusat
Guest
Posts: n/a
 
      02-16-2012
ccc31807 <(E-Mail Removed)> writes:

[...]


> Finally, if you automate your scripts, perhaps by using a cron job or
> a scheduled task, no one sees the warnings.


FYI: Usually, cron will mail the stdout and stderr output of a cronjob to
the user whose cronjob it was.
 
Reply With Quote
 
Tim McDaniel
Guest
Posts: n/a
 
      02-16-2012
In article <(E-Mail Removed) >,
Rainer Weikusat <(E-Mail Removed)> wrote:
>If they are also 'something different' for a particular application
>of Perl to some problem depends on the problem


Hm. I think I agree with your point. Perhaps I might put it that,
from the point of view of "duck typing", what matter is what you want
to do with it and what the language conveniently allows.

I'm not sure whether it's my FORTRAN and C background, or my general
anal-retentiveness, that makes me focus too much on types and to look
with suspicion on Perl's builtin conversions, instead of relaxing and
letting Perl deal with it -- in the case I was asking about, letting
the "==" operator handle the conversion.

>no matter how thoroughly the very idea combs zealous beancounters
>against the grain (I have no idea if this works in English, just some
>web-research based hopes that it does).


"Beancounter", as I've heard it, refers specifically to accountants,
and that word doesn't have connotations that work here. I'd say
"no matter how thoroughly the very idea rubs pedants the wrong way".

--
Tim McDaniel, (E-Mail Removed)
 
Reply With Quote
 
Peter J. Holzer
Guest
Posts: n/a
 
      02-17-2012
On 2012-02-16 20:21, Rainer Weikusat <(E-Mail Removed)> wrote:
> ccc31807 <(E-Mail Removed)> writes:
>> Finally, if you automate your scripts, perhaps by using a cron job or
>> a scheduled task, no one sees the warnings.

>
> FYI: Usually, cron will mail the stdout and stderr output of a cronjob to
> the user whose cronjob it was.


Right. And getting a mail with a warning every 10 minutes should be
enough enough motivation to fix the problem fast (of course some people
would rather implement a mail filter to automatically delete all mails
from cron ...)

hp

--
_ | Peter J. Holzer | Deprecating human carelessness and
|_|_) | Sysadmin WSR | ignorance has no successful track record.
| | | (E-Mail Removed) |
__/ | http://www.hjp.at/ | -- Bill Code on (E-Mail Removed)
 
Reply With Quote
 
Peter J. Holzer
Guest
Posts: n/a
 
      02-17-2012
On 2012-02-15 22:52, Graham Drabble <(E-Mail Removed)> wrote:
> On 14 Feb 2012 (E-Mail Removed) (Tim McDaniel) wrote in
> news:jhek67$dpd$(E-Mail Removed):
>> So a cow-orker has the result of a database query. It's being
>> returned as a string: it contains an integer or it's a null
>> string.

>
> Has he though of changing the query. You don't say what DB he's using
> but the following should work in MSSQL and I would expect similar to
> be possible in other DBMSs.
>
> Instead of
> "SELECT
> column
> from table"
>
> use
>
> "SELECT
> case
> when column is null then 0
> else column
> end
> from table"


Tim already wrote (unless I misunderstood him), that the value is
actually "", not undef. DBI always returns undef for NULL, so that
wouldn't help. (This also means that the column has almost certainly a
varchar type, not a number type, which hints at a deeper database design
problem - but unfortunately we often have to live with databases as they
are and can't fix them).

Somethingh like

SELECT
case column
when '' then 0
else column
end
from table

should work, though.

hp


--
_ | Peter J. Holzer | Deprecating human carelessness and
|_|_) | Sysadmin WSR | ignorance has no successful track record.
| | | (E-Mail Removed) |
__/ | http://www.hjp.at/ | -- Bill Code on (E-Mail Removed)
 
Reply With Quote
 
Peter J. Holzer
Guest
Posts: n/a
 
      02-17-2012
On 2012-02-16 09:30, Shmuel Metz <(E-Mail Removed)> wrote:
> In <(E-Mail Removed) >, on 02/15/2012
> at 03:25 PM, Rainer Weikusat <(E-Mail Removed)> said:
>>They are not different concepts and Perl and have never been
>>different concepts in Perl:

>
> Nonsense; interpolating an empty string does not produce a warning.
> There are certainly cases where you can ignore the difference, but the
> difference is nonetheless real.


More importantly: If Larry had intended undef to to conceptually the
same as an empty string he wouldn't have bothered to implement undef
at all. Why implement a special value with a special keyword if it's
just the same as an empty string? So Larry considered it important to be
able to distinguish between undef (no value, missing value, unknown
value, ...) and the empty string or 0, even if he provided for automatic
conversion.

hp


--
_ | Peter J. Holzer | Deprecating human carelessness and
|_|_) | Sysadmin WSR | ignorance has no successful track record.
| | | (E-Mail Removed) |
__/ | http://www.hjp.at/ | -- Bill Code on (E-Mail Removed)
 
Reply With Quote
 
Peter J. Holzer
Guest
Posts: n/a
 
      02-17-2012
On 2012-02-15 22:17, ccc31807 <(E-Mail Removed)> wrote:
> On Feb 14, 4:37*pm, (E-Mail Removed) (Tim McDaniel) wrote:
>> So a cow-orker has the result of a database query. *It's being
>> returned as a string: it contains an integer or it's a null string.
>> (Yes, we're certain.) *He wants to use it in a numeric context,
>> Is there an elegant idiom for converting such a string to a number
>> without producing a warning if it happens to be a null string?

>
> What's wrong with using int(), or sprintf()?
>
> I had a similar problem, but the reverse. I used person ID numbers as
> keys in a hash table, and manipulated the values in various ways,
> which included Microsoft Excel. I kept getting aggravating errors over
> a long time, and after one experience went through the results line by
> line and discovered that sometimes ID numbers with leading zeros were
> treated like real numbers, and a value like '4321' does not match a
> hash key like '0004321'.


Well, you have to know your data: Perl itself won't convert a string
'0004321' into the number 4321 unless you force it to. Contrary to what
Rainer probably thinks numbers and strings aren't the same in Perl and
if you keep a mental model of what your values actually are it isn't
actually that hard to prevent accidental type conversions.


> I started using sprintf() when in doubt, and it solved the problem. I
> just convert whatever the value is into a string, and it preserves the
> leading zeros.


You haven't shown the sprintf invokation you use but I don't think so.
It may *add* leading zeros if they got lost, but it cannot preserve
them.

hp


--
_ | Peter J. Holzer | Deprecating human carelessness and
|_|_) | Sysadmin WSR | ignorance has no successful track record.
| | | (E-Mail Removed) |
__/ | http://www.hjp.at/ | -- Bill Code on (E-Mail Removed)
 
Reply With Quote
 
Tim McDaniel
Guest
Posts: n/a
 
      02-17-2012
In article <(E-Mail Removed)>,
Peter J. Holzer <(E-Mail Removed)> wrote:
>Tim already wrote (unless I misunderstood him), that the value is
>actually "", not undef. DBI always returns undef for NULL, so that
>wouldn't help. (This also means that the column has almost certainly
>a varchar type, not a number type, which hints at a deeper database
>design problem - but unfortunately we often have to live with
>databases as they are and can't fix them).


In particular, this is Oracle. As I understand it, it implements
varchar NULL as a null string. It may be DBI, or the database
wrappers we've put around it, or other functions around them, but my
cow-orker reported that it was indeed a null string when he got it.

--
Tim McDaniel, (E-Mail Removed)
 
Reply With Quote
 
Rainer Weikusat
Guest
Posts: n/a
 
      02-17-2012
"Peter J. Holzer" <(E-Mail Removed)> writes:

[...]

> Contrary to what Rainer probably thinks numbers and strings aren't
> the same in Perl


Assumptions you make about other people's thoughts are YOUR thoughts.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
how many ways to convert a integer to a string apple.davinci@gmail.com C Programming 12 03-10-2006 09:18 PM
is there something more elegant to convert Dos to unix in subroutine? Andrew Perl Misc 23 05-09-2004 10:12 PM
Convert decimal number in binary number makok VHDL 1 02-23-2004 06:04 PM
Number of ways to create an object Peter Ammon C++ 22 01-30-2004 02:50 AM
good ways to convert string into time Hank Python 5 11-18-2003 11:44 PM



Advertisments