"Dave Weaver" <weaver22 (AT) pacbell (DOT) net> wrote

"Dave Weaver" wrote in reply:
Dave,

try the same test, but make the numbers each 1 byte shorter. Drop off the
last 4 on each of the two numbers and see what happens.

FOOFOO2
001 REC114 = "7228810817"
002 UPC = "0007228810817"
003 IF REC114 = UPC THEN PRINT "SAME" ELSE PRINT "NOT.SAME"

:FOOFOO2
SAME

You get the NOT SAME with the longer string because the POPN fails on
numbers that large. They overflow the accumulator, causing an error which
forces string compare.

You are 100% correct that the problem is that the two strings are both
numeric and so to force alpha testing, you MUST append a non-numeric
character to each string.

Like:

IF REC114:" " = UPC:" " THEN PRINT "SAME" ELSE PRINT "NOT SAME"


Mark Brown

As a side note if you ever wonder about why something is or is not
behaving, at least in Universe, go to the debugger and display the
variable there. It will tell you:

X/
INTEGER: 123

or

X/
STRING: T r L-3 '123'

Then you can see if you are comparing apples to apples or not.

This is also the problem with simply adding zero to remove leading
zero(s)... if you add zero to a large numeric string (say a bank
account number) you get crap. In this case I usually:

loop until x[1,1] ne "0" do
x = x[2,99]
repeat

Scott Ballinger
Pareto Corporation
Edmonds WA USA
206 713 6006

Hmmm, should have probably tested that before expounding based on
memory. I seem to recall that something expoded when this was done in
the past (maybe very very distant past?) but now, on D3 7.4 at least,
adding zero to a large string just does... nothing. I.e. does not
convert to numeric and does not remove leading zeros. So, although it
does not blow up, you do still need to use string manipulation [1,1] to
remove the the leading characters.

Scott Ballinger
Pareto Corporation
Edmonds WA USA
206 713 6006

Scott Ballinger wrote:
Yup. D3 is capable of handling arbitrarily large numbers these days.
Presumably they integrated AccuMath into BASIC runtime, or possibly
developed their own long-string arithmetic package.

Luke

IIRC it is the Acumath product, or at least derived from it. I think
AccuMath got "bundled" with AP at around 5.2 - a native realease
anyway, and I think when 6.0 came out (a reasonably stable release for
SCO I recall, and a watershed for a number of features), rather than
being an 'add in' it was more harmoniously integrated

On jBASE, you can force a string comparison by using the StrComp() C
function, e.g.

DEFC StrComp(VAR, VAR, VAR)
IF StrComp( '=', IM.REC<114>, UPC) THEN . . .

A bit more elegant than appending (or prepending) a string to each
variable, don't you think? ;-)

This method is also about 5 times faster than 'IF var1 op var2', and faster
still than the 'string append' method!

Dan


On Tue, 03 May 2005 21:07:10 GMT, "James Stoddard" <wildcat66 (AT) hotmail (DOT) com>
wrote:

Scott Ballinger wrote:
I don't know about all versions, but UniData offers an option on the
TRIM function to do this. In the various versions I've used, the
function TRIM(<string>) returns the original string without leading,
trailing and redundant blanks. UniData allows you to specify three
parameters: TRIM(<string>,<char>,<type>). By default, <char> is the
blank, and <type> is "R" (for Redundant). Other available types
include "L", "T", "B" and "A", for Leading, Trailing, Both, and All.

In the above example, under UniData, I could use

x = TRIM(x,"0","L")

to get the same result. I believe Pick version 6.2 and up offers this
syntax in the "trimchar" function. I don't know if this syntax is
available under other versions.

--Tom Pellitieri

If I didn't know better I'd think this was a troll. Gotta remember
the best way to get this group fired up: ask a question about
something that hasn't changed since R83.

I happen to know Jim's application is written in RPL, not BASIC:
Jim - The question you are asking is exactly the reason why there is
an IFN statement in RPL compared to IF. If you used an IF statement
in RPL then you'll get '001' is different from '1', but if you intend
a numeric compare then you'd use IFN. BASIC has no IFN but when it
sees two numerics it evaluates them numerically - and that's why
everyone suggests forcing the compare to alpha when you're checking
data that happens to consist of numeric chars but the data is not
technically 'a number'.

Tony

To answer Dale B: Data from a file are *always* in string format. I'd always
used the +0 to convert to number (but see #2 below). Personally, I've used
the append-a-character comparison a lot.

An aside: Sometimes you want to pass a variable to a subroutiine but not get
any changes back; the technique I use is:
CALL WHATSUB( number+0, string:'' ) ... sometimes you need this to pass
COMMON variables also, as some compiler/runtimes barf at excessive COMMONs
as arguments.

From other posts, I gather:

1- that jbase can use a C function to do the same thing as straight BASIC
(ie StrComp vs IF x=y) but the former executes 5 times faster than the code
that 99% of the programmers would choose (or maybe even have heard about)!

2- What Luke seems to say is that, say, '0000001' + 0 results in 1 (numeric)
but '000000000000000000000000000001' + 0 results in
'000000000000000000000000000001' (string)! So the programmer has to be
aware of the system's limitations (I presume the limit is 2^^48-1?) even
though Extended math is "built in". What
happens if you say X='000000000000000000000000000001' + 1 ?

Time for me to stop badmouthing javascript and IE.

Chandru

"Daniel Klein" <danielkleinad (AT) hotmail (DOT) com> wrote