Re: [fpc-pascal] best method: multiple three state options in a decision tree
On 21/01/14 18:42, waldo kitty wrote:
> On 1/21/2014 10:21 AM, Mattias Gaertner wrote:
>> On Tue, 21 Jan 2014 09:51:38 -0500
>> waldo kitty wrote:
>>
>>> On 1/18/2014 7:40 PM, waldo kitty wrote:
what is the best method of coding a decision tree with options that have
three
states and all options are additive?
clarification: i have a situation with 5 (at this time) options and all 5
are
three state... each option can be paired with all other options' states
but may
NOT be paired with its own other states...
>>> [...]
>>>
>>> no one has any ideas or thoughts on this?
>>
>> Maybe I don't understand the question.
>
> that's quite possible... it took me a while to write it the way i did
> after starting over numerous times... i may have also used the wrong
> terms for what i was trying to describe as well as not giving enough
> examples but the example list was getting too large at that point
> anyway ;)>
>> The 5 options with each 3 states sounds like an array[1..5] of TRedGreenBlue.
^This
>
> a lot of stuff i googled up related to 3states came up with
> similar... to me that reads as to be used for graphics and this is a
> console app with no graphics involved... i'm only using the bits to
> denote the combinations available... they select which IF statement
> is used in the actual filter code described below...>
> originally i had thought of using an array but i didn't know the size
> of it and each grouping varies with the number of options...>
>> What do you mean with "additive"
>
> logical AND with some combinations being invalid...
>
> eg:
> optionA:min/max {solitary}
> optionB:max only AND optionE:min only {two ANDed together}
> optionA:min only AND optionB:min/max AND optionC:max only {three ANDed
> together}
>
> optionA:min/max AND optionA:min only {invalid}
> optionA:min/max AND optionA:max only {invalid}
> optionA:min only AND optionA:max only {invalid}
>
and ^this
[...]
> the current idea is to use a bit for each "state" and then use a case
> statement for the "decision tree" (as shown above) so as to simply
> walk thru the integers that the bit patterns make for the valid
> combinations...>
^and this...
looks like a (good?) use for a dynamic array of TMinMaxState = [mmNone, mmMin,
mmMinMax, mmMax];
(then var Options = array[static or dynamic] of TMinMaxState;)
This assumes options have a fixed position in the array however... but the
bitwise code was
assuming this anyway.
And yes, 4 states - one of them being mmNone - for the case when you don't want
to use certain option.
If there is a lot of options, but not always consecutive - so there would be a
lot more of mmNone's
than significant states (IOW the data is sparse) - maybe do
TOption = record
Index : [whatever type would suffice here];
State : TMinMaxState; // [which could then be 3 state not 4]
end;
and use a dynamic array to hold the TOption(s).
Excuse my lameness please :) as I am not a programmer by trade.
-L.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Winsock problems on trunk: rtl-extra?
FPC trunk x86, windows. Warning: fiddling newb alert. I have a unit httpclient that apparently uses winsock2: 3rdparty\httpclient.pas(0,0) Fatal: Can not find unit WinSock2 used by Sockets. Temporarily adding this to the other unit files (-Fu) in Lazarus ;$(fpcsrcdir)\packages\rtl-extra\src\win fixed that but now the packages\rtl-extra\src\win\sockets.pp unit cannot find socketsh.inc which indeed is not present in that directory but in \rtl\inc\socketsh.inc Does the FPC make files need some more adjustments... or do I need to make them ;) Thanks, Reinier ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] best method: multiple three state options in a decision tree
On 1/22/2014 3:52 AM, Lukasz Sokol wrote:
[...]
^and this...
looks like a (good?) use for a dynamic array of TMinMaxState = [mmNone, mmMin,
mmMinMax, mmMax];
(then var Options = array[static or dynamic] of TMinMaxState;)
This assumes options have a fixed position in the array however... but the
bitwise code was
assuming this anyway.
ok so basically converting 16 bits storage into an array? currently only 15 bits
are being used and i don't know that any more will be added... but i'm not
seeing how to add (logical AND) them together for
optionA:mmMin AND optionC:mmMinMax
and similar up to all five basic ones as
A:mmMin AND B:mmMax AND C:mmMinMax AND D:mmMax AND E:mmMin
And yes, 4 states - one of them being mmNone - for the case when you don't want
to use certain option.
yes, i've basically been ignoring mmNone because all the bits are off so we just
skip over it in the ANDing code
If there is a lot of options, but not always consecutive - so there would be a
lot more of mmNone's
than significant states (IOW the data is sparse) -
yes, with what i have done, there are 1023 valid combination... 1024 if we count
all options off (or mmNone)... that's out of 32767 combinations where the
majority are invalid... it is no wonder, with 1023 combinations, that i got
lost/confused with my first attempt using if/then/else and while trying to
manually implement the bitmap CASE code...
maybe do
TOption = record
Index : [whatever type would suffice here];
State : TMinMaxState; // [which could then be 3 state not 4]
end;
and use a dynamic array to hold the TOption(s).
as above, i'm not seeing how to AND each valid set together for later use in the
filtering code :?
Excuse my lameness please :) as I am not a programmer by trade.
no problems... i'm looking for ideas and input for handling items like this... i
appreciate any input on this...
it would seem that things like this would come up a lot and that there would
already be a class or possibly an object that one could feed the settings array
to with the options that hold each array and then to be able to walk thru like
one can do with TStringsList
eg: fooList:TStringsList;
[...]
fooList[i]:='blah';
[...]
writeln(fooList[i]);
i actually did look at the TBits class but didn't see an easy way of walking it
like one can do with TStringsList... my finding and looking at TBits was after
some 12+ hours of manually coding if/then/else, getting lost in the details and
starting over numerous times...
what i finally did with my current attempt using a bitmapped word was to write a
tool to generate all the code for the case statement... with this i was able to
1] find out how many valid combinations there are (1023)
2] have the ANDs all written in the proper order for each valid bitmask
3] generate a file that is easily included {$I bitcase.inc}
any changes to the ordering need only a small rewrite to the generating tool to
create the new CASE code for the filter... the resulting include file is only
(!) 392353 bytes at 7932 lines with no comment lines... that's ~3x the size of
the program's .pas file of 119151 bytes at 3157 lines with a few hundred comment
lines...
this current implementation is used for output filtering... there's going to be
an exact duplicate used for input selection with the only difference between the
two CASE code blocks being the routine called on a match...
eg:
case FilterBits of
0 : writeoutput;
1 : begin
if (rec^.optionA >= optionA_min) and (rec^.optionA <= optionA_max) then
writeoutput;
end;
2 : begin
if (rec^.optionA >= optionA_min) then
writeoutput;
end;
3 : begin {invalid} end;
4 : begin
if (rec^.optionA >= optionA_max) then
writeoutput;
end;
[...]
case SelectBits of
0 : addItem;
1 : begin
if (rec^.optionA >= optionA_min) and (rec^.optionA <= optionA_max) then
addItem;
end;
2 : begin
if (rec^.optionA >= optionA_min) then
addItem;
end;
3 : begin {invalid} end;
4 : begin
if (rec^.optionA >= optionA_max) then
addItem;
end;
[...]
i think i should be able to use one routine for both input selection and output
filtering... done by pass the bitmap and the routine to be used... that'll save
having to worry about editing in more than one place when things change... i
just gotta figure out how to pass the routine to use...
would something like:
procedure runCase(var bitMap:word; whichProcedure: pointer);
called with
runCase(SelectBits,@addItem);
runCase(FilterBits,@writeoutput);
be the way to do this??
sometimes my linear procedural mind really gets in the way :/
--
NOTE: No off-list assistance is given without prior approval.
Please keep mailing list traffic on the list unless
private contact is specifically requested and granted.
Re: [fpc-pascal] Winsock problems on trunk: rtl-extra?
Am 22.01.2014 16:13, schrieb Reinier Olislagers: FPC trunk x86, windows. Warning: fiddling newb alert. I have a unit httpclient that apparently uses winsock2: 3rdparty\httpclient.pas(0,0) Fatal: Can not find unit WinSock2 used by Sockets. Temporarily adding this to the other unit files (-Fu) in Lazarus ;$(fpcsrcdir)\packages\rtl-extra\src\win fixed that but now the packages\rtl-extra\src\win\sockets.pp unit cannot find socketsh.inc which indeed is not present in that directory but in \rtl\inc\socketsh.inc Does the FPC make files need some more adjustments... or do I need to make them ;) Should now be fixed in revision 26564. :) Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Winsock problems on trunk: rtl-extra?
On 22/01/2014 17:05, Sven Barth wrote: > Am 22.01.2014 16:13, schrieb Reinier Olislagers: >> Does the FPC make files need some more adjustments... or do I need to >> make them ;) > Should now be fixed in revision 26564. :) > Thanks a lot Sven, works perfectly! ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] best method: multiple three state options in a decision tree
On 22/01/14 15:51, waldo kitty wrote:
> On 1/22/2014 3:52 AM, Lukasz Sokol wrote:
> [...]
>> ^and this...
>> looks like a (good?) use for a dynamic array of TMinMaxState = [mmNone,
>> mmMin, mmMinMax, mmMax];
>> (then var Options = array[static or dynamic] of TMinMaxState;)
>>
>> This assumes options have a fixed position in the array however... but the
>> bitwise code was
>> assuming this anyway.
>
> ok so basically converting 16 bits storage into an array? currently
> only 15 bits are being used and i don't know that any more will be
> added... but i'm not seeing how to add (logical AND) them together
> for
>
> optionA:mmMin AND optionC:mmMinMax
>
> and similar up to all five basic ones as
>
> A:mmMin AND B:mmMax AND C:mmMinMax AND D:mmMax AND E:mmMin
>
>> And yes, 4 states - one of them being mmNone - for the case when you don't
>> want to use certain option.
If you insist on using bits define them:
const
OptionAmmMin = $0001;
OptionAmmMinMax = $0002;
OptionAmmMax = $0004; // and so on
then do
if Options and (OptionAmmMin and ... ) then
?
I would have thought, that having an array of TOption like I wrote, would
ensure the exclusivity.
And having the array dynamic, you can check for its size, then write some
clever code to use it ;)
>
> yes, i've basically been ignoring mmNone because all the bits are off so we
> just skip over it in the ANDing code
>
>> If there is a lot of options, but not always consecutive - so there would be
>> a lot more of mmNone's
>> than significant states (IOW the data is sparse) -
>
> yes, with what i have done, there are 1023 valid combination... 1024
> if we count all options off (or mmNone)... that's out of 32767
> combinations where the majority are invalid... it is no wonder, with
> 1023 combinations, that i got lost/confused with my first attempt
> using if/then/else and while trying to manually implement the bitmap
> CASE code...
If you count permutations (so combinations not repeating) you'd have 120 valid
ones...?
http://easycalculation.com/statistics/permutation-combination.php
do I understand that correctly?
>> maybe do
>>
>> TOption = record
>>Index : [whatever type would suffice here];
>>State : TMinMaxState; // [which could then be 3 state not 4]
>> end;
>>
>> and use a dynamic array to hold the TOption(s).
>
> as above, i'm not seeing how to AND each valid set together for later use in
> the filtering code :?
>
>> Excuse my lameness please :) as I am not a programmer by trade.
>
> no problems... i'm looking for ideas and input for handling items like
> this... i appreciate any input on this...
>
> it would seem that things like this would come up a lot and that
> there would already be a class or possibly an object that one could
> feed the settings array to with the options that hold each array and
> then to be able to walk thru like one can do with TStringsList
>
> eg: fooList:TStringsList;
> [...]
> fooList[i]:='blah';
> [...]
> writeln(fooList[i]);
>
> i actually did look at the TBits class but didn't see an easy way of
> walking it like one can do with TStringsList... my finding and
> looking at TBits was after some 12+ hours of manually coding
> if/then/else, getting lost in the details and starting over numerous
> times...
>
> what i finally did with my current attempt using a bitmapped word was
> to write a tool to generate all the code for the case statement...
> with this i was able to
> 1] find out how many valid combinations there are (1023)
> 2] have the ANDs all written in the proper order for each valid bitmask
> 3] generate a file that is easily included {$I bitcase.inc}
>
> any changes to the ordering need only a small rewrite to the
> generating tool to create the new CASE code for the filter... the
> resulting include file is only (!) 392353 bytes at 7932 lines with no
> comment lines... that's ~3x the size of the program's .pas file of
> 119151 bytes at 3157 lines with a few hundred comment lines...
>
> this current implementation is used for output filtering... there's
> going to be an exact duplicate used for input selection with the only
> difference between the two CASE code blocks being the routine called
> on a match...
> eg:
> case FilterBits of
> 0 : writeoutput;
> 1 : begin
> if (rec^.optionA >= optionA_min) and (rec^.optionA <= optionA_max)
> then
> writeoutput;
> end;
> 2 : begin
> if (rec^.optionA >= optionA_min) then
> writeoutput;
> end;
> 3 : begin {invalid} end;
> 4 : begin
> if (rec^.optionA >= optionA_max) then
> writeoutput;
> end;
> [...]
>
>
> case SelectBits of
> 0 : addItem;
> 1 : begin
> if (rec^.optionA >= optionA_min) and (rec^.optionA <= optionA_max)
> then
> addItem;
> end;
> 2 : begin
> if (rec^.optionA >= optionA_min) then
> addItem;
> end;
> 3 : begin {invalid} end;
> 4 : begin
> if (
Re: [fpc-pascal] Strange message about mixed signed expression
Am 2014-01-22 07:41, schrieb leledumbo: Jürgen Hestermann wrote Realy? But why that? It cannot be negative. Using integer instead of unsigned values reduces the possible (positive) range and produces such illogical (to me) compiler warnings. Delphi compatibility and maximum data size limitation AFAIK (2 GB). Sigh... all the bad things in FPC crept in from Delphi it seems... Why did they artifically limit the max number of array elements to 2^31when it would have been very easy to have a maximum of 2^32 instead? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Strange message about mixed signed expression
Am 22.01.2014 19:00, schrieb Jürgen Hestermann: > > Am 2014-01-22 07:41, schrieb leledumbo: >> Jürgen Hestermann wrote >>> Realy? >>> But why that? >>> It cannot be negative. >>> Using integer instead of unsigned values reduces the possible (positive) >>> range >>> and produces such illogical (to me) compiler warnings. >> Delphi compatibility and maximum data size limitation AFAIK (2 GB). >> > > Sigh... all the bad things in FPC crept in from Delphi it seems... ... which is not true in this case. - The unsigned types are something very unpascalish. - Extended Pascal defines the result of length as integer - Expressions like length(s)-1 are very common and would cause a lot of trouble if length(s) would be unsigned. > > Why did they artifically limit the max number of array elements to 2^31when > it would have been very easy to have a maximum of 2^32 instead? It is even easier to use a 64 bit OS in this case. Even more having a data segment >2 GB might be a problem for 32 Bit OSes. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Strange message about mixed signed expression
On 22.01.2014 19:00, Jürgen Hestermann wrote: Am 2014-01-22 07:41, schrieb leledumbo: Jürgen Hestermann wrote Realy? But why that? It cannot be negative. Using integer instead of unsigned values reduces the possible (positive) range and produces such illogical (to me) compiler warnings. Delphi compatibility and maximum data size limitation AFAIK (2 GB). Sigh... all the bad things in FPC crept in from Delphi it seems... Why did they artifically limit the max number of array elements to 2^31when it would have been very easy to have a maximum of 2^32 instead? You have to think back at that time. 64-bit was in the far future, on Windows you only had 2 GB RAM available to user mode (the 3GB switch was added with XP AFAIK). So you *could not* allocate more than 2 GB of RAM even if you wanted to. And you couldn't even reach that, because you still have other memory in use by the RTL. The rest is history... Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] best method: multiple three state options in a decision tree
On 1/22/2014 12:12 PM, Lukasz Sokol wrote:
[...]
If you insist on using bits define them:
it isn't that i'm insisting on using them... more the way that my linear mind
sees them... i'm trying to change this if it affords me better code that is
easier to read, understand and modify...
const
OptionAmmMin = $0001;
OptionAmmMinMax = $0002;
OptionAmmMax = $0004; // and so on
this is pretty much already being done by the code using SetBIT and GetBIT
then do
if Options and (OptionAmmMin and ... ) then
this is where the CASE "decision tree" comes in with each CASE having the
necessary if/then filtering of the data record at hand...
I would have thought, that having an array of TOption like I wrote, would
ensure the exclusivity.
And having the array dynamic, you can check for its size, then write some
clever code to use it ;)
it may very well but as i wrote, i cannot visualize it in my mind's eye :(
yes, i've basically been ignoring mmNone because all the bits are off so we
just skip over it in the ANDing code
If there is a lot of options, but not always consecutive - so there would be a
lot more of mmNone's
than significant states (IOW the data is sparse) -
yes, with what i have done, there are 1023 valid combination... 1024
if we count all options off (or mmNone)... that's out of 32767
combinations where the majority are invalid... it is no wonder, with
1023 combinations, that i got lost/confused with my first attempt
using if/then/else and while trying to manually implement the bitmap
CASE code...
If you count permutations (so combinations not repeating) you'd have 120 valid
ones...?
http://easycalculation.com/statistics/permutation-combination.php
do I understand that correctly?
there are 1023 permutations of the 32767 possible... that means that i have to
have 1023 (1024 counting no options set) case selectors... each with their
specific if/then to check the current data record for a match...
[...]
i think i should be able to use one routine for both input selection
and output filtering... done by pass the bitmap and the routine to be
used... that'll save having to worry about editing in more than one
place when things change... i just gotta figure out how to pass the
routine to use...>
would something like:
procedure runCase(var bitMap:word; whichProcedure: pointer);
called with
runCase(SelectBits,@addItem);
runCase(FilterBits,@writeoutput);
be the way to do this??
sometimes my linear procedural mind really gets in the way :/
Huh, well a lot of micro-management goes on here;
possibly ;) but i don't know...
What if you did it like:
- define the valid bit masks (permutations?) at the start, dynamically
humm... my tool that generates the CASE statement does something like this... i
might be able to adapt it... /BUT/ i still have to match the data records with
the current permutation selected when the program is executed... don't i??
eg:
myprogram --optionA=-1,145 --optionD=30,40
on execution, GetOption('optionA') loads the values from the optionA command
line parameter... any value less than zero means to ignore that "slot"... all
other numbers are valid...
the above "--optionA=-1,145" results in the optionA_MAX bit being set (
0010) and storing the value of 145 in optA_MAX...
the above "--optionD=30,40" results in the optionD_MINMAX bit (0010
), storing the value of 30 in optD_MIN, and storing the value of 40 in
optD_MAX...
ANDing the bitmasks together we have 0010 0010 which is 514 in
decimal... this is the case selector value used later for output filtering (and
future input selecting)...
then the program loads all of the data records it finds in all of the default
files... currently this is some 3 records from some 80+ files updated
nightly... as the data is loaded, it is merged and updated so there are no
duplicates records and all records have the most current, by date and time,
information in them...
after all the merging and updating, we start with the first record and run
through all of them writing them to the output file... if there are no options
specified on the command line, then all the records are written... in this
example, only the records matching the values given for the two options will be
written to the output file... currently, that's
514 : begin // 0010 0010
if (Rec^.optA <= optA_MAX) and
(Rec^.optD >= optD_MIN) and (Rec^.optD <= optD_MAX) then
writeoutput;
end;
if you can explain to me how using the arrays would work so that i can visualize
it like the above, then i can try to implement it... however, i can't see any
way to bypass the huge CASE statement and its IF comparisons of the data in each
record... how would using the arrays allow me to do that?
- associate the procedures (their pointers) to jump to with the valid bit masks
in a new data type
(- do you REALLY have
Re: [fpc-pascal] Strange message about mixed signed expression
On 1/22/2014 1:00 PM, Jürgen Hestermann wrote: Am 2014-01-22 07:41, schrieb leledumbo: Jürgen Hestermann wrote Realy? But why that? It cannot be negative. Using integer instead of unsigned values reduces the possible (positive) range and produces such illogical (to me) compiler warnings. Delphi compatibility and maximum data size limitation AFAIK (2 GB). Sigh... all the bad things in FPC crept in from Delphi it seems... it goes back much further than that... IIRC, Turbo Pascal was the first to introduce the string type... i don't remember if it was in TP1 or TP2... i do know if it was in TP3 because i was using them in my code then... Why did they artifically limit the max number of array elements to 2^31when it would have been very easy to have a maximum of 2^32 instead? 64k stack limitation is the first thing that comes to mind... the string type is/was a 256 character array with the 0th (zero-th) element containing the length of the string... this allowed one to immediately know how many characters to read at once... it was much faster than iterating thru the array looking for a nul byte as done in other languages... it was quite innovative at the time and actually lead to the Hudson Message Base format being developed by Adam Hudson of QuickBBS fame when he was in high school (grades 10-12)... this message base format was the greatest thing since sliced bread when it came out and many other BBS packages adopted it because of its amazing speed and the large number of messages that could be stored with it... 255 maximum areas 32k total messages 16M maximum size of message data file in the days of 10M and new 20M hard drives, this was huge and message oriented BBSes sprung up all over the world along with evolving message oriented store and forward packet networks like fidonet, WWIVNet, RIME/PCRelay and others... all because of the string type ;) -- NOTE: No off-list assistance is given without prior approval. Please keep mailing list traffic on the list unless private contact is specifically requested and granted. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Strange message about mixed signed expression
2014/1/22 waldo kitty > the string type is/was a 256 character array with the 0th (zero-th) > element containing the length of the string... this allowed one to > immediately know how many characters to read at once... it was much faster > than iterating thru the array looking for a nul byte as done in other > languages... > > it was quite innovative at the time and actually lead to the Hudson > Message Base format being developed by Adam Hudson of QuickBBS fame when he > was in high school (grades 10-12)... this message base format was the > greatest thing since sliced bread when it came out and many other BBS > packages adopted it because of its amazing speed and the large number of > messages that could be stored with it... > What was innovative? Storing the length as byte 0? I believe old Basic had been doing it for years before. Basic is not a language I like, but still... -- Frederic Da Vitoria (davitof) Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Strange message about mixed signed expression
On 1/22/2014 5:39 PM, Frederic Da Vitoria wrote: 2014/1/22 waldo kitty mailto:wkitt...@windstream.net>> the string type is/was a 256 character array with the 0th (zero-th) element containing the length of the string... this allowed one to immediately know how many characters to read at once... it was much faster than iterating thru the array looking for a nul byte as done in other languages... it was quite innovative at the time and actually lead to the Hudson Message Base format being developed by Adam Hudson of QuickBBS fame when he was in high school (grades 10-12)... this message base format was the greatest thing since sliced bread when it came out and many other BBS packages adopted it because of its amazing speed and the large number of messages that could be stored with it... What was innovative? the type, itself... it did not exist previously and if there was anything like it, it was written specially by coders needing... this is likely how it came to be included, too... i simply do not recall since that was what? some 35+ years ago? Storing the length as byte 0? I believe old Basic had been doing it for years before. Basic is not a language I like, but still... i don't know how BASIC (which BASIC??) did it... each implementation, like the various pascals, could do things their own way behind the scenes as long as the results were the same... witness FPC with what it does to achieve the same results as other pascal languages ;) as for not liking BASIC, when i found TP and actually learned ASM, i left BASIC in the dust and never looked back... when i had to start writing dBase II code, it was like a huge step backwards to BASIC for me... i tended to write my dBase II code like i did my pascal code... going as low level as i could... oh well... that was then and dBase is not even around any more AFAIK... -- NOTE: No off-list assistance is given without prior approval. Please keep mailing list traffic on the list unless private contact is specifically requested and granted. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
