|
 L
#24040
23 Jan 19 12:08 PM
|
|
Anonymous
Unregistered
|
|
Anonymous
Unregistered
|
I cannot for the life of me remember what the L does here. I searched the documentation, but had no idea what to search for :rolleyes:
What does the L do here?
test'b6 = 99999999999999L
|
|
|
|
Re: L
#24041
23 Jan 19 12:44 PM
|
Joined: Jun 2001
Posts: 11,794
Jack McGregor
Member
|
|
Member
Joined: Jun 2001
Posts: 11,794 |
This was introduced in 6.4.1515 (compiler edit 763,June 2016) and then refined in 6.4.1533 (compiler edit 789, October 2016),but obviously not documented very well. The latter note more or less explains it:
1533.2 Compiler edit 789: revise compiler edit 763 so that it only uses the 48 bit integer format for large numeric literals that are either explicitly tagged with the "L" suffix or with the hex (&h) or octal (&o) prefix. Previously it was using the new format for large numeric literals expressed in exponential or decimal notation, which was causing unexpected backwards compatibility problems when compiling under 6.3 and running under 6.2.
The "L" syntax was borrowed from a notation used in C to indicate a "large integer" as opposed to a standard integer, although in our case it tells the compiler to store the literal in the RUN as a B,6 value rather than as a floating point. The difference is significant in your case, because the standard float (F,6) can handle only about 11 significant digits, and your constant has 14. With the L suffix, we can handles up to 2**47 (I,6) or 2**48 (B,6) both of which are in the low 15 digits. But be careful, because if you add one more 9 (to make 15 of them), you'll overflow the 48 bit integer format, resulting in garbage, whereas storing it as a float would at least keep it in the ballpark. For example: significance 16
map1 i6,i,6
map1 b6,b,6
map1 f6,f,6
i6 = 99999999999999 ! constants stored as F6
? i6
b6 = 99999999999999
? b6
?
i6 = 99999999999999L ! constants stored as I,6
? i6
b6 = 99999999999999L
? b6
?
i6 = 200000000000000L ! this is above the I6 threshold,
? i6
b6 = 200000000000000L ! but below the B6 threshold
? b6
?
i6 = 999999999999999L ! 15 9's will overflow the format!
? i6
b6 = 999999999999999L
? b6
?
f6 = 999999999999999 ! float to float
? f6
end .run ltest
100000000000000
100000000000000
99999999999999
99999999999999
-81474976710656
200000000000000
-125899906842625
155575069868031
1000000000000000 So the first two (without the L suffix) end up getting rounded due to the limited significance of the F6 format. The second two are perfect. In the third pair, the I6 value overflowed while the B6 was able to handle it. The fourth pair (with 15 9's) both overflow in different ways. And the last one shows the the F,6 format, while again being off by one, is at least close.
|
|
|
|
Re: L
#24042
24 Jan 19 11:21 AM
|
|
Anonymous
Unregistered
|
|
Anonymous
Unregistered
|
Thanks for the long (L) answer :rolleyes: . So, if I have an integer constant that is larger than approximately 11 digits, I have to use the L, &h, or &o or the compiler will store it as F,6 and not be accurate? So if I'm dividing something by 1e12, I need to use 1000000000000L? Seems like a good case for a ++PRAGMA or just the default with the X:2 compile switch. Maybe?
|
|
|
|
Re: L
#24043
24 Jan 19 11:36 AM
|
Joined: Jun 2001
Posts: 11,794
Jack McGregor
Member
|
|
Member
Joined: Jun 2001
Posts: 11,794 |
A pragma might be appropriate, but I started with the idea of automatically using the 48 bit integer format for constants larger than 32 bits, but then changed it because of problems with programs that were compiled under a newer version of the compiler but run under an older runtime that didn't recognize the 48 bit integer constant format.
If you're regularly dealing with numbers having 12 or more digits, it might make sense to do a full review to see whether some kind of scaling might be appropriate, since even the 48 bit integers only get you into the low 15 digits.
|
|
|
|
Re: L
#24044
24 Jan 19 11:48 AM
|
|
Anonymous
Unregistered
|
|
Anonymous
Unregistered
|
In the new pharmacy prescription claim version (not in use yet), I know, off the top of my head, of one variable that is 14 digits and likely others. I really doubt that I have used a constant that is more than 11 digits but don't really know and that's my problem. I would make use of the pragma, but it will be a year or more before this new version is in use. Could you put it on the to do on a rainy day list or is this a monster?
|
|
|
|
Re: L
#24045
24 Jan 19 12:30 PM
|
Joined: Jun 2001
Posts: 11,794
Jack McGregor
Member
|
|
Member
Joined: Jun 2001
Posts: 11,794 |
Ok, I'll put it on the rainy day list.
But just out of curiosity, what kind of a value is that 14 digit monster? Hopefully it's not money (I know pharmaceuticals have gotten expensive, but seriously!).
|
|
|
|
Re: L
#24046
24 Jan 19 01:03 PM
|
|
Anonymous
Unregistered
|
|
Anonymous
Unregistered
|
It's a quantity value of an ingredient in a compounded drug that I store as an integer. It's actually defined as 9(7)v9(7) but can repeat up to 25 times. I need to store it as an integer to sum the potential 25 ingredients in a compounded product without losing any significance. There are other values I can't think of right now that are in that range too. I have converted a large number of integer variables in the files to use I,6 and b,6. That is a fantastic addition you made. For the record, most dollar amounts are signed and defined as s9(6)v99.
|
|
|
|
Re: L
#24047
24 Jan 19 04:06 PM
|
Joined: Sep 2002
Posts: 5,471
Frank
Member
|
|
Member
Joined: Sep 2002
Posts: 5,471 |
That is a LOT of tapioca! 
|
|
|
|
Re: L
#24048
25 Jan 19 08:58 AM
|
|
Anonymous
Unregistered
|
|
Anonymous
Unregistered
|
And who would be better to know than you, Frank 
|
|
|
|
Re: L
#24049
13 Feb 19 11:52 AM
|
Joined: Jun 2001
Posts: 11,794
Jack McGregor
Member
|
|
Member
Joined: Jun 2001
Posts: 11,794 |
I thought I would try to hammer this out while waiting for the IFE() negotiations to complete. But now I'm not 100% sure what is needed here. You want a pragma that effectively adds the "L" suffix to any constant large enough to benefit? (Because you you didn't use the "L" suffix previously, and don't have any easy way of finding all of the existing constants where it should have been used?)
If that's right, then I propose:
++PRAGMA AUTO_LARGE_CONSTANTS
which would effectively add the "L" suffix to any constant integer large enough to to be at risk of exceeding the precision of F6 (and small enough to fit in 48 bits).
|
|
|
|
Re: L
#24050
14 Feb 19 12:49 PM
|
|
Anonymous
Unregistered
|
|
Anonymous
Unregistered
|
That sounds perfect. Thanks.
|
|
|
|
Re: L
#24051
15 Feb 19 07:16 PM
|
Joined: Jun 2001
Posts: 11,794
Jack McGregor
Member
|
|
Member
Joined: Jun 2001
Posts: 11,794 |
|
|
|
|
Re: L
#24052
16 Feb 19 12:30 PM
|
|
Anonymous
Unregistered
|
|
Anonymous
Unregistered
|
This seems to work nicely. Thank you 
|
|
|
|
Re: L
#24053
10 Mar 19 01:13 PM
|
Joined: Jun 2001
Posts: 11,794
Jack McGregor
Member
|
|
Member
Joined: Jun 2001
Posts: 11,794 |
Postscript from Herman... I'm so confused  My concern now is that since Jack asked about the size of pricing variables in the standard I have to work with, they changed it from s9(6)v99 to s9(9)v99. I have tried to change everything to I6 and b6 variables, but now have to go back thru the code and follow thru a ton of variables to be sure they all fit. Jack, I wish you hadn't asked! Will ife(a,b) do this for me? First off, for those of our readers not yet dependent on tapioca, perhaps we should point out that these weird symbols that Herman keeps referring to (e.g. S9(6)v99) are from an ancient language called COBOL and are something like our mask characters, except that they refer not just to the display format but to the storage format as well. S9(6)v99 means a leading sign, followed by (6) numeric digits, an implied decimal (v), and two more numeric digits. That's a mere 8 significant digits, well within F6 or B4/I4 capacity. The larger s9(9)v99 is 9+2=11 significant digits, still within F6 capability, particularly if you store it as an integer with the implied decimal point. But it is beyond B4/I4. The 9(7)v9(7) referenced earlier is 14 significant digits, beyond F6 capability (but still within B6/I6/F8). So I guess we need to get more specific about the problem. Obviously if you are storing any of these in 32 bit variables, you're going to have problems. But I've lost track of the exact situation you're worried. Why don't you give us a slightly more detailed example to chew on; I suspect that the exercise would be useful to multiple developers who are likely to be at risk of bumping into this problem themselves.
|
|
|
|
Re: L
#24054
11 Mar 19 01:11 PM
|
|
Anonymous
Unregistered
|
|
Anonymous
Unregistered
|
I had a lot typed in yesterday and clicked 'Preview Post' and lost it all  I'm working on software for pharmacies where there is a national standard for transmitting claims for prescriptions real time. The version of the claim is changing and one of the changes in it is to increase the dollar fields by 3 digits. The old format was s9(6)v99 and is now s9(9)v99. There is a standard for requests (sending a claim from the pharmacy to the insurer or who they hire to process their claims - payer) and a slightly different standard for the response (payer back to the pharmacy). I counted over 50 occurrences of a dollar variable in the request and stopped counting so there are probably 100 or so instances of this increased variable size. I know Jack didn't mean to imply that I was old using the format from COBOL, but it's what the standard uses. :rolleyes: The s9(6)v99 needed to be an I,4 variable to hold a value from -99999999 to 99999999. Now the value may be from -99999999999 to 99999999999. The I,4 variable will hold something like -2,147,483,648 thru 2,147,483,647 and we must increase the variable size. B,5 would hold this figure, but it makes sense to use Jack's new I,6 variable which will hold -140,737,488,355,328 thru 140,737,488,355,327. In the real world this would likely never happen but I have to be prepared for the testing process which will throw something like this at us. I have, over the past year or so had to increase file sizes for other reasons, and at the same time tried to change to b,6 and I,6 where I thought there was a chance of needing it in the future. Now the future is here. What I need to do is: 1. Make sure all dollar variables are mapped as I,6 in the claim (request and response) and in all files where they are stored. 2. Look thru all programs which reference any of these variables and make sure any temporary variables or those used in calculations are also mapped I,6. 3. Look at the way calculations are done so that I don't overflow my I,6 variable. If I have to, I will do a division first, then multiply. I'm sure I will find other thinks to look at while going thru the programs. The point is, while making any changes to files, I would go ahead and "upgrade" to the new b,6 and I,6. And Jack, when will the b,8 and I,8 or maybe even b,16 and I,16 variables be ready?
|
|
|
|
Re: L
#24055
11 Mar 19 01:47 PM
|
Joined: Jun 2001
Posts: 11,794
Jack McGregor
Member
|
|
Member
Joined: Jun 2001
Posts: 11,794 |
Sorry about your lost preview (but probably your second draft was more lucid and elegant than the first one).
For an old man, it sounds like you've got it figured out. The rest of us will be looking forward to your presentation on LARGE NUMBERS at the 2020 Conference.
In the meantime I'll think about B,8 and I,8. (The fundamental problem here is the expression stack design which handles all numbers as F,8. F,8 can faithfully represent 48 bit integers, but not 64 bit integers. So probably the solution will be to change the stack so that each value has a descriptor with it (allowing different numeric sizes/types to be commingled and converted as necessary during expression evaluation, sort of like it's done with parameter passing). It will add some overhead, but the bigger problem will just be the additional complexity in a critically central routine, meaning that it will require a lot of testing. It might also be very difficult to perfectly reproduce the idiosyncrasies of F,8 precision/rounding when some of the operands are switched from F,8 to integer format.
Then again, maybe Congress will come up with a way to constrain the virulent growth of pharmaceutical prices so that we don't have to invent mathematical techniques just to handle them! :rolleyes:
|
|
|
|
Re: L
#24056
11 Mar 19 01:56 PM
|
Joined: Nov 2006
Posts: 2,223
Stephen Funkhouser
Member
|
|
Member
Joined: Nov 2006
Posts: 2,223 |
Hi Herman, You may want to look at using DEFTYPE to standardize the variable definitions DEFTYPE PHAR_PRICE=I,4
MAP1 phar'price,PHAR_PRICE
FUNCTION fn'phar'price(pp as PHAR_PRICE) as PHAR_PRICE
...
ENDFUNCTION
Stephen Funkhouser
Diversified Data Solutions
|
|
|
|
Re: L
#24057
11 Mar 19 01:56 PM
|
|
Anonymous
Unregistered
|
|
Anonymous
Unregistered
|
I,8 and B,8 would be nice, but I don't think it's worth the potential problems and heartache it would cause you.
|
|
|
|
Re: L
#24058
11 Mar 19 01:57 PM
|
|
Anonymous
Unregistered
|
|
Anonymous
Unregistered
|
Good thought, Stephen. Thanks.
|
|
|
|
Re: L
#24059
11 Mar 19 01:58 PM
|
|
Anonymous
Unregistered
|
|
Anonymous
Unregistered
|
Good thought, Stephen. Thanks.
|
|
|
|
Re: L
#24060
11 Mar 19 02:36 PM
|
Joined: Jun 2001
Posts: 11,794
Jack McGregor
Member
|
|
Member
Joined: Jun 2001
Posts: 11,794 |
Excellent thought!
One of the things you missed at the last Conference was a discussion about "Dynamic Data Sources" which built on the idea of using DEFTYPEs for all your data as a means not only of standardizing the internal format but also the display format and potentially other attributes (editing rules, etc.) associated with each type.
For example, in your case, even though your plan might be to change all of the price-related fields to I6, it might make sense to use different DEFTYPE names to identify the display formatting and/or other distinctions so that you could later create generic routines (ideally with lots of IFE(a,b) expressions!) that were informed by the data type name.
If you're in the process of reviewing all your data, this might be a good time to consider assigning DEFTYPEs to everything.
|
|
|
|
Re: L
#24061
11 Mar 19 04:20 PM
|
|
Anonymous
Unregistered
|
|
Anonymous
Unregistered
|
I'll look at that. Thanks guys.
|
|
|
|
Re: L
#24062
11 Mar 19 04:22 PM
|
|
Anonymous
Unregistered
|
|
Anonymous
Unregistered
|
By the way, I'll be glad to make that LARGE NUMBERS presentation at the 2019 conference :rolleyes:
|
|
|
|
Re: L
#24063
13 Mar 19 03:24 PM
|
|
Anonymous
Unregistered
|
|
Anonymous
Unregistered
|
Stephen, in creating a new file and writing functions to handle several things in that new file, I was worried about forgetting to change the variable sizes being passed to these functions because I was playing around with the sizes. So I tried. deftype rxqual_file_type = s, 2
deftype rxqual_rec_num = s, 20
deftype rxqual_qual_type = s, 10
deftype rxqual_qual = s, 20
defstruct rxqual_structure
map2 rec'type, s, 2
map2 file'type, rxqual_file_type
map2 rec'num, rxqual_rec_num
map2 qual'type, rxqual_qual_type
map2 qual, rxqual_qual
map2 qual'value, s, 60
map2 fill, s, 142
endstruct
…
…
function fn'get'all'rxqual(get'rxqual'rec() as rxqual_structure, &
local'file'type as rxqual_file_type:inputonly, &
local'rec'num as rxqual_rec_num:inputonly, &
local'qual'type as rxqual_qual_type:inputonly) as f8Great feature. Thanks to you and Jack. I sure hope I can come to the 2019 conference By the way, when I clicked add post, it again lost the post. At least this time I had it copied.
|
|
|
|
Re: L
#24064
13 Mar 19 03:26 PM
|
|
Anonymous
Unregistered
|
|
Anonymous
Unregistered
|
Stephen, in creating a new file and writing functions to handle several things in that new file, I was worried about forgetting to change the variable sizes being passed to these functions because I was playing around with the sizes. So I tried. deftype rxqual_file_type = s, 2
deftype rxqual_rec_num = s, 20
deftype rxqual_qual_type = s, 10
deftype rxqual_qual = s, 20
defstruct rxqual_structure
map2 rec'type, s, 2
map2 file'type, rxqual_file_type
map2 rec'num, rxqual_rec_num
map2 qual'type, rxqual_qual_type
map2 qual, rxqual_qual
map2 qual'value, s, 60
map2 fill, s, 142
endstruct
…
…
function fn'get'all'rxqual(get'rxqual'rec() as rxqual_structure, &
local'file'type as rxqual_file_type:inputonly, &
local'rec'num as rxqual_rec_num:inputonly, &
local'qual'type as rxqual_qual_type:inputonly) as f8Great feature. Thanks to you and Jack. I sure hope I can come to the 2019 conference
|
|
|
|
Re: L
#24065
13 Mar 19 03:26 PM
|
|
Anonymous
Unregistered
|
|
Anonymous
Unregistered
|
Very strange things going on
|
|
|
|
Re: L
#24066
13 Mar 19 03:41 PM
|
Joined: Jun 2001
Posts: 11,794
Jack McGregor
Member
|
|
Member
Joined: Jun 2001
Posts: 11,794 |
Judging from the duplicate posts, I'm beginning to suspect that you only think something went wrong with the first post.
But it doesn't look like there is anything wrong with your understanding of the DEFTYPE feature.
Now you just need to master the DYNSTRUCT and Dynamic Functions features and you'll be able to dynamically extract those new types from your map layouts and use them to dynamically evaluate and call corresponding functions for formatting/editing/validating/etc those types.
|
|
|
|
Re: L
#24067
14 Mar 19 10:04 AM
|
|
Anonymous
Unregistered
|
|
Anonymous
Unregistered
|
You can bring me up to date at the 2019 conference :rolleyes:
By the way, when I clicked add post the first time, it immediately came back to the New Topic screen with the Title line. All was empty. So I went back and entered the reply again.
|
|
|
|
Re: L
#24068
14 Mar 19 10:07 AM
|
|
Anonymous
Unregistered
|
|
Anonymous
Unregistered
|
You can bring me up to date at the 2019 conference :rolleyes:
|
|
|
|
Re: L
#24069
14 Mar 19 10:08 AM
|
|
Anonymous
Unregistered
|
|
Anonymous
Unregistered
|
And something strange just happened again!
|
|
|
|
Re: L
#24070
14 Mar 19 11:02 AM
|
Joined: Jun 2001
Posts: 11,794
Jack McGregor
Member
|
|
Member
Joined: Jun 2001
Posts: 11,794 |
I haven't seen that problem. Maybe it's some kind of browser incompatibility? (I'm typically using Firefox or Chrome - what are you using?)
|
|
|
|
Re: L
#24071
14 Mar 19 11:14 AM
|
|
Anonymous
Unregistered
|
|
Anonymous
Unregistered
|
I'm using Edge but nothing has changed for 3-4 years. Let's chalk it up to my tapioca induced stupor for the time being and I'll keep a closer watch on it.
|
|
|
|
Re: L
#24072
14 Mar 19 03:55 PM
|
Joined: Sep 2002
Posts: 5,471
Frank
Member
|
|
Member
Joined: Sep 2002
Posts: 5,471 |
Like Deja vu all over again PS: So is Herman volunteering to have an odd-year conference this year at his plantation? Perhaps a mea-culpa for dissing the last one? Sign me up and of course I'll bring the tapioca!
|
|
|
|
Re: L
#24073
15 Mar 19 11:52 AM
|
Joined: Sep 2003
Posts: 4,158
Steve - Caliq
Member
|
|
Member
Joined: Sep 2003
Posts: 4,158 |
I always wondered who the 1 Microsoft Edge user was.. :rolleyes: :rolleyes:
|
|
|
|
Re: L
#24074
15 Mar 19 12:39 PM
|
Joined: Jun 2001
Posts: 11,794
Jack McGregor
Member
|
|
Member
Joined: Jun 2001
Posts: 11,794 |
In the immortal words of Bill Nye the Science Guy... NOW-owww You KNOW-ohhhh! :p
|
|
|
|
Re: L
#24075
15 Mar 19 12:52 PM
|
|
Anonymous
Unregistered
|
|
Anonymous
Unregistered
|
I dissed the last one under duress! Well, maybe I'll see y'all in 2020 and not 2019! :rolleyes:
|
|
|
|
Re: L
#24076
15 Mar 19 03:02 PM
|
Joined: Sep 2002
Posts: 5,471
Frank
Member
|
|
Member
Joined: Sep 2002
Posts: 5,471 |
Was it the tapioca?! OK OK i won't bring any tapioca! Can we still meet up at your plantation?
|
|
|
|
Re: L
#24077
15 Mar 19 03:12 PM
|
|
Anonymous
Unregistered
|
|
Anonymous
Unregistered
|
|
|
|
|
Re: L
#24078
08 Apr 19 12:37 PM
|
|
Anonymous
Unregistered
|
|
Anonymous
Unregistered
|
Thought I would bring you up to date on my Large number conversion. I failed to think about the masks and xtree columns that had to be increased which turned out to be the most involved thing in the conversion. Also reports needed more room for the extremely high priced drugs that I will be dispensing.
I did find one dollar field that had been increased to s9(12)v99 which will fit nicely into an i,6 variable. No calculations are done on this variable, so we're in good shape.
I was fortunate in that over the period of time since you introduced the b,6 and i,6 variables, we had to restructure a lot of files and the change to the dollar and quantity fields in the files had already been made. Also all temporary variables had been changed.
Hope they don't make any more changes before naming this version as the one to release next. If so, we're good for another 10 years!
Thanks Jack
|
|
|
|
Re: L
#24079
08 Apr 19 01:15 PM
|
Joined: Jun 2001
Posts: 11,794
Jack McGregor
Member
|
|
Member
Joined: Jun 2001
Posts: 11,794 |
By then, AOC will be President will have nationalized the drug companies, forcing you to reformat all of those fields again (to handle the MUCH SMALLER dollar amounts). :p
|
|
|
|
|
