Menu
▾
▴
geniustrader-devel — participate in geniustrader development, ask for help, suggest improvements, etc
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(32) |
Oct
(144) |
Nov
(14) |
Dec
(44) |
| 2002 |
Jan
(16) |
Feb
|
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
(65) |
Nov
(4) |
Dec
(30) |
| 2003 |
Jan
(84) |
Feb
(101) |
Mar
(58) |
Apr
(30) |
May
(138) |
Jun
(336) |
Jul
(36) |
Aug
(12) |
Sep
(8) |
Oct
(4) |
Nov
(12) |
Dec
(12) |
| 2004 |
Jan
(186) |
Feb
(274) |
Mar
(248) |
Apr
(18) |
May
(104) |
Jun
(48) |
Jul
(144) |
Aug
(98) |
Sep
(60) |
Oct
(72) |
Nov
(32) |
Dec
(130) |
| 2005 |
Jan
(84) |
Feb
(130) |
Mar
(50) |
Apr
(106) |
May
(240) |
Jun
(154) |
Jul
(66) |
Aug
(82) |
Sep
(36) |
Oct
(18) |
Nov
(14) |
Dec
(4) |
| 2006 |
Jan
(68) |
Feb
(2) |
Mar
(14) |
Apr
(6) |
May
|
Jun
|
Jul
|
Aug
(2) |
Sep
|
Oct
|
Nov
(50) |
Dec
(4) |
| 2007 |
Jan
(14) |
Feb
(42) |
Mar
(70) |
Apr
(30) |
May
(8) |
Jun
|
Jul
(2) |
Aug
(2) |
Sep
|
Oct
(88) |
Nov
(168) |
Dec
(2) |
| 2008 |
Jan
(56) |
Feb
(372) |
Mar
(446) |
Apr
(112) |
May
(144) |
Jun
(94) |
Jul
(208) |
Aug
(90) |
Sep
(26) |
Oct
(10) |
Nov
(2) |
Dec
|
| 2009 |
Jan
|
Feb
(8) |
Mar
|
Apr
(46) |
May
(188) |
Jun
(120) |
Jul
(448) |
Aug
(202) |
Sep
(4) |
Oct
(72) |
Nov
(154) |
Dec
(2) |
| 2010 |
Jan
(58) |
Feb
|
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
(68) |
Aug
(24) |
Sep
|
Oct
|
Nov
|
Dec
(11) |
| 2011 |
Jan
(6) |
Feb
(11) |
Mar
(8) |
Apr
(10) |
May
(4) |
Jun
|
Jul
|
Aug
(8) |
Sep
|
Oct
(3) |
Nov
(2) |
Dec
|
| 2012 |
Jan
|
Feb
(13) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(31) |
Aug
(21) |
Sep
(2) |
Oct
(1) |
Nov
(29) |
Dec
(17) |
| 2013 |
Jan
(2) |
Feb
|
Mar
|
Apr
(25) |
May
(1) |
Jun
|
Jul
|
Aug
(1) |
Sep
(3) |
Oct
(4) |
Nov
(11) |
Dec
|
| 2016 |
Jan
(1) |
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2018 |
Jan
(3) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2019 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2020 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2023 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
(1) |
Oct
|
Nov
|
Dec
|
|
From: Eric L. <eri...@gm...> - 2011-04-23 19:26:39
|
Hi ras,
It works !!
Thank but with this part of code you can have 2 form :
% display_indicator.pl I:Generic:Divide --start date --end date T
'{I:Generic:Diff {I:EMA 30}} {I:Generic:PeriodAgo 1 {I:EMA 30}}}'
and this form
%display_indicator.pl --start date --end date "{I:Generic:Divide
{I:Generic:Diff {I:EMA 30}} {I:Generic:PeriodAgo 1 {I:EMA 30}}}}" T
in bash { is significant but
exactly the same indicator as for signal.
I am afraid to have work for nothing ;-)
Eric
2011/4/23 Robert A. Schmied <ra...@ac...>
> aloha eric
>
> while i don't really think this is the primary purpose for
> or of the display_*.pl scripts it can be done sorta kinda
> like this:
>
> % display_indicator.pl I:Generic:Divide --start date --end date
> T '{I:Generic:Diff {I:EMA 30}} {I:Generic:PeriodAgo 1 {I:EMA 30}}}'
>
> note in csh the '{' is significant and therefore must be escaped.
>
>
> if you cannot get this to work post a note of what you tried
> and i'll review etc.
>
> aloha
>
> ras
>
>
> Eric Lemesre wrote:
> > Hello,
> >
> > How can i display complexe indicator like
> > {I:Generic:Divide {I:Generic:Diff {I:EMA 30}}
> > {I:Generic:PeriodAgo 1 {I:EMA 30}}
> > }
> >
> > With the script display_indicator.pl ?
> >
> > I found a part of code to do this in
> > GT::Graphics::DataSource::GenericIndicatorResults
> >
> > # Create the indicator according to the arguments
> > my $indicator_module = shift || pod2usage(verbose => 2);
> > my $code = shift || pod2usage(verbose => 2);
> > my $indicator; # if it a complexe indicator
> >
> > # a complexe indicator ave { and }
> > if ($indicator_module =~ m/.*\{.*\}.*/) {
> >
> > # remove the last '}'
> > if (substr($indicator_module,length($indicator_module)-1,1) eq "}") {
> > $indicator_module =
> > substr($indicator_module,1,length($indicator_module)-2);
> > }
> > $indicator_module =~ /[\s|\{]*(.*)$/;
> >
> > my @function = split(/\s+/,$1);
> > $indicator = create_standard_object(@function);
> >
> > } else {
> > $indicator = create_standard_object("$indicator_module",@ARGV);
> > }
> >
> > With this code we can do this :
> > ./Scripts/display_indicator.pl --nb-item 25 --timeframe week "{I:G:Eval
> 100
> > * {I:Generic:Divide {I:Generic:Diff {I:EMA 30}} {I:Generic:PeriodAgo 1
> > {I:EMA 30}} }" AC
> >
> >
> >
> > ------------------------------------------------------------------------
> >
> >
> ------------------------------------------------------------------------------
> > Fulfilling the Lean Software Promise
> > Lean software platforms are now widely adopted and the benefits have been
> > demonstrated beyond question. Learn why your peers are replacing JEE
> > containers with lightweight application servers - and what you can gain
> > from the move. http://p.sf.net/sfu/vmware-sfemails
>
>
>
> ------------------------------------------------------------------------------
> Fulfilling the Lean Software Promise
> Lean software platforms are now widely adopted and the benefits have been
> demonstrated beyond question. Learn why your peers are replacing JEE
> containers with lightweight application servers - and what you can gain
> from the move. http://p.sf.net/sfu/vmware-sfemails
>
--
Cordialement
Eric Lemesre
GSM 06 76 85 59 40
|
|
From: Robert A. S. <ra...@ac...> - 2011-04-23 18:30:15
|
aloha eric
while i don't really think this is the primary purpose for
or of the display_*.pl scripts it can be done sorta kinda
like this:
% display_indicator.pl I:Generic:Divide --start date --end date
T '{I:Generic:Diff {I:EMA 30}} {I:Generic:PeriodAgo 1 {I:EMA 30}}}'
note in csh the '{' is significant and therefore must be escaped.
if you cannot get this to work post a note of what you tried
and i'll review etc.
aloha
ras
Eric Lemesre wrote:
> Hello,
>
> How can i display complexe indicator like
> {I:Generic:Divide {I:Generic:Diff {I:EMA 30}}
> {I:Generic:PeriodAgo 1 {I:EMA 30}}
> }
>
> With the script display_indicator.pl ?
>
> I found a part of code to do this in
> GT::Graphics::DataSource::GenericIndicatorResults
>
> # Create the indicator according to the arguments
> my $indicator_module = shift || pod2usage(verbose => 2);
> my $code = shift || pod2usage(verbose => 2);
> my $indicator; # if it a complexe indicator
>
> # a complexe indicator ave { and }
> if ($indicator_module =~ m/.*\{.*\}.*/) {
>
> # remove the last '}'
> if (substr($indicator_module,length($indicator_module)-1,1) eq "}") {
> $indicator_module =
> substr($indicator_module,1,length($indicator_module)-2);
> }
> $indicator_module =~ /[\s|\{]*(.*)$/;
>
> my @function = split(/\s+/,$1);
> $indicator = create_standard_object(@function);
>
> } else {
> $indicator = create_standard_object("$indicator_module",@ARGV);
> }
>
> With this code we can do this :
> ./Scripts/display_indicator.pl --nb-item 25 --timeframe week "{I:G:Eval 100
> * {I:Generic:Divide {I:Generic:Diff {I:EMA 30}} {I:Generic:PeriodAgo 1
> {I:EMA 30}} }" AC
>
>
>
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> Fulfilling the Lean Software Promise
> Lean software platforms are now widely adopted and the benefits have been
> demonstrated beyond question. Learn why your peers are replacing JEE
> containers with lightweight application servers - and what you can gain
> from the move. http://p.sf.net/sfu/vmware-sfemails
|
|
From: Eric L. <eri...@gm...> - 2011-04-23 18:06:12
|
Hello,
How can i display complexe indicator like
{I:Generic:Divide {I:Generic:Diff {I:EMA 30}}
{I:Generic:PeriodAgo 1 {I:EMA 30}}
}
With the script display_indicator.pl ?
I found a part of code to do this in
GT::Graphics::DataSource::GenericIndicatorResults
# Create the indicator according to the arguments
my $indicator_module = shift || pod2usage(verbose => 2);
my $code = shift || pod2usage(verbose => 2);
my $indicator; # if it a complexe indicator
# a complexe indicator ave { and }
if ($indicator_module =~ m/.*\{.*\}.*/) {
# remove the last '}'
if (substr($indicator_module,length($indicator_module)-1,1) eq "}") {
$indicator_module =
substr($indicator_module,1,length($indicator_module)-2);
}
$indicator_module =~ /[\s|\{]*(.*)$/;
my @function = split(/\s+/,$1);
$indicator = create_standard_object(@function);
} else {
$indicator = create_standard_object("$indicator_module",@ARGV);
}
With this code we can do this :
./Scripts/display_indicator.pl --nb-item 25 --timeframe week "{I:G:Eval 100
* {I:Generic:Divide {I:Generic:Diff {I:EMA 30}} {I:Generic:PeriodAgo 1
{I:EMA 30}} }" AC
--
Cordialement
Eric Lemesre
|
|
From: Robert A. S. <ra...@ac...> - 2011-03-31 02:39:47
|
Thomas Weigert wrote: > RAS, > > a major effort in the exp branch has been to make the various modules > more consistent. These changes have been available in the exp branch for > years. so what, this change is targeting the trunk not the exp branch. > > I would be extremely disappointed in a different, and potentially > inconsistent, change to be made to find_calculator which might break > applications I have been using for a long time. what can i say, sometimes things happen in life that result in disappointment. > > I do not understand why it took years of testing on the exp branch to > consider these important changes, while suddenly changes are rushed into > the system. again -- this change is targeting the trunk not the exp branch. nothing rushed about it, roman penieav took the time to figure out why --full and --end date don't work as one might expect and as the pod describes, at least by my reading. he also took the time to post his fix to -devel. i took the time to investigate the problem independently and posted my test cases and findings and indicated i'm inclined to make this change because it appears to solve a long standing problem at least on the trunk ... and now we are discussing the merits of the change but only to the trunk, not the exp branch. feelings, wishes, time factors and wants don't factor into merit, facts and findings do. > > I feel strongly that you should be examining the exp branch before > making any changes to this interface. well, i feel just as strongly the obligation to examine the exp branch and demonstrate it works without this particular change is yours and not mine; the exp branch is simply a don't care from my view point. as i've already shown the change corrects a long standing problem so i'm still inclined to (eventually) push it on the the trunk. aloha ras > > Best regards, Th. > <snip> |
|
From: Robert A. S. <ra...@ac...> - 2011-03-30 22:01:02
|
Weigert, Thomas wrote:
> RAS,
>
> please go over the exp patches related to find_calculator. These have
> been in use for years now and are well tested.
>
> We should not suddenly use different new formulations.
first off -- this change is targeting the trunk not the exp branch.
secondly if you think the exp branch has solved this defect provide
test results that demonstrate it.
otherwise i'm still included to make this change on the trunk.
regards
ras
>
> Thanks, Th.
>
> On 03/30/2011 05:29 PM, Robert A. Schmied wrote:
>
>>From: Roman Penieav <r.peniaev@gm...> - 2011-03-28 08:58
>>
>>>>2. GT_ARGS_PRIORITY.patch -
>>>>Seems to me --full argument must have more priority than nb-item,
>>>>i.e. without this patch any script with arguments `--full
>>>>--end=<some_date>`
>>>>outputs 200 default items, because default nb-item==200 has more
>>>>priority.
>>
>>gt'ers
>>
>>i'm inclined to accept this change to method GT::Tools::find_calculator
>>based on the following test conditions and cases:
>> with key 'Option::nb-item' unset in options file relying on default
>>
>> before making the change
>> % display_indicator.pl --option='DB::module=Text' \
>> --option='DB::Text::directory=../../sample_data' \
>> --full --end='1995-12-31' I:Prices 13000 > /var/tmp/di_13000.log
>> % wc /var/tmp/di_13000.log
>> 201 1004 10435 /var/tmp/di_13000.log
>> % head -3 /var/tmp/di_13000.log
>> Calculating indicator Prices[] ...
>> Prices[] [1995-03-06 00:00:00] = 12.3179
>> Prices[] [1995-03-07 00:00:00] = 11.9520
>> % tail -3 /var/tmp/di_13000.log
>> Prices[] [1995-12-27 00:00:00] = 12.7356
>> Prices[] [1995-12-28 00:00:00] = 12.9094
>> Prices[] [1995-12-29 00:00:00] = 12.8728
>>
>> after making the change
>> % display_indicator.pl --option='DB::module=Text' \
>> --option='DB::Text::directory=../../sample_data' \
>> --full --end='1995-12-31' I:Prices 13000 > /var/tmp/di_13000_2.log
>> % wc /var/tmp/di_13000_2.log
>> 737 3684 38307 /var/tmp/di_13000_2.log
>> % head -3 /var/tmp/di_13000_2.log
>> Calculating indicator Prices[] ...
>> Prices[] [1993-01-04 00:00:00] = 21.0989
>> Prices[] [1993-01-05 00:00:00] = 20.9770
>> % tail -3 /var/tmp/di_13000_2.log
>> Prices[] [1995-12-27 00:00:00] = 12.7356
>> Prices[] [1995-12-28 00:00:00] = 12.9094
>> Prices[] [1995-12-29 00:00:00] = 12.8728
>>
>>
>>please note your objections, if any.
>>
>>aloha
>>
>>ras
>>
>>
>>--- GT/Tools.pm (revision 709)
>>+++ GT/Tools.pm (working copy)
>>@@ -670,15 +670,15 @@
>> unless ($start) {
>> $first = $last - 2 * GT::DateTime::timeframe_ratio($YEAR,
>> $calc->current_timeframe);
>>+ $first = $last - $nb_item + 1 if ($nb_item);
>> $first = 0 if ($full);
>>- $first = $last - $nb_item + 1 if ($nb_item);
>> $first = 0 if ($first < 0);
>> }
>> unless ($last) {
>> $last = $first + 2 * GT::DateTime::timeframe_ratio($YEAR,
>> $calc->current_timeframe);
>>+ $last = $first + $nb_item - 1 if ($nb_item);
>> $last = $c - 1 if ($full);
>>- $last = $first + $nb_item - 1 if ($nb_item);
>> $last = $c - 1 if ($last >= $c);
>> }
>>
>>
>
>
|
|
From: Robert A. S. <ra...@ac...> - 2011-03-30 21:29:44
|
From: Roman Penieav <r.peniaev@gm...> - 2011-03-28 08:58
>
> >2. GT_ARGS_PRIORITY.patch -
>> Seems to me --full argument must have more priority than nb-item,
>> i.e. without this patch any script with arguments `--full --end=<some_date>`
>> outputs 200 default items, because default nb-item==200 has more priority.
gt'ers
i'm inclined to accept this change to method GT::Tools::find_calculator
based on the following test conditions and cases:
with key 'Option::nb-item' unset in options file relying on default
before making the change
% display_indicator.pl --option='DB::module=Text' \
--option='DB::Text::directory=../../sample_data' \
--full --end='1995-12-31' I:Prices 13000 > /var/tmp/di_13000.log
% wc /var/tmp/di_13000.log
201 1004 10435 /var/tmp/di_13000.log
% head -3 /var/tmp/di_13000.log
Calculating indicator Prices[] ...
Prices[] [1995-03-06 00:00:00] = 12.3179
Prices[] [1995-03-07 00:00:00] = 11.9520
% tail -3 /var/tmp/di_13000.log
Prices[] [1995-12-27 00:00:00] = 12.7356
Prices[] [1995-12-28 00:00:00] = 12.9094
Prices[] [1995-12-29 00:00:00] = 12.8728
after making the change
% display_indicator.pl --option='DB::module=Text' \
--option='DB::Text::directory=../../sample_data' \
--full --end='1995-12-31' I:Prices 13000 > /var/tmp/di_13000_2.log
% wc /var/tmp/di_13000_2.log
737 3684 38307 /var/tmp/di_13000_2.log
% head -3 /var/tmp/di_13000_2.log
Calculating indicator Prices[] ...
Prices[] [1993-01-04 00:00:00] = 21.0989
Prices[] [1993-01-05 00:00:00] = 20.9770
% tail -3 /var/tmp/di_13000_2.log
Prices[] [1995-12-27 00:00:00] = 12.7356
Prices[] [1995-12-28 00:00:00] = 12.9094
Prices[] [1995-12-29 00:00:00] = 12.8728
please note your objections, if any.
aloha
ras
--- GT/Tools.pm (revision 709)
+++ GT/Tools.pm (working copy)
@@ -670,15 +670,15 @@
unless ($start) {
$first = $last - 2 * GT::DateTime::timeframe_ratio($YEAR,
$calc->current_timeframe);
+ $first = $last - $nb_item + 1 if ($nb_item);
$first = 0 if ($full);
- $first = $last - $nb_item + 1 if ($nb_item);
$first = 0 if ($first < 0);
}
unless ($last) {
$last = $first + 2 * GT::DateTime::timeframe_ratio($YEAR,
$calc->current_timeframe);
+ $last = $first + $nb_item - 1 if ($nb_item);
$last = $c - 1 if ($full);
- $last = $first + $nb_item - 1 if ($nb_item);
$last = $c - 1 if ($last >= $c);
}
|
|
From: Roman P. <r.p...@gm...> - 2011-03-30 10:24:31
|
Hi, Ras. 1. You're right saying that newline symbol is a configurable option, and not GT trouble. So I have one more patch. Please, take a look. Also it fixes marker delimiter. We should eval escaped chars, because any escaped char, e.g. '\t', which has been read from config, will be equal to this: $v = '\t'; # hex 0x5C 0x74 but not to expected: $v = "\t"; # hex 0x09 *we expect double quoted, but not single quoted* GT_NEWLINE.patch 2. In my previous GT_SET_STOP.patch I missed another wrong stop set. So, new patch covers this case. GT_SET_STOP_2.patch > finally graphic object Orders might be useful to show portfolio orders, > but i don't recall if a portfolio archives all orders or just the ones > that result in a trade ... (it's also possible that this module isn't in > the repo; in that case yell and i'll fire you off what i have) I can't find any graphic object Orders in repository. But I found GT/Graphics/Object/Positions.pm, which draws really traded positions. That's ok for me. > well, graphic.pl just plots graphs of mostly indicators so passing things > (objects) like trade-filters, money-managers and order-factories don't > make a lot of sense (but if you see it differently please explain). I just want to see my whole system on chart. But as I said above: traded positions on charts are great help. > no. as far as i'm able to determine (i don't trade futures or options) > gt isn't easily adaptable for futures (or options). hm. don't think that calculating futures margin is a big deal if we have contract definition. I'll try to develop something for my own needs and will send the patch. (maybe I'am wrong and this is really hard to implement. will see) > the hack isn't in the repository, but likely posted as a proposed > alternative > to backtest.pl in the geniustrader-devel mail archive. if you are unable to > find it (or make it work) give me a shout and i'll either try to hunt down > the archive reference or help you get it working ... I found it in repository: GT/Graphics/Object/Positions.pm. This module contains full description how to use it. And it works. Thanks for help. Trying to dive deeper. :) -- Roman On Tue, Mar 29, 2011 at 10:33 PM, Robert A. Schmied <ra...@ac...> wrote: >> [GT] Minor patches and some questions >> From: Roman Penieav <r.peniaev@gm...> - 2011-03-28 08:58 >> >> Hi. > > aloha roman > > i'll look at your patches in detail as time goes by, but wanted > to fire off this quick thanks and to quickly answer some of the > immediate questions ... embedded below > > >> >> I'am newbie in GT and would like to ask some questions. >> But first of all please take a look at my patches: >> >> 1. GT_MINOR.patch - >> Minor comments tweaks. >> >> 2. GT_ARGS_PRIORITY.patch - >> Seems to me --full argument must have more priority than nb-item, >> i.e. without this patch any script with arguments `--full >> --end=<some_date>` >> outputs 200 default items, because default nb-item==200 has more priority. > > humm -- the issue with data ranges just never seems to go away ... > >> >> 3. GT_SET_STOP.patch >> Seems to me we should use 'set_stop' call, instead of setting stop >> directly, because direct set can replace another "best" stop of another >> CS. > > yes! this may be a fix to a long standing problem ... > >> >> 4. GT_CRLF.patch >> Text files exported from Windows machine always contain CRLF symbols >> at the end of the line, chomp removes \n, so we should try to remove >> \r symbol at the end of the line. > > well 1) chomp is used all over the place ... > 2) i don't much care (cannot test) about that foreign platform > 3) was under the apparently mistaken belief that perl handled this > internally. > > looks like the perl var $/ needs to be (re)set on windblown plats to be > "\n\r", > but that's a user-platform configuration-use problem not really a gt problem > ... > > assuming it's not an isolated problem (to just you/your platform) ... > i guess a hack to Conf.pm could be used to do this automagically ... > any other windowners out there experiencing the same/similar problem? > >> >> Questions: >> >> 1. ./backtest.pl accepts CS, TF, MM and OF as params, but other scripts >> such >> as ./graphics.pl or ./display_system.pl do not. How can I pass full >> trading system >> (with CS, TF, MM, OF) to these scripts? > > well, graphic.pl just plots graphs of mostly indicators so passing things > (objects) like trade-filters, money-managers and order-factories don't > make a lot of sense (but if you see it differently please explain). > > on the other hand plotting signals is kind-of reasonable, so feeding either > close-strats or a trading system sys-sig-indic desc might be useful since > these are just signal pairs. > > you might look at the two special graphic objects BuySellArrows and > VotingLine to plot these sorts of things, but as of now close-strats > are still not supported by these modules. > > finally graphic object Orders might be useful to show portfolio orders, > but i don't recall if a portfolio archives all orders or just the ones > that result in a trade ... (it's also possible that this module isn't in > the repo; in that case yell and i'll fire you off what i have) > >> >> 2. Does GT support futures? I mean if I trade with leverage my >> Portfolio must considerate >> initial margin requirements of the contract but not the real trade price. > > no. as far as i'm able to determine (i don't trade futures or options) > gt isn't easily adaptable for futures (or options). > > also note that the accounting aspects of portfolio are probably rather > lacking (or maybe worse just wrong) -- for example, interest paid by a > company isn't considered when computing performance (and there isn't > an easy way to wedge this into the program). in the case of margined > securities, i've not done (nor have seen) any verifications that margin > costs are correctly computed and correctly applied ... > >> >> 3. On this page http://www.geniustrader.org/screenshots.html >> I found such words: >> "Note: there is a ras hack of backtest.pl (possibly available in the >> GT devel archive) that uses the graphic object Positions to draw buys >> and sells on the chart instead of the Trades graphic object to mark >> trades alone the bottom axis." >> I can't find this changes in GT trunk. Is this outdated? > > the hack isn't in the repository, but likely posted as a proposed > alternative > to backtest.pl in the geniustrader-devel mail archive. if you are unable to > find it (or make it work) give me a shout and i'll either try to hunt down > the archive reference or help you get it working ... > > aloha > > ras > > >> >> -- >> Roman >> >> > |
|
From: Robert A. S. <ra...@ac...> - 2011-03-29 18:47:01
|
> [GT] Minor patches and some questions
> From: Roman Penieav <r.peniaev@gm...> - 2011-03-28 08:58
>
> Hi.
aloha roman
i'll look at your patches in detail as time goes by, but wanted
to fire off this quick thanks and to quickly answer some of the
immediate questions ... embedded below
>
> I'am newbie in GT and would like to ask some questions.
> But first of all please take a look at my patches:
>
> 1. GT_MINOR.patch -
> Minor comments tweaks.
>
> 2. GT_ARGS_PRIORITY.patch -
> Seems to me --full argument must have more priority than nb-item,
> i.e. without this patch any script with arguments `--full --end=<some_date>`
> outputs 200 default items, because default nb-item==200 has more priority.
humm -- the issue with data ranges just never seems to go away ...
>
> 3. GT_SET_STOP.patch
> Seems to me we should use 'set_stop' call, instead of setting stop
> directly, because direct set can replace another "best" stop of another CS.
yes! this may be a fix to a long standing problem ...
>
> 4. GT_CRLF.patch
> Text files exported from Windows machine always contain CRLF symbols
> at the end of the line, chomp removes \n, so we should try to remove
> \r symbol at the end of the line.
well 1) chomp is used all over the place ...
2) i don't much care (cannot test) about that foreign platform
3) was under the apparently mistaken belief that perl handled this internally.
looks like the perl var $/ needs to be (re)set on windblown plats to be "\n\r",
but that's a user-platform configuration-use problem not really a gt problem ...
assuming it's not an isolated problem (to just you/your platform) ...
i guess a hack to Conf.pm could be used to do this automagically ...
any other windowners out there experiencing the same/similar problem?
>
> Questions:
>
> 1. ./backtest.pl accepts CS, TF, MM and OF as params, but other scripts such
> as ./graphics.pl or ./display_system.pl do not. How can I pass full
> trading system
> (with CS, TF, MM, OF) to these scripts?
well, graphic.pl just plots graphs of mostly indicators so passing things
(objects) like trade-filters, money-managers and order-factories don't
make a lot of sense (but if you see it differently please explain).
on the other hand plotting signals is kind-of reasonable, so feeding either
close-strats or a trading system sys-sig-indic desc might be useful since
these are just signal pairs.
you might look at the two special graphic objects BuySellArrows and
VotingLine to plot these sorts of things, but as of now close-strats
are still not supported by these modules.
finally graphic object Orders might be useful to show portfolio orders,
but i don't recall if a portfolio archives all orders or just the ones
that result in a trade ... (it's also possible that this module isn't in
the repo; in that case yell and i'll fire you off what i have)
>
> 2. Does GT support futures? I mean if I trade with leverage my
> Portfolio must considerate
> initial margin requirements of the contract but not the real trade price.
no. as far as i'm able to determine (i don't trade futures or options)
gt isn't easily adaptable for futures (or options).
also note that the accounting aspects of portfolio are probably rather
lacking (or maybe worse just wrong) -- for example, interest paid by a
company isn't considered when computing performance (and there isn't
an easy way to wedge this into the program). in the case of margined
securities, i've not done (nor have seen) any verifications that margin
costs are correctly computed and correctly applied ...
>
> 3. On this page http://www.geniustrader.org/screenshots.html
> I found such words:
> "Note: there is a ras hack of backtest.pl (possibly available in the
> GT devel archive) that uses the graphic object Positions to draw buys
> and sells on the chart instead of the Trades graphic object to mark
> trades alone the bottom axis."
> I can't find this changes in GT trunk. Is this outdated?
the hack isn't in the repository, but likely posted as a proposed alternative
to backtest.pl in the geniustrader-devel mail archive. if you are unable to
find it (or make it work) give me a shout and i'll either try to hunt down
the archive reference or help you get it working ...
aloha
ras
>
> --
> Roman
>
>
|
|
From: Roman P. <r.p...@gm...> - 2011-03-28 08:58:12
|
Hi. I'am newbie in GT and would like to ask some questions. But first of all please take a look at my patches: 1. GT_MINOR.patch - Minor comments tweaks. 2. GT_ARGS_PRIORITY.patch - Seems to me --full argument must have more priority than nb-item, i.e. without this patch any script with arguments `--full --end=<some_date>` outputs 200 default items, because default nb-item==200 has more priority. 3. GT_SET_STOP.patch Seems to me we should use 'set_stop' call, instead of setting stop directly, because direct set can replace another "best" stop of another CS. 4. GT_CRLF.patch Text files exported from Windows machine always contain CRLF symbols at the end of the line, chomp removes \n, so we should try to remove \r symbol at the end of the line. Questions: 1. ./backtest.pl accepts CS, TF, MM and OF as params, but other scripts such as ./graphics.pl or ./display_system.pl do not. How can I pass full trading system (with CS, TF, MM, OF) to these scripts? 2. Does GT support futures? I mean if I trade with leverage my Portfolio must considerate initial margin requirements of the contract but not the real trade price. 3. On this page http://www.geniustrader.org/screenshots.html I found such words: "Note: there is a ras hack of backtest.pl (possibly available in the GT devel archive) that uses the graphic object Positions to draw buys and sells on the chart instead of the Trades graphic object to mark trades alone the bottom axis." I can't find this changes in GT trunk. Is this outdated? -- Roman |
|
From: Eric L. <eri...@gm...> - 2011-02-23 18:08:40
|
Code;Name;ID;MarketIndiceCode;Market;CountryCode;icb1_symbol;icb3_symbol;pea;srd ALBRO;BROSSARD;FR0010447631;;;FR;;;; MLUNI;UNIROSS;FR0010105817;;;FR;;;; MLEST;EST REPUBLICAIN;FR0005310463;;;FR;;;; ALCBO;CBO TERRITORIA;FR0010193979;;;FR;;;; ALCLA;CLASQUIN;FR0004152882;;;FR;;;; MLHOM;HOMSYS GROUP;FR0010000869;;;FR;;;; MLPLA;PROMENS (EX PLASTOHM);FR0000061327;;;FR;;;; ALTHE;THENERGO;BE0947217122;;;BE;;;; ALCRM;CRM COMPANY GROUP;FR0010358465;;;FR;;;; ALDIE;DIETSWELL ENGINEERING;FR0010377127;;;FR;;;; ALDLS;DLSI;FR0010404368;;;FR;;;; MLMAP;MAPORAMA INTERNATIONAL;FR0010215202;;;FR;;;; MLWIL;WILLEME;FR0006460721;;;FR;;;; ALEUR;NEXEYA (EX.GROUPE EURILOGIC);FR0010414961;;;FR;;;; ALFBA;FASHION B AIR;FR0004034593;;;FR;;;; ALFPC;FOUNTAINE PAJOT;FR0010485268;;;FR;;;; ALHPC;HEURTEY PETROCHEM;FR0010343186;;;FR;;;; ALI2S;I2S;FR0005854700;;;FR;;;; ALODI;O2i;FR0010231860;;;FR;;;; ALPRI;PRESS INDEX;FR0010314963;;;FR;;;; ALPRV;PROSERVIA;FR0010337485;;;FR;;;; MLNEX;NEXO;FR0000044414;;;FR;;;; MLCES;CESAM;FR0000062838;;;FR;;;; ALCEL;CELEOS;FR0010324962;;;FR;;;; MLCOM;COMPOBAIE;FR0000074288;;;FR;;;; ALITS;INTERNATIONAL TECHNOLOGIE SELECTION;FR0010370163;;;FR;;;; ALNEO;NEOTION;FR0004172260;;;FR;;;; ALTEC;TECHNILINE;FR0010212480;;;FR;;;; ALMDG;MGI Digital Graphic;FR0010353888;;;FR;;;; AL185;1855;FR0004168243;;;FR;;;; MLADM;ADMEA;FR0010002196;;;FR;;;; BN;DANONE;FR0000120644;PX1;PAR;FR;FRCG;FRFPR;Oui;True MLLEO;LEON GROSSE;FR0005717626;;;FR;;;; MLCSP;CHINA SUPER POWER;HK0000043510;;;HK;;;; MLDAN;DANIEL HARLANT;FR0004523611;;;FR;;;; MLINF;INFORMATIS TECHNOLOGY SYSTEM;FR0000077463;;;FR;;;; MLEFI;EUROPE FINANCE ET INDUSTRIES;FR0004038180;;;FR;;;; MLOBE;OBEA;FR0000044604;;;FR;;;; MLMAD;MADE;FR0010328302;;;FR;;;; MLMOB;MOBILEGOV;FR0010581363;;;FR;;;; MLZTA;ZETA BIOTECH;FR0010485516;;;FR;;;; MLWAN;WORLD ART NET;LU0336998249;;;LU;;;; MLTMS;TMS (TRADING MAIN. & SERVICES);BE0129618261;;;BE;;;; ALCNX;CONPOREC;CA2082824004;;;CA;;;; MLHAP;HAPPYDOO;FR0010491373;;;FR;;;; MLEDR;EAUX DE ROYAN;FR0007200100;;;FR;;;; MLLOI;LOCASYSTEM INTERNATIONAL;FR0004155208;;;FR;;;; MLHIN;HOTELIERE IMMOBILIERE DE NICE;FR0006563904;;;FR;;;; ALADO;ADOMOS;FR0000044752;;;FR;;;; MLNEW;NEWTECH INTERACTIVE;FR0000037400;;;FR;;;; MLLAR;STRATEGECO SOLAR;FR0010535849;;;FR;;;; MLNEI;NEWSINVEST;FR0010358507;;;FR;;;; ALASS;ASSYA CIE FIN;FR0004060234;;;FR;;;; ALBUD;BUDGET TELECOM;FR0004172450;;;FR;;;; ALAUT;AUTO ESCAPE;FR0010423152;;;FR;;;; ALEFT;EFRONT;FR0010406777;;;FR;;;; ALALO;ACHETER-LOUER.FR;FR0010493510;;;FR;;;; ALANT;ANTEVENIO;ES0109429037;;;ES;;;; MLGCO;GROUPE COPLAN;FR0000078750;;;FR;;;; ALGOA;GOADV;FR0010500975;;;FR;;;; ALHEO;H2O INNOVATION;CA44329N2005;;;CA;;;; ALGFT;GENFIT;FR0004163111;;;FR;;;; ALHIT;HITECHPROS;FR0010396309;;;FR;;;; ALHOM;HOMAIR VACANCES;FR0010307322;;;FR;;;; MLTEL;TELEMEDIA GROUP;FR0000076416;;;FR;;;; MLMAN;MANDRIVA (EX MANDRAKESOFT);FR0004159382;;;FR;;;; MLFMB;FMB AQUAPOLE;FR0010505917;;;FR;;;; MLEFS;EASY FIELD SERV.;FR0010417816;;;FR;;;; MLCHE;CHEOPS TECHNOLOGY;FR0010447086;;;FR;;;; ALYIN;YIN PARTNERS;FR0010461384;;;FR;;;; ALWEB;WEBORAMA;FR0010337444;;;FR;;;; MLSTS;STS GROUP;FR0010173518;;;FR;;;; TNU;EUROTUNNEL UNITS;FR0000125379;;;FR;;;; MLDUC;DUCOS SARRAT;FR0005159175;;;FR;;;; MLNSB;NASEBA GROUP;FR0010241596;;;FR;;;; MLPRW;PROWEBCE;FR0010355057;;;FR;;;; MLEO2;EO2;FR0010465534;;;FR;;;; ALXIR;XIRING;FR0004155612;;;FR;;;; MLCAL;CALYSTENE;FR0000076275;;;FR;;;; MLONE;BODY ONE;FR0010106039;;;FR;;;; MLGOL;GOLOG;LU0310864698;;;LU;;;; ALCSY;COME AND STAY;FR0004171346;;;FR;;;; ALIDE;IDEOM;FR0000044885;;;FR;;;; ALBIL;RENTABILIWEB;BE0946620946;;;BE;;;; ALLAR;LAROCHE SA;FR0000077117;;;FR;;;; ALLMR;LAMARTHE;FR0010311597;;;FR;;;; ALIDA;LOYALTOUCH;FR0010354407;;;FR;;;; ALEMV;EMAILVISION;FR0004168045;;;FR;;;; ALLOG;LOGIC INSTRUMENT;FR0000044943;;;FR;;;; ALMGI;MG INTERNATIONAL;FR0010204453;;;FR;;;; ALTMG;THE MARKETINGROUP (EX.PHONE M);FR0000044679;;;FR;;;; MLGAU;GAUSSIN;FR0010342329;;;FR;;;; MLFRC;FRANCE CHAUFFAGE;FR0004260479;;;FR;;;; ALNOR;NORMACTION;FR0010210153;;;FR;;;; ALRIC;RICHEL SERRES FRA.;FR0000078875;;;FR;;;; MLSIM;SIMO INTERNATIONAL;FR0004038818;;;FR;;;; MLENR;ENTREPRENDRE;FR0000045122;;;FR;;;; MLEDS;EDITIONS DU SIGNE;FR0000052755;;;FR;;;; MLGAI;GAI (EX.EFE EDITION FORMATION);FR0000053415;;;FR;;;; MLPRI;PROPRIETES IMMEUBLES;FR0000061376;;;FR;;;; AVM;WAVECOM;FR0000073066;PX1;PAR;FR;FRTEC;FRTHF;True;Non CAR;CARRERE GROUP;FR0000044422;PX1;PAR;FR;FRCS;FRMED;True;Non BRGS;BOURGEOIS;FR0000060055;PX1;PAR;FR;FRHC;FRHES;True;Non BORG;DISTRIBORG GROUPE;FR0000061178;PX1;PAR;FR;FRCS;FRFDR;True;Non DSNV;DMC NV;FR0010565838;PX1;PAR;FR;FRCG;FRPG;True;Non DLAM;DUC LAMOTHE PARTICIPATIONS;FR0000039638;PX1;PAR;FR;FRFIN;;True;Non DS;DMC(DOLLFUS MIEG);FR0000121337;PX1;PAR;FR;FRCG;FRPG;True;Non FOAF;FIN.OUEST AFRICAIN;SN0000033192;PX1;PAR;SN;FRFIN;FRGF;Non;Non GANT;GANTOIS;FR0000064214;PX1;PAR;FR;FRIN;FRIE;True;Non GDSA;GDSA REGP.;FR0010603191;PX1;PAR;FR;FRIN;FRIE;True;Non FED;GIORGIO FEDON;IT0001210050;PX1;PAR;IT;FRCG;FRPG;True;Non IMHO;IMMOB.HOTELIERE;FR0000036980;PX1;PAR;FR;FRCS;FRTL;True;Non LATO;LATONIA INVEST.;PA5183021045;PX1;PAR;PA;FRFIN;;Non;Non CRLBS;CARB LOR BSAAR1112;FR0010530105;PX1;PAR;FR;FRIN;FREEE;True;Non CGDBS;CEGIDGP BSAR0309;FR0010061853;PX1;PAR;FR;FRTEC;FRSCS;True;Non VK;VALLOUREC;FR0000120354;PX1;PAR;FR;FRIN;FRIE;True;True VLS;VIVALIS;FR0004056851;PX1;PAR;FR;FRHC;FRPB;True;Non VMMA;VM MATERIAUX;FR0000066540;PX1;PAR;FR;FRIN;FRCM;True;Non VRAP;VRANKEN-POMMERY MONOPOLE;FR0000062796;PX1;PAR;FR;FRCG;FRBEV;True;Non XIL;XILAM ANIMATION;FR0004034072;PX1;PAR;FR;FRCS;FRMED;True;Non ZC;ZODIAC AEROSPACE;FR0000125684;PX1;PAR;FR;FRIN;FRAD;True;True ZIF;ZUBLIN IMMOBILIERE FRANCE;FR0010298901;PX1;PAR;FR;FRFIN;;True;Non IFG;ATARI;FR0010478248;PX1;PAR;FR;FRTEC;FRSCS;True;Non OLI;ID FUTURE (EX.PROXITEC);FR0000060410;PX1;PAR;FR;FRTEC;FRTHF;True;Non RINV;PERNOD RICARD NV;FR0010631721;PX1;PAR;FR;FRCG;FRBEV;True;Non QTE;QUOTIUM TECHNO;FR0010211615;PX1;PAR;FR;FRTEC;FRSCS;True;Non CBR;ROBERTET CDV 87;FR0000045619;PX1;PAR;FR;FRBM;;Non;Non LCONV;SOLUCOM NV;FR0010622837;PX1;PAR;FR;FRTEC;FRSCS;True;Non LYSP;SYLIS;FR0010655191;PX1;PAR;FR;FRTEC;FRSCS;True;Non ZCNV;ZODIAC NV;FR0010654491;PX1;PAR;FR;FRIN;FRAD;True;Non AC;ACCOR;FR0000120404;PX1;PAR;FR;FRCS;FRTL;True;True ACA;CREDIT AGRICOLE SA;FR0000045072;PX1;PAR;FR;FRFIN;FRB;True;True ACAN;ACANTHE DEVELOPPEMENT;FR0000064602;PX1;PAR;FR;FRFIN;;True;Non GRS;GROUPE SILICOMP;FR0000063794;PX1;PAR;FR;FRTEC;FRSCS;True;Non FFBE;FOND.FRANCO-BELGES;FR0000063265;PX1;PAR;FR;FRFIN;;True;Non FAYE;FAYENCERIES SARREGUEMINES;FR0000031973;PX1;PAR;FR;FRCG;FRHG;True;Non DEVR;DEVERNOIS;FR0000060840;PX1;PAR;FR;FRCG;FRPG;True;Non EME;EMME;FR0004155000;PX1;PAR;FR;FRCS;FRMED;True;Non AML;ATMEL CORP.;US0495131049;PX1;PAR;US;FRTEC;FRTHF;Non;Non ASY;ASSYSTEM (EX ASSYSTEM BRIME);FR0000074148;PX1;PAR;FR;FRTEC;FRSCS;True;Non ATE;ALTEN;FR0000071946;PX1;PAR;FR;FRTEC;FRSCS;True;True AUB;AUBAY;FR0000063737;PX1;PAR;FR;FRTEC;FRSCS;True;Non FIPP;FIPP;FR0000038184;PX1;PAR;FR;FRFIN;FRGF;True;Non NTS;NET2S;FR0000075921;PX1;PAR;FR;FRTEC;FRSCS;True;Non PIER;TRSP NORD-PIERCHON;FR0000063513;PX1;PAR;FR;FRIN;FRINT;True;Non SFBS;SOFIBUS (EX FINA.BUREAUX USIN);FR0000038804;PX1;PAR;FR;FRFIN;;True;Non LEON;LEON DE BRUXELLES;FR0010522169;PX1;PAR;FR;FRCS;FRTL;True;Non SLCO;SELCODIS (EX. SUPERVOX GROUPE);FR0000065492;PX1;PAR;FR;FRIN;FRCM;True;Non VEC;VECTRANE;FR0010262287;PX1;PAR;FR;FRFIN;;True;Non DLTBR;DELTA PLUS BSAR;FR0010202655;PX1;PAR;FR;FRCG;FRPG;True;Non KAZBS;ORCHESTRA 1.55 BSA 03/09;FR0010058644;PX1;PAR;FR;FRCG;FRPG;True;Non HAM;HAMMERSON;GB0004065016;PX1;PAR;GB;FRFIN;;True;Non VAST;VASTNED RETAIL NV;NL0000288918;PX1;PAR;NL;FRFIN;;True;Non WDPP;WDP;BE0003763779;PX1;PAR;BE;FRFIN;;True;Non ONA;ONA;MA0000010316;PX1;PAR;MA;FRIN;;Non;Non NOHYP;NORSK HYDRO;NO0005052605;PX1;PAR;NO;FRBM;;True;Non ITXT;INTL TEXT.ASSOCIES;FR0000064958;PX1;PAR;FR;FRCG;FRPG;True;Non LDA;ALDETA;FR0000036634;PX1;PAR;FR;FRCS;FRGR;True;Non CPT;COMPLETEL;NL0000262822;PX1;PAR;NL;FRTEL;FRFLT;True;Non SETF;SETFORGE;FR0000044489;PX1;PAR;FR;FRIN;FRIE;True;Non CEI;AREVA (EX CEA-INDUSTRIE CIP);FR0004275832;PX1;PAR;FR;FRUT;;True;Non CEN;GROUPE CRIT;FR0000036675;PX1;PAR;FR;FRIN;FRSS;True;Non OMA;AUTOMA TECH;FR0000074270;PX1;PAR;FR;FRIN;FRIE;True;Non MEX;MEILLEURTAUX;FR0010187096;PX1;PAR;FR;FRFIN;FRGF;True;Non OCS;OBERTHUR CARD SYSTEMS;FR0000124133;PX1;PAR;FR;FRIN;FREEE;True;True TIPA;TEAM PARTNERS GROUP;FR0010494252;PX1;PAR;FR;FRTEC;FRSCS;True;Non INV;SIICINVEST;FR0010332049;PX1;PAR;FR;FRFIN;;True;Non MIL;MILLIMAGES;FR0000044380;PX1;PAR;FR;FRCS;FRMED;True;Non NSGP;NSC GROUPE;FR0000064529;PX1;PAR;FR;FRIN;FRIE;True;Non ORCBR;ORCO BSAR;LU0234878881;PX1;PAR;LU;FRFIN;;True;Non PTER;PLANTATIONS TERRES ROUGES;LU0012113584;PX1;PAR;LU;FRCG;FRFPR;True;Non ADE;ADECCO;CH0012138605;PX1;PAR;CH;FRIN;FRSS;Non;True WHP;WERELDHAVE NV;NL0000289213;PX1;PAR;NL;FRFIN;;True;Non BPLC;BP P.L.C.;GB0007980591;PX1;PAR;GB;FROG;FROGP;True;Non IPOA;IPO(INST.PART.O.);FR0000066284;PX1;PAR;FR;FRFIN;;True;Non LYC;LYCOS EUROPE C.B;NL0000233195;PX1;PAR;NL;FRTEC;FRSCS;True;Non EHO;ESPACE PRODUCTION;FR0004048072;PX1;PAR;FR;FRCG;FRHG;True;Non SFCA;SOC FRANC CASINOS;FR0010209809;PX1;PAR;FR;FRCS;FRTL;True;Non NORT;OUTSIDE LIVIN IND (EX NORTENE);FR0006626032;PX1;PAR;FR;FRCS;FRGR;True;Non TVRB;TELEVERBIER;CH0008175645;PX1;PAR;CH;FRCS;FRTL;Non;Non DX;DEXIA;BE0003796134;PX1;PAR;BE;FRFIN;FRB;True;True SEVDA;SUEZ ENV COMP DA;FR0010614115;PX1;PAR;FR;FRUT;FRGWM;True;Non CHAU;CHAUFFAGE URBAIN;FR0000052896;PX1;PAR;FR;FRUT;FRGWM;True;Non DLT;DALET;FR0000076176;PX1;PAR;FR;FRTEC;FRSCS;True;Non DLTA;DELTA PLUS GROUP;FR0004152502;PX1;PAR;FR;FRCG;FRPG;True;Non NOV;ANOVO NR;FR0004152593;PX1;PAR;FR;FRIN;FRSS;True;Non MTP;ARCELORMITTAL;LU0323134006;PX1;PAR;LU;FRBM;;True;True THEPA;THENERGO (D);BE0003895159;PX1;PAR;BE;FRUT;;True;Non CK;CASINO GUICHAR.ADP;FR0000121139;PX1;PAR;FR;FRCS;FRFDR;True;Non CMD;CMT MEDICAL TECHNOLOGIES;IL0010832298;PX1;PAR;IL;FRHC;FRHES;Non;Non ILO;ILOG;FR0004042364;PX1;PAR;FR;FRTEC;FRSCS;True;Non CRO;CAR PRO DE NON REG;FR0004161677;PX1;PAR;FR;FRTEC;FRSCS;True;Non ALDV;ALLIANCE DEVELOPPEMENT CAPITAL;FR0000065401;PX1;PAR;FR;FRFIN;;True;Non AMA;CAMAIEU;FR0004008209;PX1;PAR;FR;FRCS;FRGR;True;Non ENTC;ENTREPOSE CONTRACTING;FR0010204321;PX1;PAR;FR;FROG;;True;False EO;FAURECIA;FR0000121147;PX1;PAR;FR;FRCG;FRAP;True;Oui EOS;ACTEOS (EX DATATRONIC);FR0000076861;PX1;PAR;FR;FRTEC;FRSCS;Oui;False ADEN;ADENCLASSIFIEDS;FR0004053932;PX1;PAR;FR;FRTEC;FRSCS;Oui;False GLT;GL TRADE;FR0000072084;PX1;PAR;FR;FRTEC;FRSCS;Oui;False CBDG;CAMBODGE NOM.;FR0000079659;PX1;PAR;FR;FRFIN;;Oui;False BLEE;BLEECKER;FR0000062150;PX1;PAR;FR;FRFIN;;Oui;False LUC;LUCIA;FR0000036303;PX1;PAR;FR;FRFIN;;Oui;False ARE;GROUPE ARES;FR0000072167;PX1;PAR;FR;FRTEC;FRSCS;Oui;False DAB;DAB BANK J00;DE0005072300;PX1;PAR;DE;FRFIN;FRGF;Oui;False BST;BAC MAJESTIC;FR0000076895;PX1;PAR;FR;FRCS;FRMED;Oui;False CBD;CYBERDECK;FR0004154151;PX1;PAR;FR;FRTEC;FRTHF;Oui;False MBRE;MB RETAIL EUROPE (EX.CHAINE T);FR0000061475;PX1;PAR;FR;FRFIN;;Oui;False CRCL;CRCAM CENTRE LOIRE.CCI;FR0000045296;PX1;PAR;FR;FRFIN;FRB;Oui;False SPR;SPERIAN PROTECTION (ex BACOU);FR0000060899;PX1;PAR;FR;FRIN;;Oui;Oui BRICO;BRICORAMA;FR0000054421;PX1;PAR;FR;FRCS;FRGR;Oui;False TRD;TRADER CLASSIFIED MEDIA;NL0000233187;PX1;PAR;NL;FRCS;FRMED;Oui;False HREG;HOTEL REGINA PARIS;FR0007080254;PX1;PAR;FR;FRCS;FRTL;Oui;False INIT;INITIATIVE FIN.S.A;FR0000050072;PX1;PAR;FR;FRFIN;;Oui;False MILU;MINES LUCETTE;FR0000066177;PX1;PAR;FR;FRFIN;;Oui;False NOEV;NEOVIA ELECTRONICS;FR0010101741;PX1;PAR;FR;FRCG;FRLEG;Oui;False OXYM;OXYMETAL;FR0000063018;PX1;PAR;FR;FRIN;FRIE;Oui;False PRI;PARIS RE;CH0032057447;PX1;PAR;CH;FRFIN;FRNI;False;Oui SAGA;SAGA NOM.;FR0000185522;PX1;PAR;FR;FRIN;FRINT;Oui;False SDRB;SDR BRETAGNE;FR0000066094;PX1;PAR;FR;FRFIN;FRGF;Oui;False SZE;SUEZ;FR0000120529;PX1;PAR;FR;FRUT;FRGWM;Oui;False IAT;INTL ANDRE TRIGANO;FR0000061202;PX1;PAR;FR;FRCS;FRTL;Oui;False VIA;GROUPE VIAL;FR0010340406;PX1;PAR;FR;FRIN;FRCM;Oui;False UMS;UMANIS NR;FR0000066771;PX1;PAR;FR;FRTEC;FRSCS;Oui;False VIM;PROVIMI;FR0000044588;PX1;PAR;FR;FRCG;FRFPR;Oui;False ALL;ALLIANZ;DE0008404005;PX1;PAR;DE;FRFIN;FRNI;Oui;Oui VCT;VICAT;FR0000031775;PX1;PAR;FR;FRIN;FRCM;Oui;Oui VET;VET AFFAIRES;FR0000077158;PX1;PAR;FR;FRCS;FRGR;Oui;False VETO;VETOQUINOL;FR0004186856;PX1;PAR;FR;FRHC;FRPB;Oui;False VIE;VEOLIA ENVIRONNEMENT;FR0000124141;PX1;PAR;FR;FRUT;FRGWM;Oui;Oui VIL;VIEL ET COMPAGNIE;FR0000050049;PX1;PAR;FR;FRFIN;FRGF;Oui;False VIRP;VIRBAC;FR0000031577;PX1;PAR;FR;FRHC;FRPB;Oui;False VIV;VIVENDI;FR0000127771;PX1;PAR;FR;FRCS;FRMED;Oui;Oui YACHT;COUACH;FR0000075764;PX1;PAR;FR;FRCG;FRLEG;Oui;False DEQN;CROSSWOOD (EX.DESQUENNE ET GIRAL);FR0000050395;PX1;PAR;FR;FRIN;FRCM;Oui;False OROS;OROSDI-BACK;FR0000039141;PX1;PAR;FR;FRCS;FRGR;Oui;False CARP;CARPINIENNE DE PARTICIPATIONS;FR0000064156;PX1;PAR;FR;FRFIN;;Oui;False OVG;OVERLAP GROUPE;FR0004051530;PX1;PAR;FR;FRTEC;FRSCS;Oui;False EXPL;EXPLOSIFS & PRODUITS CHIMIQUES;FR0000039026;PX1;PAR;FR;FRBM;;Oui;False HDP;HOTELS DE PARIS;FR0004165801;PX1;PAR;FR;FRCS;FRTL;Oui;False UNBL;UNIBEL;FR0000054215;PX1;PAR;FR;FRCG;FRFPR;Oui;False OXYBS;OXYMETAL BS1209;FR0010489815;PX1;PAR;FR;FRIN;FRIE;Oui;False DPAM;DOCKS PETROLES D AMBES;FR0000065260;PX1;PAR;FR;FRIN;FRINT;Oui;False ACI;ACCES INDUSTRIE;FR0010567032;PX1;PAR;FR;FRIN;FRSS;Oui;False ADA;ADA;FR0000053076;PX1;PAR;FR;FRCS;FRTL;Oui;False ADI;AUDIKA;FR0000063752;PX1;PAR;FR;FRHC;FRHES;Oui;False ADP;AEROPORTS DE PARIS;FR0010340141;PX1;PAR;FR;FRIN;FRINT;Oui;Oui AESCH;AES CHEMUNEX;FR0010158642;PX1;PAR;FR;FRHC;FRHES;Oui;False AF;AIR FRANCE - KLM;FR0000031122;PX1;PAR;FR;FRCS;FRTL;Oui;Oui AFO;AFONE;FR0000044612;PX1;PAR;FR;FRTEL;FRFLT;Oui;False AGCR;AGRICOLE CRAU;FR0000062176;PX1;PAR;FR;FRCG;FRFPR;Oui;False AGTA;AGTA RECORD;CH0008853209;PX1;PAR;CH;FRIN;FRCM;False;False AI;AIR LIQUIDE;FR0000120073;PX1;PAR;FR;FRBM;;Oui;Oui AKA;AKKA TECHNOLOGIES;FR0004180537;PX1;PAR;FR;FRIN;FRSS;Oui;False AKE;ARKEMA;FR0010313833;PX1;PAR;FR;FRBM;;Oui;Oui CER;CEREP;FR0004042232;PX1;PAR;FR;FRHC;FRPB;Oui;False ESK;ESKER;FR0000035818;PX1;PAR;FR;FRTEC;FRSCS;Oui;False ALM;ALPHA MOS;FR0000062804;PX1;PAR;FR;FRIN;FREEE;Oui;False ALO;ALSTOM;FR0010220475;PX1;PAR;FR;FRIN;FRIE;Oui;Oui ALP;ADLPARTNER;FR0000062978;PX1;PAR;FR;FRCS;FRMED;Oui;False PDJ;PISCINES DESJOYAUX;FR0000061608;PX1;PAR;FR;FRCG;FRLEG;Oui;False ALT;ALTRAN TECHNOLOGIES;FR0000034639;PX1;PAR;FR;FRIN;FRSS;Oui;Oui ALTA;ALTAREA;FR0000033219;PX1;PAR;FR;FRFIN;;Oui;False ALU;ALCATEL-LUCENT;FR0000130007;PX1;PAR;FR;FRTEC;FRTHF;Oui;Oui AM;DASSAULT AVIATION;FR0000121725;PX1;PAR;FR;FRIN;FRAD;Oui;False AN;CANAL +;FR0000125460;PX1;PAR;FR;FRCS;FRMED;Oui;Oui ANF;ANF;FR0000063091;PX1;PAR;FR;FRFIN;;Oui;False APR;APRIL GROUP;FR0004037125;PX1;PAR;FR;FRFIN;FRNI;Oui;Oui ARR;APRR (AUTOROUTES PRR);FR0006807004;PX1;PAR;FR;FRIN;FRINT;Oui;Oui ASP;AST GROUPE (EX AST PROMOTION);FR0000076887;PX1;PAR;FR;FRCG;FRHG;Oui;False ATI;ACTIA GROUP (EX.ACTIELEC TECHNOLOGIES);FR0000076655;PX1;PAR;FR;FRIN;FREEE;Oui;False ATO;ATOS ORIGIN;FR0000051732;PX1;PAR;FR;FRTEC;FRSCS;Oui;Oui AUGR;AUGROS COSMETICS;FR0000061780;PX1;PAR;FR;FRIN;;Oui;False AURE;AUREA;FR0000039232;PX1;PAR;FR;FRIN;FRSS;Oui;False AURS;AURES TECHNOLOGIES;FR0000073827;PX1;PAR;FR;FRIN;FREEE;Oui;False AVF;AVENIR FINANCE;FR0004152874;PX1;PAR;FR;FRFIN;FRGF;Oui;False AVQ;AVANQUEST SOFTWARE (EX BVRP);FR0004026714;PX1;PAR;FR;FRTEC;FRSCS;Oui;False AVT;AVENIR TELECOM;FR0000066052;PX1;PAR;FR;FRTEC;FRTHF;Oui;False GTO;GEMALTO;NL0000400653;PX1;PAR;NL;FRIN;FREEE;Oui;Oui BAIN;BAINS MER MONACO;MC0000031187;PX1;PAR;MC;FRCS;FRTL;False;False BB;BIC;FR0000120966;PX1;PAR;FR;FRCG;FRHG;Oui;Oui BCRA;BACCARAT;FR0000064123;PX1;PAR;FR;FRCG;FRHG;Oui;False BELI;BELIER;FR0000072399;PX1;PAR;FR;FRCG;FRAP;Oui;False BEN;BENETEAU;FR0000035164;PX1;PAR;FR;FRCG;FRLEG;Oui;Oui BERR;FIN.ETANG BERRE;FR0000062341;PX1;PAR;FR;FRFIN;;Oui;False BH;BONGRAIN;FR0000120107;PX1;PAR;FR;FRCG;FRFPR;Oui;False BI;GASCOGNE;FR0000124414;PX1;PAR;FR;FRIN;;Oui;False BIG;BIGBEN INTERACTIVE;FR0000074072;PX1;PAR;FR;FRCG;FRLEG;Oui;False BIM;BIOMERIEUX;FR0010096479;PX1;PAR;FR;FRHC;FRHES;Oui;Oui BIO;BIOALLIANCE PHARMA;FR0010095596;PX1;PAR;FR;FRHC;FRPB;Oui;False BLC;BASTIDE LE CONFORT;FR0000035370;PX1;PAR;FR;FRHC;FRHES;Oui;False BLOI;BERNARD LOISEAU;FR0000066961;PX1;PAR;FR;FRCS;FRTL;Oui;False BNA;BCI NAVIGATION;FR0000076192;PX1;PAR;FR;FRTEC;FRSCS;Oui;False BND;BUSINESS ET DECISION;FR0000078958;PX1;PAR;FR;FRTEC;FRSCS;Oui;False BNP;BNP PARIBAS;FR0000131104;PX1;PAR;FR;FRFIN;FRB;Oui;Oui BOI;BOIRON;FR0000061129;PX1;PAR;FR;FRHC;FRPB;Oui;False BOL;BOLLORE;FR0000039299;PX1;PAR;FR;FRIN;FRINT;Oui;Oui BON;BONDUELLE;FR0000063935;PX1;PAR;FR;FRCG;FRFPR;Oui;Oui BOZ;LANSON-BCC (Ex Boizel Chanoine Champagne);FR0004027068;PX1;PAR;FR;FRCG;FRBEV;Oui;False BRS;BOURSORAMA;FR0000075228;PX1;PAR;FR;FRFIN;FRGF;Oui;False BSD;BOURSE DIRECT;FR0000074254;PX1;PAR;FR;FRFIN;FRGF;Oui;False BSHO;SIIC DE PARIS 8EME;FR0000077844;PX1;PAR;FR;FRFIN;;Oui;False BUI;BARBARA BUI;FR0000062788;PX1;PAR;FR;FRCG;FRPG;Oui;False BULL;BULL REGP;FR0010266601;PX1;PAR;FR;FRTEC;FRTHF;Oui;False BUR;BURELLE;FR0000061137;PX1;PAR;FR;FRCG;FRAP;Oui;False BVD;BELVEDERE;FR0000060873;PX1;PAR;FR;FRCG;FRBEV;Oui;False BVI;BUREAU VERITAS;FR0006174348;PX1;PAR;FR;FRIN;FRSS;Oui;Oui CA;CARREFOUR;FR0000120172;PX1;PAR;FR;FRCS;FRFDR;Oui;Oui CAF;CRCAM PARIS ET IDF;FR0000045528;PX1;PAR;FR;FRFIN;FRB;Oui;False CAFO;CAFOM;FR0010151589;PX1;PAR;FR;FRCS;FRGR;Oui;False CES;CAMELEON SOFTWARE;FR0000074247;PX1;PAR;FR;FRTEC;FRSCS;Oui;False CAMT;CA TOULOUSE 31 CCI;FR0000045544;PX1;PAR;FR;FRFIN;FRB;Oui;False CAP;CAP GEMINI;FR0000125338;PX1;PAR;FR;FRTEC;FRSCS;Oui;Oui CAPLI;CAPELLI;FR0010127530;PX1;PAR;FR;FRFIN;;Oui;False CAS;CAST;FR0000072894;PX1;PAR;FR;FRTEC;FRSCS;Oui;False CATR;CATERPILLAR INC;US1491231015;PX1;PAR;US;FRIN;FRIE;False;False CBSM;SCBSM (BOIS SCIER.MANCHE);FR0006239109;PX1;PAR;FR;FRFIN;;Oui;False CC;CIC CAT.A;FR0005025004;PX1;PAR;FR;FRFIN;FRB;Oui;False CCA;CCA INTERNATIONAL;FR0000078339;PX1;PAR;FR;FRCS;FRMED;Oui;Non CCN;CRCAM NORMANDIE SEINE;FR0000044364;PX1;PAR;FR;FRFIN;FRB;Oui;Non CDA;COMPAGNIE DES ALPES;FR0000053324;PX1;PAR;FR;FRCS;FRTL;Oui;Non CDI;CHRISTIAN DIOR;FR0000130403;PX1;PAR;FR;FRCG;FRPG;Oui;Oui CFCL;CFCAL BANQUE;FR0000064560;PX1;PAR;FR;FRFIN;FRGF;Oui;Non CFDR;COFIDUR;FR0000054629;PX1;PAR;FR;FRIN;FREEE;Oui;Non CFTM;COFITEM;FR0000034431;PX1;PAR;FR;FRFIN;;Oui;Non CGD;CEGID S.A.;FR0000124703;PX1;PAR;FR;FRTEC;FRSCS;Oui;Non CGM;CEGEDIM;FR0000053506;PX1;PAR;FR;FRTEC;FRSCS;Oui;Non CGR;CEGEREAL;FR0010309096;PX1;PAR;FR;FRFIN;;Oui;Non CIB;CIBOX INTERACTIVE;FR0000054322;PX1;PAR;FR;FRTEC;FRTHF;Oui;Non CIMB;IMMOBETELGEUSE;FR0000036725;PX1;PAR;FR;FRFIN;;Oui;Non CIV;CRCAM ILLE-ET-VILAINE.CCI;FR0000045213;PX1;PAR;FR;FRFIN;FRB;Oui;Non CMA;CIMENTS FRANCAIS;FR0000120982;PX1;PAR;FR;FRIN;FRCM;Oui;Oui CMO;CRCAM MORBIHAN CCI;FR0000045551;PX1;PAR;FR;FRFIN;FRB;Oui;Non CNF;CRCAM NORD DE FRANCE;FR0000185514;PX1;PAR;FR;FRFIN;FRB;Oui;Non CNP;CNP ASSURANCES;FR0000120222;PX1;PAR;FR;FRFIN;;Oui;Oui CO;CASINO GUICHARD;FR0000125585;PX1;PAR;FR;FRCS;FRFDR;Oui;Oui COH;COHERIS;FR0004031763;PX1;PAR;FR;FRTEC;FRSCS;Oui;Non COM;CNIM CONSTRUCTION FRF 10;FR0000053399;PX1;PAR;FR;FRIN;FRCM;Oui;Non COTT;COTTIN FRERES;FR0000071854;PX1;PAR;FR;FRCG;FRBEV;Oui;Non COUR;COURTOIS;FR0000065393;PX1;PAR;FR;FRFIN;;Oui;Non COX;NICOX;FR0000074130;PX1;PAR;FR;FRHC;FRPB;Oui;Non CRAP;CRCAM ALPES PROVENCE.CCI;FR0000044323;PX1;PAR;FR;FRFIN;FRB;Oui;Non CRAV;CRCAM ATL.VEND.CCI;FR0000185506;PX1;PAR;FR;FRFIN;FRB;Oui;Non CRBP2;CRCAM BRIE PIC2CCI;FR0010483768;PX1;PAR;FR;FRFIN;FRB;Oui;Non CRI;CHARGEURS;FR0000130692;PX1;PAR;FR;FRCG;FRPG;Oui;Non CRLA;CRCAM LANGUEDOC;FR0010461053;PX1;PAR;FR;FRFIN;FRB;Oui;Non CRLO;CRCAM LOIRE HAUTE LOIRE;FR0000045239;PX1;PAR;FR;FRFIN;FRB;Oui;Non CRSU;CRCAM SUD RHONE ALPES.CCI;FR0000045346;PX1;PAR;FR;FRFIN;FRB;Oui;Non CRTO;CRCAM TOURAINE CCI;FR0000045304;PX1;PAR;FR;FRFIN;FRB;Oui;Non CS;AXA;FR0000120628;PX1;PAR;FR;FRFIN;FRNI;Oui;Oui CSAR;CESAR;FR0010540997;PX1;PAR;FR;FRCG;FRLEG;Oui;Non CTRG;CATERING INTL SERVICES;FR0000064446;PX1;PAR;FR;FRIN;FRSS;Oui;Non CU;CLUB MEDITERRANEE;FR0000121568;PX1;PAR;FR;FRCS;FRTL;Oui;Oui CYB;CYBERGUN;FR0004031839;PX1;PAR;FR;FRCG;FRLEG;Oui;Non CYBX;CYBERNETIX;FR0000036162;PX1;PAR;FR;FRIN;FRIE;Oui;Non DAN;DANE ELEC MEMORY;FR0000036774;PX1;PAR;FR;FRTEC;FRTHF;Oui;Non DAR;DAMARTEX;FR0000185423;PX1;PAR;FR;FRCS;FRGR;Oui;Non DBT;ENCRES DUBUIT;FR0004030708;PX1;PAR;FR;FRBM;;Oui;Non DCH;DELACHAUX;FR0000032195;PX1;PAR;FR;FRIN;FRIE;Oui;Non DEC;JCDECAUX SA.;FR0000077919;PX1;PAR;FR;FRCS;FRMED;Oui;Oui DELF;DELFINGEN;FR0000054132;PX1;PAR;FR;FRCG;FRAP;Oui;Non DG;VINCI;FR0000125486;PX1;PAR;FR;FRIN;FRCM;Oui;Oui DGM;DIAGNOSTIC MEDICAL;FR0000063224;PX1;PAR;FR;FRHC;FRHES;Oui;Non DIDO;CFI;FR0000037475;PX1;PAR;FR;FRCG;FRHG;Oui;Non DIM;SARTORIUS STED BIO;FR0000053266;PX1;PAR;FR;FRHC;FRHES;Oui;Non DNX;DREAMNEX;FR0010436584;PX1;PAR;FR;FRCS;FRGR;Oui;Non DOLY;DOCKS LYONNAIS;FR0000060204;PX1;PAR;FR;FRFIN;;Oui;Non DP;IRD NORD PAS DE CALAIS;FR0000124232;PX1;PAR;FR;FRFIN;FRGF;Oui;Non DPT;ST DUPONT;FR0000054199;PX1;PAR;FR;FRCG;FRPG;Oui;Non FDR;FONCIERE DES REGIONS;FR0000064578;PX1;PAR;FR;FRFIN;;Oui;Oui DSY;DASSAULT SYSTEMES;FR0000130650;PX1;PAR;FR;FRTEC;FRSCS;Oui;Oui DVT;DEVOTEAM;FR0000073793;PX1;PAR;FR;FRTEC;FRSCS;Oui;Non DVTBS;DEVOTEAM BSAR 1112;FR0010379529;PX1;PAR;FR;FRTEC;FRSCS;Oui;Non DYT;DYNACTION;FR0000130353;PX1;PAR;FR;FRBM;;Oui;Non EAD;EADS;NL0000235190;PX1;PAR;NL;FRIN;FRAD;Oui;Oui EADT;ADT S.I.I.C.;FR0000064594;PX1;PAR;FR;FRFIN;;Oui;Non EBI;EBIZCUSS.COM;FR0000078859;PX1;PAR;FR;FRIN;FRSS;Oui;Non EC;TOTAL GABON;GA0000121459;PX1;PAR;GA;FROG;FROGP;Non;Oui ECASA;ECA;FR0010099515;PX1;PAR;FR;FRIN;FRIE;Oui;Non ECP;EUROPACORP;FR0010490920;PX1;PAR;FR;FRCS;FRMED;Oui;Non EDF;EDF;FR0010242511;PX1;PAR;FR;FRUT;;Oui;Oui EDI;MEDIA 6;FR0000064404;PX1;PAR;FR;FRCS;FRMED;Oui;Non EDL;EURO DISNEY;FR0010540740;PX1;PAR;FR;FRCS;FRTL;Oui;Non EEM;ELECTRICITE ET EAUX MADAGASCAR;FR0000035719;PX1;PAR;FR;FRFIN;;Oui;Non EEN;EDF ENERGIES NOUVELLES;FR0010400143;PX1;PAR;FR;FRUT;;Oui;Oui EF;ESSILOR INTERNATIONAL;FR0000121667;PX1;PAR;FR;FRHC;FRHES;Oui;Oui EIFF;TOUR EIFFEL;FR0000036816;PX1;PAR;FR;FRFIN;;Oui;Non ELE;EULER HERMES;FR0004254035;PX1;PAR;FR;FRFIN;FRNI;Oui;Oui ELEC;ELECTRICITE DE STRASBOURG;FR0000031023;PX1;PAR;FR;FRUT;;Oui;Non EMG;EUROMEDIS GROUPE;FR0000075343;PX1;PAR;FR;FRHC;FRHES;Oui;Non EN;BOUYGUES;FR0000120503;PX1;PAR;FR;FRIN;FRCM;Oui;Oui ERA;ERAMET;FR0000131757;PX1;PAR;FR;FRBM;;Oui;Oui ERF;EUROFINS SCIENTIFIC;FR0000038259;PX1;PAR;FR;FRHC;FRPB;Oui;Oui ERSC;EUROSIC;FR0000038200;PX1;PAR;FR;FRFIN;;Oui;Non ES;ESSO;FR0000120669;PX1;PAR;FR;FROG;FROGP;Oui;Non ESI;ESI GROUP;FR0004110310;PX1;PAR;FR;FRTEC;FRSCS;Oui;Non ESRP;ESR;FR0000072969;PX1;PAR;FR;FRTEC;FRSCS;Oui;Non ETL;EUTELSAT COMMUNICATIONS;FR0010221234;PX1;PAR;FR;FRTEC;FRTHF;Oui;Oui EUR;EURO RESSOURCES;FR0000054678;PX1;PAR;FR;FRBM;;Oui;Non EURS;FONCIERE EURIS;FR0000038499;PX1;PAR;FR;FRFIN;;Oui;Non EXE;EXEL INDUSTRIES A;FR0004527638;PX1;PAR;FR;FRIN;FRIE;Oui;Non FATL;FONCIERE ATLAND;FR0000064362;PX1;PAR;FR;FRFIN;;Oui;Non FDL;FDL;FR0000030181;PX1;PAR;FR;FRFIN;;Oui;Non FEL;FONC EUR LOGISTIQ (EX.CITEL);FR0000064305;PX1;PAR;FR;FRFIN;;Oui;Non FEM;AUFEMININ.COM;FR0004042083;PX1;PAR;FR;FRTEC;FRSCS;Oui;Non FFP;FONCIERE FINANCIERE PART;FR0000064784;PX1;PAR;FR;FRFIN;;Oui;Oui FGR;EIFFAGE;FR0000130452;PX1;PAR;FR;FRIN;FRCM;Oui;Oui FID;AFFIPARIS;FR0010148510;PX1;PAR;FR;FRFIN;;Oui;Non FII;LISI (EX GFI INDUSTRIES);FR0000050353;PX1;PAR;FR;FRIN;FRAD;Oui;Non FIM;FIMALAC;FR0000037947;PX1;PAR;FR;FRFIN;FRGF;Oui;Oui FLE;FLEURY MICHON;FR0000074759;PX1;PAR;FR;FRCG;FRFPR;Oui;Non FLO;GROUPE FLO;FR0004076891;PX1;PAR;FR;FRCS;FRTL;Oui;Non FLY;FONCIERE LYONNAISE;FR0000033409;PX1;PAR;FR;FRFIN;;Oui;Non FMU;FONCIERE DES MURS;FR0000060303;PX1;PAR;FR;FRFIN;;Oui;Non FNTS;FINATIS;FR0000035123;PX1;PAR;FR;FRCS;FRFDR;Oui;Non FORDP;FORD MOTOR;US3453708600;PX1;PAR;US;FRCG;FRAP;Non;Non FP;TOTAL;FR0000120271;PX1;PAR;FR;FROG;FROGP;Oui;Oui FPG;UNION TECH.INFOR.;FR0000074197;PX1;PAR;FR;FRTEC;FRSCS;Oui;Non FR;VALEO;FR0000130338;PX1;PAR;FR;FRCG;FRAP;Oui;Oui FREY;FREY;FR0010588079;PX1;PAR;FR;FRFIN;;Oui;Non FROM;ALTAREIT;FR0000039216;PX1;PAR;FR;FRCG;FRFPR;Oui;Non FSER;FIAT EPAR.NCV SICO;IT0001976429;PX1;PAR;IT;FRCG;FRAP;Oui;Non FSOR;FIAT SPA ORD.RGP;IT0001976403;PX1;PAR;IT;FRCG;FRAP;Oui;Non FTE;FRANCE TELECOM;FR0000133308;PX1;PAR;FR;FRTEL;FRFLT;Oui;Oui GA;CGG VERITAS (ex GEOPHYSIQUE);FR0000120164;PX1;PAR;FR;FROG;;Oui;Oui GAM;GAUMONT;FR0000034894;PX1;PAR;FR;FRCS;FRMED;Oui;Non GARD;BISCUITS GARDEIL;FR0000065435;PX1;PAR;FR;FRCG;FRFPR;Oui;Non GBT;GUERBET;FR0000032526;PX1;PAR;FR;FRHC;FRPB;Oui;Non GDMS;GRANDS MOULINS DE STRAS.;FR0000064180;PX1;PAR;FR;FRCG;FRFPR;Oui;Non GDS;GENERALE DE SANTE;FR0000044471;PX1;PAR;FR;FRHC;FRHES;Oui;Oui GEA;GEA GRENOBL.ELECT.;FR0000053035;PX1;PAR;FR;FRIN;FREEE;Oui;Non GECM;GECIMED;FR0000061566;PX1;PAR;FR;FRFIN;;Oui;Non GECP;GECI INTERNATIONAL;FR0000079634;PX1;PAR;FR;FRIN;FRAD;Oui;Non GENP;STALLERGENES;FR0000065674;PX1;PAR;FR;FRHC;FRPB;Oui;Non GENX;GENERIX;FR0010501692;PX1;PAR;FR;FRTEC;FRSCS;Oui;Non GEOF;COFIGEO (EX GEO FINANCIERE);FR0000035008;PX1;PAR;FR;FRCG;FRFPR;Oui;Non GET;GROUPE EUROTUNNEL;FR0010533075;PX1;PAR;FR;FRIN;FRINT;Oui;Non GETBS;GET SA BS;FR0010452441;PX1;PAR;FR;FRIN;FRINT;Oui;Non GFC;GECINA NOMINATIF;FR0010040865;PX1;PAR;FR;FRFIN;;Oui;Oui GFI;GFI;FR0004038099;PX1;PAR;FR;FRTEC;FRSCS;Oui;Oui GFT;GAMELOFT;FR0000079600;PX1;PAR;FR;FRTEC;FRSCS;Oui;Non GG;GUYENNE GASCOGNE;FR0000120289;PX1;PAR;FR;FRCS;FRFDR;Oui;Oui GID;EGIDE;FR0000072373;PX1;PAR;FR;FRIN;FREEE;Oui;Non GIL;GROUPE GUILLIN;FR0000051831;PX1;PAR;FR;FRIN;;Oui;Non GIRO;SIGNAUX GIROD;FR0000060790;PX1;PAR;FR;FRIN;FRIE;Oui;Non GJAJ;GROUPE JAJ (EX JAJ DISTRIBUTION);FR0004010338;PX1;PAR;FR;FRCG;FRPG;Oui;Non GLE;SOCIETE GENERALE;FR0000130809;PX1;PAR;FR;FRFIN;FRB;Oui;Oui GLO;GL EVENTS;FR0000066672;PX1;PAR;FR;FRIN;FRSS;Oui;Non GND;NORBERT DENTRESSANGLE;FR0000052870;PX1;PAR;FR;FRIN;FRINT;Oui;Non FINU;GROUPE GORGE ( EX FINUCHEM);FR0000062671;PX1;PAR;FR;FRIN;FRIE;Oui;Non GPDF;GPE DIFFUSION PLUS;FR0000053449;PX1;PAR;FR;FRCS;FRMED;Oui;Non GPE;GROUPE PIZZORNO ENVIRONNEMENT;FR0010214064;PX1;PAR;FR;FRUT;FRGWM;Oui;Non GREV;MUSEE GREVIN;FR0000037970;PX1;PAR;FR;FRCS;FRTL;Oui;Non GSP;GROUPE GO SPORT;FR0000072456;PX1;PAR;FR;FRCS;FRGR;Oui;Non GSZ;GDF SUEZ;FR0010208488;PX1;PAR;FR;FRUT;FRGWM;Oui;Oui GUI;GUILLEMOT;FR0000066722;PX1;PAR;FR;FRTEC;FRSCS;Oui;Non GUYD;GUY DEGRENNE;FR0004035061;PX1;PAR;FR;FRCG;FRHG;Oui;Non HAV;HAVAS;FR0000121881;PX1;PAR;FR;FRCS;FRMED;Oui;Oui HBW;HUBWOO.COM;FR0004052561;PX1;PAR;FR;FRTEC;FRSCS;Oui;Non HCL;HUIS CLOS;FR0000072357;PX1;PAR;FR;FRIN;FRCM;Oui;Non HCO;HIGH CO;FR0000054231;PX1;PAR;FR;FRCS;FRMED;Oui;Non HF;HF COMPANY;FR0000038531;PX1;PAR;FR;FRTEC;FRTHF;Oui;Non HIM;HI MEDIA;FR0000075988;PX1;PAR;FR;FRCS;FRMED;Oui;Non HO;THALES;FR0000121329;PX1;PAR;FR;FRIN;FRAD;Oui;Oui HOL;HOLOGRAM INDUSTRIES;FR0000062168;PX1;PAR;FR;FRIN;FRSS;Oui;Non IAM;MAROC TELECOM;MA0000011488;PX1;PAR;MA;FRTEL;FRFLT;Non;Oui ICAD;ICADE;FR0000035081;PX1;PAR;FR;FRFIN;;Oui;Non IDIP;IDI;FR0000051393;PX1;PAR;FR;FRFIN;;Oui;Non IDSU;IDSUD;FR0000062184;PX1;PAR;FR;FRFIN;FRGF;Oui;Non IEC;IEC PROFESSIONNEL MEDIA;FR0000066680;PX1;PAR;FR;FRCS;FRMED;Oui;Non IFV;INFOVISTA;FR0004031649;PX1;PAR;FR;FRTEC;FRSCS;Oui;Non IGE;IGE + XAO;FR0000030827;PX1;PAR;FR;FRTEC;FRSCS;Oui;Non IGF;GIFI;FR0000075095;PX1;PAR;FR;FRCS;FRGR;Oui;Non ILD;ILIAD ( FREE );FR0004035913;PX1;PAR;FR;FRTEC;FRSCS;Oui;Oui IMDA;IMMOBILIERE DASSAULT;FR0000033243;PX1;PAR;FR;FRFIN;;Oui;Non IML;AFFINE;FR0000036105;PX1;PAR;FR;FRFIN;;Oui;Non IMMP;SIIC DE PARIS;FR0000057937;PX1;PAR;FR;FRFIN;;Oui;Non IMS;IMS INTERNATIONAL METAL SCE;FR0000033904;PX1;PAR;FR;FRBM;;Oui;Non INEA;FONCIERE INEA;FR0010341032;PX1;PAR;FR;FRFIN;;Oui;Non INF;INFOTEL;FR0000071797;PX1;PAR;FR;FRTEC;FRSCS;Oui;Non ING;INGENICO;FR0000125346;PX1;PAR;FR;FRIN;FREEE;Oui;Oui INN;INNELEC MULTIMEDIA;FR0000064297;PX1;PAR;FR;FRTEC;FRSCS;Oui;Non IPH;INNATE PHARMA;FR0010331421;PX1;PAR;FR;FRHC;FRPB;Oui;Non IPN;IPSEN;FR0010259150;PX1;PAR;FR;FRHC;FRPB;Oui;Oui IPS;IPSOS;FR0000073298;PX1;PAR;FR;FRCS;FRMED;Oui;Oui ITE;ITESOFT;FR0004026151;PX1;PAR;FR;FRTEC;FRSCS;Oui;Non ITL;IT LINK;FR0000072597;PX1;PAR;FR;FRTEC;FRSCS;Oui;Non ITP;INTER PARFUMS;FR0004024222;PX1;PAR;FR;FRCG;FRPG;Oui;Non ITS;ITS GROUP;FR0000073843;PX1;PAR;FR;FRTEC;FRSCS;Oui;Non ITT;I.T.T.INDUSTRIES;US4509111021;PX1;PAR;US;FRIN;;Non;Non JEAN;ADVINI;FR0000053043;PX1;PAR;FR;FRCG;FRBEV;Oui;Non JXR;ARCHOS;FR0000182479;PX1;PAR;FR;FRCG;FRLEG;Oui;Non KAZI;ORCHESTRA.KAZIBAO REGRT;FR0010160564;PX1;PAR;FR;FRCG;FRPG;Oui;Non KEY;KEYRUS;FR0004029411;PX1;PAR;FR;FRTEC;FRSCS;Oui;Non KEYYO;KEYYO (EX.PHONE SYSTEM REGR);FR0000185621;PX1;PAR;FR;FRTEL;FRFLT;Oui;Non KIND;KINDY;FR0000052904;PX1;PAR;FR;FRCG;FRPG;Oui;Non KMU;KLEMURS;FR0010404780;PX1;PAR;FR;FRFIN;;Oui;Non KN;NATIXIS;FR0000120685;PX1;PAR;FR;FRFIN;FRB;Oui;Oui KOF;KAUFMAN ET BROAD;FR0004007813;PX1;PAR;FR;FRCG;FRHG;Oui;Oui KORI;KORIAN;FR0010386334;PX1;PAR;FR;FRHC;FRHES;Oui;Non KSA;KESA ELECTRICALS PLC;GB0033040113;PX1;PAR;GB;FRCS;FRGR;Oui;Non LAC;LACIE S.A.;FR0000054314;PX1;PAR;FR;FRTEC;FRTHF;Oui;Non LACR;LACROIX SA;FR0000066607;PX1;PAR;FR;FRIN;FREEE;Oui;Non LAF;LAFUMA;FR0000035263;PX1;PAR;FR;FRCG;FRPG;Oui;Non LAGB;LAGARDERE ACTIVE BROADCAST;MC0000120790;PX1;PAR;MC;FRCS;FRMED;Oui;Non LAT;AVIATION LATECOERE;FR0000032278;PX1;PAR;FR;FRIN;FRAD;Oui;Non LBON;LEBON;FR0000121295;PX1;PAR;FR;FRFIN;;Oui;Non LCO;SOLUCOM;FR0004036036;PX1;PAR;FR;FRTEC;FRSCS;Oui;Non LD;LOCINDUS;FR0000121352;PX1;PAR;FR;FRFIN;;Oui;Non LDL;LDLC COM;FR0000075442;PX1;PAR;FR;FRCS;FRGR;Oui;Non LEX;LEXIBOOK LINGUIST.;FR0000033599;PX1;PAR;FR;FRCG;FRLEG;Oui;Non LEY;FAIVELEY;FR0000053142;PX1;PAR;FR;FRIN;FRIE;Oui;Non LG;LAFARGE;FR0000120537;PX1;PAR;FR;FRIN;FRCM;Oui;Oui LI;KLEPIERRE;FR0000121964;PX1;PAR;FR;FRFIN;;Oui;Oui LIN;LINEDATA SERVICES;FR0004156297;PX1;PAR;FR;FRTEC;FRSCS;Oui;Non LNA;LE NOBLE AGE;FR0004170017;PX1;PAR;FR;FRHC;FRHES;Oui;Non LNC;LES NOUVEAUX CONSTRUCTEURS;FR0004023208;PX1;PAR;FR;FRCG;FRHG;Oui;Non LOUP;LDC;FR0000053829;PX1;PAR;FR;FRCG;FRFPR;Oui;Non LPE;LAURENT-PERRIER;FR0006864484;PX1;PAR;FR;FRCG;FRBEV;Oui;Non LR;LEGRAND SA;FR0010307819;PX1;PAR;FR;FRIN;FREEE;Oui;Oui LSS;LECTRA;FR0000065484;PX1;PAR;FR;FRTEC;FRSCS;Oui;Non LTA;ALTAMIR AMBOISE;FR0000053837;PX1;PAR;FR;FRFIN;;Oui;Non LTAN;LE TANNEUR;FR0000075673;PX1;PAR;FR;FRCG;FRPG;Oui;Non LTE;VALTECH;FR0004155885;PX1;PAR;FR;FRTEC;FRSCS;Oui;Non LVL;LVL MEDICAL GROUPE;FR0000054686;PX1;PAR;FR;FRHC;FRHES;Oui;Non MALA;GRAND MARNIER;FR0000038036;PX1;PAR;FR;FRCG;FRBEV;Oui;Non MAN;MANUTAN INTL;FR0000032302;PX1;PAR;FR;FRIN;FRSS;Oui;Non MAU;MAUREL ET PROM;FR0000051070;PX1;PAR;FR;FROG;FROGP;Oui;Oui MC;LVMH MOET VUITTON;FR0000121014;PX1;PAR;FR;FRCG;FRPG;Oui;Oui MCLC;MECELEC;FR0000061244;PX1;PAR;FR;FRIN;FREEE;Oui;Non MDL;MODELABS GROUP;FR0010060665;PX1;PAR;FR;FRTEC;FRTHF;Oui;Non MED;MEDASYS;FR0000052623;PX1;PAR;FR;FRHC;FRHES;Oui;Non MEDE;MEDEA (EX.UGIGRIP);FR0000063323;PX1;PAR;FR;FRCG;FRAP;Oui;Non MEET;MEETIC;FR0004063097;PX1;PAR;FR;FRTEC;FRSCS;Oui;Non MEMS;MEMSCAP REGPT;FR0010298620;PX1;PAR;FR;FRTEC;FRTHF;Oui;Non MERY;MERCIALYS;FR0010241638;PX1;PAR;FR;FRFIN;;Oui;Oui METEX;METABOLIC EXPLORER;FR0004177046;PX1;PAR;FR;FRBM;;Oui;Non MF;WENDEL;FR0000121204;PX1;PAR;FR;FRFIN;FRGF;Oui;Oui MFC;MAISONS FRANCE CONFORT;FR0004159473;PX1;PAR;FR;FRCG;FRHG;Oui;Non MGIC;MGI COUTIER;FR0000053027;PX1;PAR;FR;FRCG;FRAP;Oui;Non ML;MICHELIN;FR0000121261;PX1;PAR;FR;FRCG;FRAP;Oui;Oui HIO;HIOLLE INDUSTRIES;FR0000077562;PX1;PAR;FR;FRIN;FRIE;Oui;Non MLVST;TELEVISTA;FR0010489658;;;FR;;;; MMB;LAGARDERE;FR0000130213;PX1;PAR;FR;FRCS;FRMED;Oui;Oui MMT;METROPOLE TV (M6);FR0000053225;PX1;PAR;FR;FRCS;FRMED;Oui;Oui MON;MONTUPET SA;FR0000037046;PX1;PAR;FR;FRCG;FRAP;Oui;Non MRB;MR BRICOLAGE;FR0004034320;PX1;PAR;FR;FRCS;FRGR;Oui;Non MRM;MRM;FR0000060196;PX1;PAR;FR;FRFIN;;Oui;Non CRL;MERSEN ( ex CARBONE LORRAINE);FR0000039620;PX1;PAR;FR;FRIN;FREEE;Oui;Oui MTG;METROLOGIC GROUP;FR0000073975;PX1;PAR;FR;FRTEC;FRSCS;Oui;Non MTU;MANITOU BF;FR0000038606;PX1;PAR;FR;FRIN;FRIE;Oui;Oui MUL;INDEX MULTIMEDIA;FR0004061513;PX1;PAR;FR;FRTEL;FRFLT;Oui;Non MUN;MICROPOLE;FR0000077570;PX1;PAR;FR;FRTEC;FRSCS;Oui;Non NEO;NEOPOST;FR0000120560;PX1;PAR;FR;FRTEC;FRTHF;Oui;Oui NERG;NERGECO;FR0000037392;PX1;PAR;FR;FRIN;FRCM;Oui;Non NEX;NEXANS;FR0000044448;PX1;PAR;FR;FRIN;FREEE;Oui;Oui NK;IMERYS;FR0000120859;PX1;PAR;FR;FRIN;FRCM;Oui;Oui NRG;NRJ GROUP;FR0000121691;PX1;PAR;FR;FRCS;FRMED;Oui;Oui NRO;NEURONES;FR0004050250;PX1;PAR;FR;FRTEC;FRSCS;Oui;Non NTG;NETGEM;FR0004154060;PX1;PAR;FR;FRTEC;FRSCS;Oui;Non NXI;NEXITY;FR0010112524;PX1;PAR;FR;FRCG;FRHG;Oui;Oui NXTV;NEXTRADIOTV;FR0010240994;PX1;PAR;FR;FRCS;FRMED;Oui;Non NYX;NYSE EURONEXT;US6294911010;PX1;PAR;US;FRFIN;FRGF;Non;Oui ODET;FINANCIERE ODET;FR0000062234;PX1;PAR;FR;FRFIN;FRGF;Oui;Non OLG;OL GROUPE;FR0010428771;PX1;PAR;FR;FRCS;FRMED;Oui;Non OLV;SOLVING EFESO INTERNATIONAL;FR0004500106;PX1;PAR;FR;FRIN;FRSS;Oui;Non OMT;OUTREMER TELECOM;FR0010425587;PX1;PAR;FR;FRTEL;FRFLT;Oui;Non OPEC;OFI PRIV EQU CAP;FR0000038945;PX1;PAR;FR;FRFIN;;Oui;Non OPN;GROUPE OPEN;FR0004050300;PX1;PAR;FR;FRTEC;FRSCS;Oui;Non OPNBS;GROPEN BSAAR0914;FR0010518688;PX1;PAR;FR;FRTEC;FRSCS;Oui;Non OR;L'OREAL;FR0000120321;PX1;PAR;FR;FRCG;FRPG;Oui;Oui ORAP;ORAPI;FR0000075392;PX1;PAR;FR;FRBM;;Oui;Non ORC;ORCO PROPERTY GROUP;LU0122624777;PX1;PAR;LU;FRFIN;;Oui;Oui ORG;ORGASYNTH;FR0000054611;PX1;PAR;FR;FRBM;;Oui;Non ORIA;FIDUCIAL REAL ESTATE;FR0000060535;PX1;PAR;FR;FRFIN;;Oui;Non ORP;ORPEA;FR0000184798;PX1;PAR;FR;FRHC;FRHES;Oui;Oui OSA;OSIATIS;FR0004044337;PX1;PAR;FR;FRTEC;FRSCS;Oui;Non OSI;AUSY;FR0000072621;PX1;PAR;FR;FRTEC;FRSCS;Oui;Non OXI;OXIS INTERNATIONAL;US6918294025;PX1;PAR;US;FRHC;FRPB;Non;Non PAJ;PAGES JAUNES;FR0010096354;PX1;PAR;FR;FRCS;FRMED;Oui;Oui PAOR;PARIS-ORLEANS;FR0000031684;PX1;PAR;FR;FRFIN;FRGF;Oui;Non PAR;PAREF;FR0010263202;PX1;PAR;FR;FRFIN;;Oui;Non PARP;GROUPE PARTOUCHE;FR0000053548;PX1;PAR;FR;FRCS;FRTL;Oui;Non PARRO;PARROT;FR0004038263;PX1;PAR;FR;FRTEC;FRTHF;Oui;Non PCA;PCAS;FR0000053514;PX1;PAR;FR;FRBM;;Oui;Non PERR;GERARD PERRIER INDUSTRIE;FR0000061459;PX1;PAR;FR;FRIN;FREEE;Oui;Non IME;LA PERLA WORLD (EX.MANDARINE HOLDING);FR0000064917;PX1;PAR;FR;FRTEC;FRSCS;Oui;Non PGP;PROCTER GAMBLE;US7427181091;PX1;PAR;US;FRCG;FRHG;Non;Non PHA;PHARMAGEST INTER.;FR0000077687;PX1;PAR;FR;FRTEC;FRSCS;Oui;Non PHY;ALES GROUPE;FR0000054652;PX1;PAR;FR;FRCG;FRPG;Oui;Non PIG;HAULOTTE GROUP;FR0000066755;PX1;PAR;FR;FRIN;FRIE;Oui;Oui POM;PLASTIC OMNIUM;FR0000124570;PX1;PAR;FR;FRCG;FRAP;Oui;Non PONY;PONCIN YACHTS;FR0010193052;PX1;PAR;FR;FRCG;FRLEG;Oui;Non PP;PPR (ex PINAULT PRINTEMPS);FR0000121485;PX1;PAR;FR;FRCS;FRGR;Oui;Oui DBG;DERICHEBOURG;FR0000053381;PX1;PAR;FR;FRIN;FRSS;Oui;Oui PRC;ARTPRICE COM;FR0000074783;PX1;PAR;FR;FRCS;FRMED;Oui;Non PREC;PRECIA;FR0000060832;PX1;PAR;FR;FRIN;FREEE;Oui;Non PSAT;PASSAT;FR0000038465;PX1;PAR;FR;FRCS;FRMED;Oui;Non PSB;PSB INDUSTRIES;FR0000060329;PX1;PAR;FR;FRIN;;Oui;Non PSY;PARSYS;FR0000062721;PX1;PAR;FR;FRTEC;FRSCS;Oui;Non PUB;PUBLICIS GROUPE;FR0000130577;PX1;PAR;FR;FRCS;FRMED;Oui;Oui PUBBS;PUBLICIS BSA;FR0000312928;PX1;PAR;FR;FRCS;FRMED;Oui;Non PUS;PUBLIC SYSTEME HOP;FR0000065278;PX1;PAR;FR;FRCS;FRMED;Oui;Non PVL;PLASTIVALOIRE;FR0000051377;PX1;PAR;FR;FRBM;;Oui;Non QUA;QUANTEL;FR0000038242;PX1;PAR;FR;FRHC;FRHES;Oui;Non RAL;RALLYE;FR0000060618;PX1;PAR;FR;FRCS;FRGR;Oui;Oui RAN;SYSTRAN;FR0004109197;PX1;PAR;FR;FRTEC;FRSCS;Oui;Non RBT;ROBERTET;FR0000039091;PX1;PAR;FR;FRBM;;Oui;Non RCF;TELEPERFORMANCE;FR0000051807;PX1;PAR;FR;FRCS;FRMED;Oui;Oui RCO;REMY COINTREAU;FR0000130395;PX1;PAR;FR;FRCG;FRBEV;Oui;Oui RDC;RUE DU COMMERCE;FR0004053338;PX1;PAR;FR;FRTEC;FRSCS;Oui;Non RE;COLAS;FR0000121634;PX1;PAR;FR;FRIN;FRCM;Oui;Non RF;EURAZEO;FR0000121121;PX1;PAR;FR;FRFIN;FRGF;Oui;Oui RGR;ROUGIER S.A.;FR0000037640;PX1;PAR;FR;FRIN;FRCM;Oui;Non MFG;MONTAIGNE FASHION (ex REGINA);FR0004048734;PX1;PAR;FR;FRCG;FRPG;Oui;Non RHA;RHODIA;FR0010479956;PX1;PAR;FR;FRBM;;Oui;Oui RI;PERNOD RICARD;FR0000120693;PX1;PAR;FR;FRCG;FRBEV;Oui;Oui RIA;GROUPE STERIA;FR0000072910;PX1;PAR;FR;FRTEC;FRSCS;Oui;Oui RIB;RIBER;FR0000075954;PX1;PAR;FR;FRTEC;FRTHF;Oui;Non RIN;VILMORIN & CIE;FR0000052516;PX1;PAR;FR;FRCG;FRFPR;Oui;Oui RLL;RADIALL;FR0000050320;PX1;PAR;FR;FRTEC;FRTHF;Oui;Non RMS;HERMES INTERNATIONAL;FR0000052292;PX1;PAR;FR;FRCG;FRPG;Oui;Oui RNO;RENAULT;FR0000131906;PX1;PAR;FR;FRCG;FRAP;Oui;Oui ROBP;ROBECO;NL0000289783;PX1;PAR;NL;FRFIN;;Non;Non ROD;RODRIGUEZ GROUP;FR0000062994;PX1;PAR;FR;FRCG;FRLEG;Oui;Oui ROLP;ROLINCO;NL0000289817;PX1;PAR;NL;FRFIN;;Non;Non RORP;RORENTO;ANN757371433;PX1;PAR;AN;FRFIN;;Non;Non RSC;RISC GROUP;FR0010542647;PX1;PAR;FR;FRTEC;FRSCS;Oui;Non RTZ;RIO TINTO ORD;GB0007188757;PX1;PAR;GB;FRBM;;Oui;Non RUI;RUBIS;FR0000121253;PX1;PAR;FR;FRUT;FRGWM;Oui;Non RX;RECYLEX;FR0000120388;PX1;PAR;FR;FRBM;;Oui;Non RXL;REXEL;FR0010451203;PX1;PAR;FR;FRIN;FRSS;Oui;Oui SABE;SABETON;FR0000060121;PX1;PAR;FR;FRFIN;;Oui;Non SACI;FIDUCIAL OFFICE SOLU(EX SACI);FR0000061418;PX1;PAR;FR;FRCS;FRGR;Oui;Non SAF;SAFRAN;FR0000073272;PX1;PAR;FR;FRIN;FRAD;Oui;Oui SAFT;SAFT;FR0010208165;PX1;PAR;FR;FRIN;FREEE;Oui;Non SAMP;SAM;FR0000044497;PX1;PAR;FR;FRIN;FRIE;Oui;Non SAMS;SAMSE;FR0000060071;PX1;PAR;FR;FRIN;FRCM;Oui;Non SAN;SANOFI-AVENTIS;FR0000120578;PX1;PAR;FR;FRHC;FRPB;Oui;Oui SAR;SYSTAR;FR0000052854;PX1;PAR;FR;FRTEC;FRSCS;Oui;Non SBTBR;OENEO BS;FR0010203299;PX1;PAR;FR;FRCG;FRBEV;Oui;Non SCDU;SCHAEFFER DUFOUR;FR0000064511;PX1;PAR;FR;FRCG;FRPG;Oui;Non SCDV;SECURIDEV;FR0000052839;PX1;PAR;FR;FRIN;FRSS;Oui;Non SCHP;SECHE ENVIRONNEMENT;FR0000039109;PX1;PAR;FR;FRIN;FRSS;Oui;Oui SCR;SCOR SE;FR0010411983;PX1;PAR;FR;FRFIN;FRNI;Oui;Oui SDG;SYNERGIE;FR0000032658;PX1;PAR;FR;FRIN;FRSS;Oui;Non SDT;VISIODENT;FR0000065765;PX1;PAR;FR;FRTEC;FRSCS;Oui;Non SECH;SECHILIENNE-SIDEC;FR0000060402;PX1;PAR;FR;FRUT;;Oui;Oui SELER;SELECTIRENTE;FR0004175842;PX1;PAR;FR;FRFIN;;Oui;Non VOR;SEQUANA;FR0000063364;PX1;PAR;FR;FRBM;;Oui;Oui SESG;SES GLOBAL FDR;LU0088087324;PX1;PAR;LU;FRCS;FRMED;Non;Oui SESL;STORE ELECTRONIC;FR0010282822;PX1;PAR;FR;FRIN;FREEE;Oui;Non SEV;SUEZ ENVIRONNEMENT COMPANY;FR0010613471;PX1;PAR;FR;FRUT;FRGWM;Oui;Oui FPF;FONCIERE PARIS FRANCE;FR0010304329;PX1;PAR;FR;FRFIN;;Oui;Non SFT;SOFT COMPUTING;FR0000075517;PX1;PAR;FR;FRTEC;FRSCS;Oui;Non SGO;SAINT GOBAIN;FR0000125007;PX1;PAR;FR;FRIN;FRCM;Oui;Oui SII;SII;FR0000074122;PX1;PAR;FR;FRTEC;FRSCS;Oui;Non SIL;SILIC;FR0000050916;PX1;PAR;FR;FRFIN;;Oui;Oui SIPH;INTLE PLANT.HEVEAS;FR0000036857;PX1;PAR;FR;FRCG;FRFPR;Oui;Non SIRA;SIRAGA;FR0000060170;PX1;PAR;FR;FRIN;FRIE;Oui;Non SIX;SIPAREX CROISSANCE;FR0000061582;PX1;PAR;FR;FRFIN;;Oui;Non SK;SEB;FR0000121709;PX1;PAR;FR;FRCG;FRHG;Oui;Oui SLB;SCHLUMBERGER;AN8068571086;PX1;PAR;AN;FROG;;Non;Oui SLG;SELOGER.COM;FR0010294595;PX1;PAR;FR;FRTEC;FRSCS;Oui;Non SMTPC;SMTPC;FR0004016699;PX1;PAR;FR;FRIN;FRINT;Oui;Non SO;SOMFY;FR0000120495;PX1;PAR;FR;FRIN;FREEE;Oui;Non SOCM;FONCIERE MASSENA (ex SOCIM);FR0000037210;PX1;PAR;FR;FRFIN;;Oui;Non SOFR;SOFRAGI;FR0000030140;PX1;PAR;FR;FRFIN;;Oui;Non SOG;SOGECLAIR;FR0000065864;PX1;PAR;FR;FRTEC;FRSCS;Oui;Non SOI;SOITEC SILICON;FR0004025062;PX1;PAR;FR;FRTEC;FRTHF;Oui;Oui SOP;SOPRA GROUP;FR0000050809;PX1;PAR;FR;FRTEC;FRSCS;Oui;Oui SPEL;FONCIERE VOLTA;FR0000053944;PX1;PAR;FR;FRCG;FRPG;Oui;Non SPH;SINCLAIR PHARMA;GB0033856740;PX1;PAR;GB;FRHC;FRPB;Oui;Non SPI;SPIR COMMUNICATION;FR0000131732;PX1;PAR;FR;FRCS;FRMED;Oui;Non SPV;SUCRIERE PITHIVIERS;FR0000033318;PX1;PAR;FR;FRCG;FRFPR;Oui;Non SQI;SQLI;FR0004045540;PX1;PAR;FR;FRTEC;FRSCS;Oui;Non SRG;FONCIERE 6 ET 7;FR0010436329;PX1;PAR;FR;FRFIN;;Oui;Non STAL;INSTALLUX;FR0000060451;PX1;PAR;FR;FRIN;FRCM;Oui;Non STF;STEF TFE;FR0000064271;PX1;PAR;FR;FRIN;FRINT;Oui;Non STM;STMICROELECTRONICS;NL0000226223;PX1;PAR;NL;FRTEC;FRTHF;Oui;Oui SU;SCHNEIDER ELECTRIC;FR0000121972;PX1;PAR;FR;FRIN;FREEE;Oui;Oui SW;SODEXO;FR0000121220;PX1;PAR;FR;FRCS;FRTL;Oui;Oui SWP;SWORD GROUP;FR0004180578;PX1;PAR;FR;FRTEC;FRSCS;Oui;Non SX;CS (COMMUNICATION & SYSTEMES);FR0007317813;PX1;PAR;FR;FRTEC;FRSCS;Oui;Non SY;SALVEPAR;FR0000124356;PX1;PAR;FR;FRFIN;;Oui;Non AEDI;AEDIAN;FR0004005924;PX1;PAR;FR;FRTEC;FRSCS;Oui;Non TAM;ETAM DEVELOPPEMENT;FR0000035743;PX1;PAR;FR;FRCS;FRGR;Oui;Non TAYN;TAYNINH;FR0000063307;PX1;PAR;FR;FRFIN;;Oui;Non TEC;TECHNIP;FR0000131708;PX1;PAR;FR;FROG;;Oui;Oui TEF;TESFRAN;FR0010358812;PX1;PAR;FR;FRFIN;;Oui;Non TEO;THEOLIA;FR0000184814;PX1;PAR;FR;FRUT;;Oui;Non TER;TERREÏS;FR0010407049;PX1;PAR;FR;FRFIN;;Oui;Non TES;TESSI;FR0004529147;PX1;PAR;FR;FRTEC;FRSCS;Oui;Non TFF;TONN.FRANCOIS FRES;FR0000071904;PX1;PAR;FR;FRCG;FRBEV;Oui;Non TFI;TF1;FR0000054900;PX1;PAR;FR;FRCS;FRMED;Oui;Oui THEP;THERMADOR GROUPE;FR0000061111;PX1;PAR;FR;FRIN;FRSS;Oui;Non THER;THERMOCOMPACT;FR0004037182;PX1;PAR;FR;FRIN;FRIE;Oui;Non TIPI;TIPIAK;FR0000066482;PX1;PAR;FR;FRCG;FRFPR;Oui;Non TLC;TR SERVICES;FR0000071763;PX1;PAR;FR;FRTEC;FRSCS;Oui;Non TMS;TECHNICOLOR NR;FR0000184533;PX1;PAR;FR;FRCS;FRMED;Oui;Oui TNG;TRANSGENE;FR0005175080;PX1;PAR;FR;FRHC;FRPB;Oui;Non TONN;TONNA ELECTRONIQUE;FR0000064388;PX1;PAR;FR;FRTEC;FRTHF;Oui;Non TOU;TOUPARGEL;FR0000039240;PX1;PAR;FR;FRCS;FRFDR;Oui;Non TOUP;TOUAX;FR0000033003;PX1;PAR;FR;FRIN;FRINT;Oui;Non TRI;TRIGANO;FR0005691656;PX1;PAR;FR;FRCG;FRLEG;Oui;Oui TRNO;BANQUE TARNEAUD;FR0000065526;PX1;PAR;FR;FRFIN;FRB;Oui;Non TVLY;TIVOLY;FR0000060949;PX1;PAR;FR;FRIN;FRIE;Oui;Non COI;UNITED ANODISERS (EX.COIL);BE0160342011;PX1;PAR;BE;FRBM;;Oui;Non UBI;UBISOFT ENTERTAIN;FR0000054470;PX1;PAR;FR;FRTEC;FRSCS;Oui;Oui UDIBR;U10 BSAR 0313;FR0010286542;PX1;PAR;FR;FRCG;FRHG;Oui;Non UDIS;U10;FR0000079147;PX1;PAR;FR;FRCG;FRHG;Oui;Non UFF;UNION FIN.FRANCE;FR0000034548;PX1;PAR;FR;FRFIN;FRGF;Oui;Non UG;PEUGEOT;FR0000121501;PX1;PAR;FR;FRCG;FRAP;Oui;Oui UL;UNIBAIL-RODAMCO;FR0000124711;PX1;PAR;FR;FRFIN;;Oui;Oui ULDV;ULRIC DE VARENS;FR0000079980;PX1;PAR;FR;FRCG;FRPG;Oui;Non VA;ANGLOGOLD LTD;ZAE000043485;PX1;PAR;ZA;FRBM;;Non;Non VAC;PIERRE VACANCES;FR0000073041;PX1;PAR;FR;FRCS;FRTL;Oui;Non MDG;MAKHEIA GROUP;FR0000072993;PX1;PAR;FR;FRCS;FRMED;Oui;Non ARG;ARGAN;FR0010481960;PX1;PAR;FR;FRFIN;;Oui;Non BOAF;BRASSERIES DE L OUEST AFRICAIN;SN0008626971;PX1;PAR;SN;FRCG;FRBEV;Non;Non BQRE;BANQUE DE LA REUNION;FR0000039612;PX1;PAR;FR;FRFIN;FRB;Oui;Non EBPF;FIN.ETANG BERRE PF;FR0000062507;PX1;PAR;FR;FRFIN;;Non;Non FBEL;FROMAGERIES BEL;FR0000121857;PX1;PAR;FR;FRCG;FRFPR;Oui;Non GBB;BOURBON;FR0004548873;PX1;PAR;FR;FROG;;Oui;Oui MPE;MONDIAL PECHE;FR0000062853;PX1;PAR;FR;FRCS;FRGR;Oui;Non NRX;NATUREX;FR0000054694;PX1;PAR;FR;FRCG;FRFPR;Oui;Non PRS;PRISMAFLEX INTL;FR0004044600;PX1;PAR;FR;FRCS;FRMED;Oui;Non SBT;OENEO (EX SABATE DIOSOS);FR0000052680;PX1;PAR;FR;FRCG;FRBEV;Oui;Non SOA;SODIFRANCE;FR0000072563;PX1;PAR;FR;FRTEC;FRSCS;Oui;Non UNM;UNIVERSAL MULTIMEDIA;FR0000057903;PX1;PAR;FR;FRCG;FRLEG;Oui;Non ALADV;ADVERLINE;FR0004176337;;;FR;;;; ALCLS;CELLECTIS;FR0010425595;;;FR;;;; ALECT;ECT INDUSTRIES;FR0004065639;;;FR;;;; MLESY;SAFETIC;FR0010100016;;;FR;;;; ALEHT;EXONHIT THERAPEUTICS;FR0004054427;;;FR;;;; OPNBR;GRPOPEN BSAR 0809;FR0010107185;PX1;PAR;FR;FRTEC;FRSCS;Oui;Non IFGBS;INFOGRAMES BSA;FR0010413237;PX1;PAR;FR;FRTEC;FRSCS;Oui;Non CAL;INTERCALL REDUCT.;FR0000044901;PX1;PAR;FR;FRTEL;FRFLT;Oui;Non WFI;LISI 47 BSAR 0510;FR0010075663;PX1;PAR;FR;FRIN;FRAD;Oui;Non MEMBS;MEMSCAPBSAF1208;FR0010262345;PX1;PAR;FR;FRTEC;FRTHF;Oui;Non MFGBS;MONTAIGNEBSA 1208;FR0010275032;PX1;PAR;FR;FRCG;FRPG;Oui;Non RICOP;RICOH CO. LTD;JP3973400009;PX1;PAR;JP;FRTEC;FRTHF;Non;Non SGR;SEGRO;GB00B1YFN979;PX1;PAR;GB;FRFIN;;Oui;Non SOM;SOFTWAY MEDICAL;FR0000054637;PX1;PAR;FR;FRTEC;FRSCS;Oui;Non STIL;STILFONTEIN GOLD;ZAE000007118;PX1;PAR;ZA;FRBM;;Non;Non TIPBS;TEAM PAR BSA13;FR0010619510;PX1;PAR;FR;FRTEC;FRSCS;Oui;Non TOUBS;TOUAX BS 0313;FR0010585224;PX1;PAR;FR;FRIN;FRINT;Oui;Non TOUBR;TOUAXBSAR0312;FR0010435438;PX1;PAR;FR;FRIN;FRINT;Oui;Non VALE3;VALE;US2044122099;PX1;PAR;US;FRBM;;Non;Non VALE5;VALE PREF;US2044121000;PX1;PAR;US;FRBM;;Non;Non ASBBS;ASSYSTEM BRIME BSAR 2012;FR0010166371;PX1;PAR;FR;FRTEC;FRSCS;Oui;Non ALGEM;EUROGERM;FR0010452474;;;FR;;;; ALGEN;GENOWAY;FR0004053510;;;FR;;;; ALHYG;HYBRIGENICS;FR0004153930;;;FR;;;; ALIVT;INVENTORISTE (L');FR0010082305;;;FR;;;; ALMAS;MASTRAD;FR0004155687;;;FR;;;; ALMAX;MAXIMILES;FR0004174233;;;FR;;;; ALMED;MEDICREA INTERNAT.;FR0004178572;;;FR;;;; ALMEO;GROUPE PROMEO;FR0010254466;;;FR;;;; ALSAT;MICROWAVE VISION (EX.SATIMO);FR0004058949;;;FR;;;; ALMIL;1000MERCIS;FR0010285965;;;FR;;;; ALMIN;MINDSCAPE;FR0010257428;;;FR;;;; ALNBT;NETBOOSTER;FR0000079683;;;FR;;;; ALNFA;NOTREFAMILLE.COM;FR0010221069;;;FR;;;; ALOBR;OBER;FR0010330613;;;FR;;;; ALOCT;OCTO TECHNOLOGY;FR0004157428;;;FR;;;; ALMAE;MAESA;FR0010288894;;;FR;;;; ALPGG;PISCINES GROUPE GA;FR0010357145;;;FR;;;; ALPRO;PRODWARE;FR0010313486;;;FR;;;; ALPWO;POWEO;FR0004191674;;;FR;;;; ALRAI;GECI AVIATION;FR0010449199;;;FR;;;; ALSDL;DL SOFTWARE;FR0010357079;;;FR;;;; ALSPO;SPOREVER;FR0010213215;;;FR;;;; ALDMO;DEMOS;FR0010474130;;;FR;;;; ALSTA;STAFF & LINE;FR0010246322;;;FR;;;; ALSTW;STREAMWIDE;FR0010528059;;;FR;;;; ALTEV;ENVIRONNEMENT SA;FR0010278762;;;FR;;;; ALTRI;TRILOGIQ;FR0010397901;;;FR;;;; ALTUR;TURENNE INVESTISSEMENT;FR0010395681;;;FR;;;; ALTVO;EVOLIS;FR0004166197;;;FR;;;; ALVDI;VDI GROUP;FR0010337865;;;FR;;;; ALVDM;VOYAGEURS DU MONDE;FR0004045847;;;FR;;;; ALVER;VERGNET;FR0004155240;;;FR;;;; ALADM;ADTHINK MEDIA;FR0010457531;;;FR;;;; MLBRS;BIONERSIS;FR0010294462;;;FR;;;; ALAUP;AUPLATA;FR0010397760;;;FR;;;; MLREF;HOLOSFIND;FR0010446765;;;FR;;;; MLICT;IC TELECOM;FR0010480111;;;FR;;;; ALORO;OROLIA;FR0010501015;;;FR;;;; MLPCT;SOLUTIONS 30;FR0010263335;;;FR;;;; MLWAT;AEROWATT;FR0010396119;;;FR;;;; MLSTR;STREIT INDUSTRIES;FR0000063976;;;FR;;;; MLTTI;TTI;FR0010383877;;;FR;;;; MLCJS;CJS PLV;FR0000074361;;;FR;;;; MLFER;FERCO DEVELOPPEMENT;FR0010071530;;;FR;;;; MLGEO;GEOREX PROV.REGPT;FR0000057945;;;FR;;;; MLION;LIONAX;HK0000038429;;;HK;;;; MLMOR;MORIA NOM.;FR0000074262;;;FR;;;; MLNEO;NEOCOM MULTIMEDIA;FR0004157543;;;FR;;;; MLSBT;SBT;FR0004175222;;;FR;;;; MLACA;ACADOMIA;FR0000075699;;;FR;;;; MLALT;ALTERGAZ;FR0010047928;;;FR;;;; MLBDM;BD MULTI MEDIA;FR0000035305;;;FR;;;; MLERO;EUROLAND FINANCE;FR0010157115;;;FR;;;; MLEUP;EUROPLASMA;FR0000044810;;;FR;;;; MLFST;TECHNOFIRST;FR0010006429;;;FR;;;; MLIMP;IMPRIMERIE CHIRAT;FR0000065773;;;FR;;;; MLNMA;MIGUET ET ASSOCIES;FR0010500363;;;FR;;;; MLOLM;OLMIX;FR0010176115;;;FR;;;; MLQUD;NOVAMEX;FR0004155174;;;FR;;;; MLVEL;VELCAN ENERGY;FR0010245803;;;FR;;;; MLVLT;VOLTALIA;FR0010302224;;;FR;;;; MLZAM;ZAMBIA CONS.CAT.B;ZM0000000037;;;ZM;;;; NRJ;LYXOR NEW ENERGY;FR0010524777;;;FR;;;; WAT;LYXOR WORLD WATER;FR0010527275;;;FR;;;; OTO;OTOR;FR0000064438;PX1;PAR;FR;FRIN;;Oui;Non DIG;DIGIGRAM;FR0000035784;PX1;PAR;FR;FRTEC;FRTHF;Oui;Non PNS;REPONSE;FR0000063869;PX1;PAR;FR;FRIN;FRSS;Oui;Non CLR;CLARINS;FR0000130296;PX1;PAR;FR;FRCG;FRPG;Oui;Oui ROCA;ROCAMAT;FR0000064255;PX1;PAR;FR;FRBM;;Oui;Non GRVO;GRAINES VOLTZ;FR0000065971;PX1;PAR;FR;FRCS;FRGR;Oui;Non BILL;PATRIMOINE ET COMMERCE;FR0000062689;PX1;PAR;FR;FRCG;FRPG;Oui;Non MONC;MONCEY (FIN.) NOM.;FR0000076986;PX1;PAR;FR;FRFIN;;Oui;Non LTI;ALTI;FR0000074296;PX1;PAR;FR;FRTEC;FRSCS;Oui;Non GEO;GEODIS;FR0000038283;PX1;PAR;FR;FRIN;FRINT;Oui;Non ATINV;ACTIA GROUP NV;FR0010664763;PX1;PAR;FR;FRIN;FREEE;Oui;Non CDANV;ALPES (CIE) NV08;FR0010665869;PX1;PAR;FR;FRCS;FRTL;Oui;Non BTPC;B.T.P.(LA CIE);FR0000033607;PX1;PAR;FR;FRFIN;FRGF;Oui;Non BANIP;BANIMMO A (D);BE0003870871;PX1;PAR;BE;FRFIN;;Oui;Non ACBS2;ACANTHEDEVBSAOCT09;FR0000346975;PX1;PAR;FR;FRFIN;;Oui;Non BUD;ANHEUSER BUSCH ORD;US0352291035;PX1;PAR;US;FRCG;FRBEV;Non;Non ASSBR;ASSYSTEM BSAR 0713;FR0010356535;PX1;PAR;FR;FRTEC;FRSCS;Oui;Non BCMA;ATTIJARIWAFA BANK;MA0000011827;PX1;PAR;MA;FRFIN;FRB;Non;Non VIKG;VIKING;FR0004044782;PX1;PAR;FR;FRIN;FRINT;Oui;Non IPBM;IPBM;FR0000050882;PX1;PAR;FR;FRFIN;;Oui;Non DRE;PIER IMPORT EUROPE;FR0000050643;PX1;PAR;FR;FRCG;FRHG;Oui;Non ERMO;ETU.REALI.MOULES (ERMO);FR0000063950;PX1;PAR;FR;FRIN;FRIE;Oui;Non PRDF;PRODEF;FR0000038176;PX1;PAR;FR;FRIN;FRSS;Oui;Non SUPR;SUPRA;FR0000032567;PX1;PAR;FR;FRCG;FRHG;Oui;Non LYSP;SYLIS;FR0000038515;PX1;PAR;FR;FRTEC;FRSCS;Oui;Non FALA;FALA;FR0000064222;PX1;PAR;FR;FRCG;FRFPR;Oui;Non MONTP;MONTEA C.V.A.;BE0003853703;PX1;PAR;BE;FRFIN;;Oui;Non ORBSR;ORCOBSAAR0314;XS0290764728;PX1;PAR;XS;FRFIN;;Oui;Non QUBS1;QUANTEL BS1;FR0010646257;PX1;PAR;FR;FRHC;FRHES;Oui;Non PM;PHILIP MORRIS INTL;US7181721090;PX1;PAR;US;FRCG;;Non;Non PCABS;PROD.CHIM.BS05BSAR;FR0010207811;PX1;PAR;FR;FRBM;;Oui;Non PROL;PROLOGUE;FR0010380626;PX1;PAR;FR;FRTEC;FRSCS;Oui;Non QUABS;QUANTEL BSAR03;FR0010021485;PX1;PAR;FR;FRHC;FRHES;Oui;Non INFE;INDLE FIN.ENTREPRISES;FR0000066219;PX1;PAR;FR;FRIN;FRCM;Oui;Non FCMC;FERMIERE DU CASINO MUN CANNES;FR0000062101;PX1;PAR;FR;FRCS;FRTL;Oui;Non CBE;ROBERTET CI;FR0000045601;PX1;PAR;FR;FRBM;;Oui;Non CHSR;CHAUSSERIA;FR0000060907;PX1;PAR;FR;FRCG;FRPG;Oui;Non JBOG;JACQUES BOGART;FR0000032633;PX1;PAR;FR;FRCG;FRPG;Oui;Non FAUV;FAUVET GIREL;FR0000063034;PX1;PAR;FR;FRFIN;;Oui;Non LEBL;LEBLANC CHROMEX;FR0000065930;PX1;PAR;FR;FRCG;FRHG;Oui;Non FORE;FORESTIERE EQUATORIALE;CI0000053161;PX1;PAR;CI;FRFIN;FRGF;Non;Non ARTO;ARTOIS NOM.;FR0000076952;PX1;PAR;FR;FRFIN;FRGF;Oui;Non HYP;HYPARLO;FR0000061731;PX1;PAR;FR;FRCS;FRFDR;Oui;Non ARB;ARBEL;FR0000035883;PX1;PAR;FR;FRIN;FRIE;Oui;Non BDAL;BRICODEAL;FR0000063919;PX1;PAR;FR;FRIN;FRSS;Oui;Non INNBS;INNELEC BSA;FR0010465492;PX1;PAR;FR;FRTEC;FRSCS;Oui;Non MAIR;HENRI MAIRE;FR0000061087;PX1;PAR;FR;FRCG;FRBEV;Oui;Non CBSBS;SCBSM BS;FR0010622241;PX1;PAR;FR;FRFIN;;Oui;Non DGE;DIAGEO;GB0002374006;PX1;PAR;GB;FRCG;FRBEV;Oui;Non DOWCP;DOW CHEMICAL CO.;US2605431038;PX1;PAR;US;FRBM;;Non;Non DUPP;DU PONT DE NEMOURS;US2635341090;PX1;PAR;US;FRBM;;Non;Non DUC;DUC;FR0000036287;PX1;PAR;FR;FRCG;FRFPR;Oui;Non EPCP;EXPLOS.PROD.CHI.PF;FR0000037343;PX1;PAR;FR;FRBM;;Non;Non TLO;TEAMLOG;FR0000064966;PX1;PAR;FR;FRTEC;FRSCS;Oui;Non CV;ZAMBIA COPPER;BMG988431240;PX1;PAR;BM;FRBM;;Non;Non VRNL;VERNEUIL PARTICIP.;FR0000062465;PX1;PAR;FR;FRFIN;FRGF;Oui;Non GNG;GINGER;FR0000045023;PX1;PAR;FR;FRIN;FRSS;Oui;Non GYO;EVIALIS;FR0000054405;PX1;PAR;FR;FRCG;FRFPR;Oui;Non GNI;CRCAM AQUITAINE;FR0000044547;PX1;PAR;FR;FRFIN;FRB;Oui;Non SOR;SOREFICO COIFFURE;FR0000054272;PX1;PAR;FR;FRCS;FRGR;Oui;Non FTNV9;FRANCE TELECOM NV9;FR0010560771;PX1;PAR;FR;FRTEL;FRFLT;Oui;Non SICA;SICAL;FR0000063653;PX1;PAR;FR;FRIN;;Oui;Non JET;JET MULTIMEDIA;FR0000053456;PX1;PAR;FR;FRTEC;FRSCS;Oui;Non JCQ;JACQUET METALS;FR0000038747;PX1;PAR;FR;FRBM;;Oui;Non BIGBS;BIGBEN BSA;FR0010412189;PX1;PAR;FR;FRCG;FRLEG;Oui;Non GNE;GENERAL ELECTRIC;US3696041033;PX1;PAR;US;FRIN;;Non;Oui KFR;KINGFISHER RGP;GB0033195214;PX1;PAR;GB;FRCS;FRGR;Oui;Non HSB;HSBC HOLDINGS;GB0005405286;PX1;PAR;GB;FRFIN;FRB;Oui;Oui DEXSP;DEXIA STRIP;BE0005587580;PX1;PAR;BE;FRFIN;FRB;Non;Non GECBS;GECI INTER 7.5 BSA 12/08;FR0010491712;PX1;PAR;FR;FRIN;FRAD;Oui;Non GMP;GENERAL MOTORS;US3704421052;PX1;PAR;US;FRCG;FRAP;Non;Non MRK;MERCK AND CO INC;US5893311077;PX1;PAR;US;FRHC;FRPB;Non;Non PCABR;PCASBSAR1212;FR0010480723;PX1;PAR;FR;FRBM;;Oui;Non HG;HARMONY GOLD;ZAE000015228;PX1;PAR;ZA;FRBM;;Non;Oui COLGP;COLGATE PALMOLIVE;US1941621039;PX1;PAR;US;FRCG;FRPG;Non;Non INGP;ING GROEP;NL0000303600;PX1;PAR;NL;FRFIN;;Oui;Non BSTBS;BAC MAJESTIC BSA;FR0010425074;PX1;PAR;FR;FRCS;FRMED;Oui;Non BEFPA;BEFIMMO-SICAFI;BE0003678894;PX1;PAR;BE;FRFIN;;Oui;Non BVDBS;BELVEDBSAR1211;FR0010134247;PX1;PAR;FR;FRCG;FRBEV;Oui;Non PHYBS;ALES GROUPE BS;FR0010057406;PX1;PAR;FR;FRCG;FRPG;Oui;Non BVDBR;BELVEDEREBSAR2014;FR0010304733;PX1;PAR;FR;FRCG;FRBEV;Oui;Non CORI;CORIO NV;NL0000288967;PX1;PAR;NL;FRFIN;;Oui;Non CFOR;COFINIMMO-SICAFI;BE0003593044;PX1;PAR;BE;FRFIN;;Oui;Non SXBRA;CSCOM BS11A;FR0010325019;PX1;PAR;FR;FRTEC;FRSCS;Oui;Non SXBRB;CSCOM BS13B;FR0010325035;PX1;PAR;FR;FRTEC;FRSCS;Oui;Non CYBSA;CYBERGUN BSARA09;FR0010386201;PX1;PAR;FR;FRCG;FRLEG;Oui;Non CYBSB;CYBERGUN BSARB10;FR0010386219;PX1;PAR;FR;FRCG;FRLEG;Oui;Non DANBR;DANEELECBSAR13;FR0010329292;PX1;PAR;FR;FRTEC;FRTHF;Oui;Non DBGA;DERIBSARA10;FR0010062935;PX1;PAR;FR;FRIN;FRSS;Oui;Non DBGB;DERIBSARB10;FR0010062950;PX1;PAR;FR;FRIN;FRSS;Oui;Non DBGC;DERIBSARC10;FR0010062968;PX1;PAR;FR;FRIN;FRSS;Oui;Non DBGBS;DERICHEBOURGBS0317;FR0010198309;PX1;PAR;FR;FRIN;FRSS;Oui;Non YDS;DMC 1% 0816 CV;FR0010356816;PX1;PAR;FR;FRCG;FRPG;Non;Non DGMBB;DMSBSARB2010;FR0010367128;PX1;PAR;FR;FRHC;FRHES;Oui;Non DRN;DURAN;FR0000035503;PX1;PAR;FR;FRCS;FRMED;Oui;Non GIDBS;EGIDE BS 06;FR0010361568;PX1;PAR;FR;FRIN;FREEE;Oui;Non ECMPP;EUROCOMM. PROP CD;NL0000288876;PX1;PAR;NL;FRFIN;;Oui;Non ERFBR;EUROFINS BSAR 13;FR0010292755;PX1;PAR;FR;FRHC;FRPB;Oui;Non ECPBS;EUROPACORP BSAR;FR0010491043;PX1;PAR;FR;FRCS;FRMED;Oui;Non FSPR;FIAT PRIV;IT0001976411;PX1;PAR;IT;FRCG;FRAP;Oui;Non AREBS;GROUPE ARES BS08;FR0010386672;PX1;PAR;FR;FRTEC;FRSCS;Oui;Non ARBSA;GROUPE ARES BSA08;FR0010527903;PX1;PAR;FR;FRTEC;FRSCS;Oui;Non ABCA;ABC ARBITRAGE;FR0004040608;PX1;PAR;FR;FRFIN;FRGF;Oui;Non BCAM;BRASSERIE CAMEROUN;CM0000035113;PX1;PAR;CM;FRCG;FRBEV;Non;Non CIEM;COMPAGNIE MAROCAINE;FR0000030611;PX1;PAR;FR;FRFIN;;Oui;Non CLAY;CLAYEUX;FR0000060824;PX1;PAR;FR;FRCS;FRGR;Oui;Non EXAC;EXACOMPTA CLAIREFONTAINE;FR0000064164;PX1;PAR;FR;FRBM;;Oui;Non GVLT;GEVELOT;FR0000033888;PX1;PAR;FR;FRCG;FRAP;Oui;Non MALT;MALTERIES FRANCO-BELGES;FR0000030074;PX1;PAR;FR;FRCG;FRBEV;Oui;Non OSIBS;AUSYBS2010;FR0010505941;PX1;PAR;FR;FRTEC;FRSCS;Oui;Non POUJ;POUJOULAT(ETS);FR0000066441;PX1;PAR;FR;FRIN;FRCM;Oui;Non SEC;SODITECH ING.;FR0000078321;PX1;PAR;FR;FRIN;FRSS;Oui;Non THAR;THARREAU IND.;FR0000062739;PX1;PAR;FR;FRCG;FRPG;Oui;Non TNFN;TECHNOFAN;FR0000065450;PX1;PAR;FR;FRIN;FRAD;Oui;Non VERM;VERMANDOISE SUCR.;FR0000037749;PX1;PAR;FR;FRCG;FRFPR;True;Non |
|
From: Erik C. <ec...@ec...> - 2011-02-23 10:46:00
|
Please note that I have released Finance::QuoteDB 0.15 to CPAN. Finance::QuoteDB is meant as a fullblown database application for maintaining stock data. It allows anyone to easily create and update a stock database. The information is gathered by using Finance::Quote and the database is created and maintained by use of DBIx::Class. The config-file for GeniusTrader use is generated automatically. Interface to R is planned to be integrated. -- erik colson ecocode.net |
|
From: Eric L. <eri...@gm...> - 2011-02-23 07:00:44
|
Eric Lemesre wrote:
2011/2/15 Robert A. Schmied <ra...@ac...>
Don't be affraid about that ...
I want to use some features with GT.
I want to make a signal with Major Indice, Sectorial indice for
equities.
Exemple :
Symbol = AC
Code ISIN = FR0000120404
Long name = ACCOR
Market code = PAR
Code ICB1,ICB2,ICB3, ICB4 = 5000, 5700, 5750, 5753
symbol in french market ICB1, ICB3 = FRCS, FRTL
Code ISIN for indice ICB1 ICB3 = QS0011017736,
QS0011017884
i'm not sure i understand completely ICB2 and ICB4 ( 5700, 5753 )
but QS0011017736 and QS0011017884 look ok: both are french? (CAC) indexes?
This link will speak better than me of classification.
http://www.icbenchmark.com/icb_structure.html
oh -- the light on this side of the world is slowing getting brighter ...
isn't this dow jones indexes and the ftse stuff proprietary,
meaning has a cost of use associated with it? i wasn't able to find
a way to download anything but the sample file ...
For French Market all sectotrial indice is totaly free. And Classicfication
information is available
from Euronext for free too.
including in GT (or an ancillary database) the methods needed to fetch/store
this info sounds neat but because it isn't freely available the adoption
rate may be rather low. on the plus side the format is very easy to use ...
I attach a file with all classification table. But it is not the good way to
use it in GT.
All security must have Industry, SuperSector, Sector, SubSector. And it is
an Additional information,
like an other one (count of Share, dividend, Long Name, Short name, ISIN
...).
I Perpose to code it with this format (or some thioink like that):
CREATE TABLE share_info
(
info character varying(25) NOT NULL DEFAULT ''::character varying,
share_id character varying(15) NOT NULL DEFAULT ''::character varying,
symbol character varying(15) NOT NULL DEFAULT ''::character varying,
value_type character varying(15) NOT NULL DEFAULT ''::character varying,
-- must be STRING, INTEGER, BOOLEAN, DATE, NUMERIC
str_value character varying,
dt_start_valide date NOT NULL DEFAULT '0001-01-01'::date,
dt_end_valide date NOT NULL DEFAULT '9999-12-31'::date,
CONSTRAINT security_info_pkey PRIMARY KEY (info, share_id, symbol,
value_type, dt_start_valide)
)
Or an other table. It doesn't matter.
We can put in for AC by exemple
info;ISIN;Symbol;Type;Value;dt_start_valide;dt_end_valide
cd_icb1;FR0000120404;AC;STRING;5000;0001-01-01;9999-12-31
cd_icb2;FR0000120404;AC;STRING;5700;0001-01-01;9999-12-31
cd_icb3;FR0000120404;AC;STRING;5750;0001-01-01;9999-12-31
cd_icb4;FR0000120404;AC;STRING;5753;0001-01-01;9999-12-31
zone_geo;FR0000120404;AC;STRING;Zone France ;0001-01-01;9999-12-31
compartiment;FR0000120404;AC;STRING;Compartiment A (Blue
Chips);0001-01-01;9999-12-31
name;FR0000120404;AC;STRING;ACCOR;0001-01-01;9999-12-31
type;FR0000120404;AC;STRING;ACTION;0001-01-01;9999-12-31
code_indice_icb1;FR0000120404;AC;STRING;FRCS;0001-01-01;9999-12-31
id_indice_icb1;FR0000120404;AC;STRING;QS0011017736;0001-01-01;9999-12-31
code_indice_icb3;FR0000120404;AC;STRING;FRTL;0001-01-01;9999-12-31
id_indice_icb3;FR0000120404;AC;STRING;QS0011017884;0001-01-01;9999-12-31
code_indice_market;FR0000120404;AC;STRING;PX1;0001-01-01;9999-12-31
is_pea;FR0000120404;AC;BOOLEAN;True;0001-01-01;9999-12-31
is_srd;FR0000120404;AC;BOOLEAN;True;0001-01-01;9999-12-31
code_market;FR0000120404;AC;STRING;PAR;0001-01-01;9999-12-31
the code in GT::DB::genericdbi to get it :
# Management of additional Informations
# #####################################
=item C<< $db->get_add_info($code,$info[,$date]) >>
Returns an additional information about the share
=cut
sub get_add_info {
my ($self, $code, $info, $date) = @_;
my $sql = GT::Conf::get("DB::genericdbi::addinfo_sql")
|| die("Invalid configuration. You must specify a valid addinfo_sql"
." sql statment for your database in the options file");
my $date_clause =
GT::Conf::get("DB::genericdbi::addinfo_sql::date_clause");
$sql =~ s/\$code/$code/g;
$sql =~ s/\$info/$info/g;
if (defined($date) && defined($date_clause)) {
$date_clause =~ s/\$date/$date/g;
$sql .= " AND ".$date_clause;
};
my $sth = $self->{'_dbh'}->prepare($sql) || die $self->{'_dbh'}->errstr;
$sth->execute() || die $self->{'_dbh'}->errstr;
my $res = $sth->fetchrow_arrayref;
return $res->[0];
}
=item C<< $db->get_all_add_info($code,[,$date]) >>
Returns all additional information about the share
in hash table
=cut
sub get_all_add_info {
my ($self, $code, $date) = @_;
my $sql = GT::Conf::get("DB::genericdbi::all_addinfo_sql")
|| die("Invalid configuration. You must specify a valid
all_addinfo_sql"
." sql statment for your database in the options file");
my $date_clause =
GT::Conf::get("DB::genericdbi::all_addinfo_sql::date_clause");
$sql =~ s/\$code/$code/g;
if (defined($date) && defined($date_clause)) {
$date_clause =~ s/\$date/$date/g;
$sql .= " AND ".$date_clause;
};
my $sth = $self->{'_dbh'}->prepare($sql) || die $self->{'_dbh'}->errstr;
$sth->execute() || die $self->{'_dbh'}->errstr;
# build Hash like this $res{'addinfo' => Value }
%res = {};
while (my ($info_ame, $info_value, $info_type) =
$sth->fetchrow_arrayref) {
$res{ $info_name => $info_value };
}
return \%res;
}
<large snip>
Yes I know that but i want to provide a way find for AC the code FRCS
this 'code' string translation is outside the scope of what GT can (or
maybe what GT should) do, but it falls within the scope of the stock prices
database. i suppose it could be an extension of the flat file database
GT provides -- refer to the way GT/DB/Text.pm and GT/DB.pm is able to map
a 'code' to a company name.
I agree with you
well, it cannot be done with stock beancounter, but you could adopt the
FRCS.PA or the isin code instead of using the actual stock 'ticker' symbol
with beancounter and i think things would then just work.
with a new development stock prices database (or a modified beancounter)
you could have one or more tables that provide the correspondence (the
mapping)
from a stock 'ticker' symbol to either the FRCS.PA reference or the isin
code.
I have not yet learning Beancounter
a simple (relatively) join query would be used to perform the mapping.
Exemple:
{I::Prices FRCS} with this form
{I::Prices {ShareInfo::Equities ICB1} } and the walue for
{ShareInfo::Equities ICB1} is FRCS for AC
but an other symbol for an other security.
I use gconf file to build graphic (see attch file) but i want to use the
same file for all equities.
with some think like that :
--add=Curve(I:EMA 30 { I:Prices CLOSE {ShareInfo::Equities ICB1} },
darkblue )
when i use
./Scripts/graphic.pl --file=./conf/graph_valeur.conf
--out=./Report/%c.png
AC
{ShareInfo::Equities ICB1} = FRCS
and with VIE (VEOLIA ENVIRONNEMENT;FR0000124141)
{ShareInfo::Equities ICB1} = FRUT
Indice ICB1 for Veolia in french market
ShareInfo or Share::Equities is a new module like Indicator than i try
to
write for provide a global substitution
variable with equities relation.
i'm still not sure i understand -- maybe a couple of examples
will help clarify ---
please provide the answers ...
q for a 'code' value of ALU what does
{ShareInfo::Equities ICB1} yield?
q for a 'code' value of ALU.PA what does
{ShareInfo::Equities ICB1} yield?
It doesn't matter I think if user want to use it code addinfo in database or
flat file as he want to use.
if they are different then it has to be something resident in ICB1
(whatever that is) that is yielding this difference. i guess i'm
asking what the significance of ICB1 is and if you envision there
could be other codes such as ICB2, etc. if this is true why not
give them names that denote their value attribute such as
'Sector', 'Industry', etc.
I am not matter about code. The best mane must be find and fixed for a long
time.
And the name of extended info could be substitute by option file mechanisme.
ShareInfo or Share::Equities is a new module like Indicator than i try
to
well, that's not how GT sys-sig-indic descriptions are defined and
implemented, but now i understand what you are trying to do. so i'm
gonna start thinking out loud -- it could be a bit messy, confusing
and rambling ...
for the most part GTs object orientation is 'data objects'. Indicators
such as I:EMA 10 already know about (or has implicit access to)
the price data via the 'calculator' object, which is the basis for
all GT sys-sig-indic processing.
so to retain similarity with the rest of GT you might want
to create a secondary 'code' based data object that operates
on 'icb' data or as i describe later maybe a modified or cloned
'calculator' that has the additional icb data.
depending on the complexity [of the icb data store] this might be as
simple as the loadtxt method in GT::Prices, it is also likely to
require additional functionality supplied by a new GT::DB::ICB module.
Exemple:
{I::Prices FRCS} with this form
{I::Prices {ShareInfo::Equities ICB1} } and the walue for
{ShareInfo::Equities ICB1} is FRCS for AC
but an other symbol for an other security.
if the above is the extent of the function that {ShareInfo::Equities ICB1}
has then about the only 'method' you need is
$icb_class = code_icb( $code );
it might return an array (or a hash) with the following elements:
industry, supersector, sector, subsector, definition
or you could define method code_icb_class, define a default classification
(say 'industry') and thereby define a method like
$icb_class = code_icb_class( $code, $classification );
where $classification could be enumerated values (like the prices
value elements) or strings that match well know regex values ...
in either case the data object $icb_class is now 'available' to any
other GT method that 'knows about it'. this 'knows about it' problem
is where most of the changes to the rest of gt occurs. i think that
should be minimized to the greatest extent practical ...
refer to my hack of GT (in the attached tarballs mentioned below).
specifically these modules to see what i've done to add simple data values
(company fundamentals) to GT via GT::DB and GT::DB::bean. note that
without my beancounter hack these data will not be available for use,
but you can see the approach i've used to implement them in GT.
these data use can be found in ../GT/Indicators/FloatQTY.pm and
../GT/Graphics/DataSource/Splits.pm ...
The hash of all extended values could be retrive by DB module. In fact Icb
classification is juste
an extended info among other.
note: i'm not entirely satisfied with this overall approach (but don't
know why (other than it's an initial version so it just cannot be the
best solution)) so if your experience suggests an alternate scheme feel
free to suggest it.
but my thinking is generally:
i) minimize changes from rippling through the bulk of the GT code base.
ii) as bad (or good) as the base gt design is retain that methodology.
OK. Adding modules like ShareInfo, ShareInfo::Equities, ShareInfo::Bonds ...
satisfi it?
iii) individual indicators (or signals or systems or anything else)
shouldn't have unique ability to access additional data; instead
the additional data should be made available in a general way so
any object that wants to use it can without having to know anything
about how to access it.
iv) if the cbi data isn't freely available, i hope you can make
these enhancements completely optional.
in french market this info is freely available in euronext.com. for Lisbon,
Amsterdam and paris exchange.
if you want to have an 'indicator' that given 'AC' returns 'FRCS' based
on the icb data, then the module should have the package name
'GT::Indicator::<something>'
<something> shouldn't contain ':' or '::' as that will denote another
level of name-space hierarchy (unless that is what you want).
more importantly, the module must be a GT::Indicators
@ISA = qw(GT::Indicators);
see ../GT/Indicators/FloatQTY.pm to see how i hacked in accessing the
number of floating shares reported by yahoo ...
this approach is *not* the way to go in my opinion -- it requires too
much special capability in the indicator itself -- this specialization
should somehow be generalized so the data is available to any indicator
that wants it.
I think extended information is not like indicator. Indicator move along the
time, for every perriode.
Extended info don't change every perriode (DAY, WWEEK). they change but
slowly.
there are three major issues that you need to solve, hopefully staying
consistent (to extent possible) with prior gt design and implementation
concepts:
1) implement new (or modified) database interface access and if
necessary with appropriate database management methods.
2) create (or modify) a data object with methods that contain/use
this new data appropriate
3) create (or modify) applications or application components in
order to make use of this new data
GT is probably too tightly integrated in some respects but once this
intercoupling is understood, given enough time and effort GT can be
extended without creating too much of a monster.
ok -- i'm starting to lose sight of the forest for the trees (this is
very typical when analyzing how GT operates and how to best implement
and extension) so i'm going to re-focus and re-state the problem:
"i want to provide a way find for AC the code FRCS"
taken literally you suggest that a 'code' object can determine the
cbi classification it has.
YES it is.
this suggests that the cbi change is really
an extension of the functionality in module GT::Calculator.
note that a 'calculator' object in GT has the code string, all
the price data and data time-frame, plus any indicators and signals.
extending a 'calculator' object to include the additional data
that the icb classification provides would allow any other object
to make use of that data on request.
the version of GT::Calculator that's in the tarballs includes an
extension for just such additional information. as i recall it's been
removed from the trunk head version for some reason -- it may have
been the dependency on XML::LibXML or something else -- an archive
search may explain the reasoning ...
the modules involved include: GT/Calculator.pm, GT/MetaInfo.pm and
perl prerequisite XML::LibXML.
note: i'm not advocating using xml encoding for the cbi database,
just pointing out what hooks are available for exploitation either
directly or by extending them for the sector classification problem.
CacheValues store information along the time (1 day One information)
but metainformation need 1 information available between date.
We can modify ChacheValues to provide this mechanisme or change MetaInfo to
remove libXml dependency.
We can use modified code of CacheValues in place of MetaInfo
another approach might be creating a classification data object
with methods in GT::Tools, but that isn't the way i'd go ...
I prefer a general mechanisme for extended information in place of
specifique mechanisme for classification.
because we want probebly make trading system this PER information or an
other extended info.
as it stands right now, i'm liking best the extension of the
'calculator' object to include all the sector classification data
as well as all the hackish stuff i've been monkeying with ...
(refer to tarball version of ../GT/DB.pm and ../GT/DB/bean.pm and
the way i make the extended data available via GT::Eval::get_ext_value.
see example indicators ../GT/Indicators/EVWMA.pm and
../GT/Indicators/FloatQTY.pm)
maybe there is a way to 'extend' a 'calculator' object without a lot
of change to GT/Calculator.pm and without requiring an indicator (or
any other object have to 'get' the data from a database. from an
sys-sig-indic object perspective the data should either be available
via the calculator methods like:
my $prices = $calc->prices;
my $classifications = $calc->cbi_classification;
Yes but with this form
my $extended_info = $calc->extended_info;
possibly by altering the GT::Calculator::new method self hash:
to
my $self = {
'code' => $code,
'tf' => {},
@_, # override or extend attributes
};
from
my $self = { 'code' => $code, 'tf' => {} };
crap -- unfortunately GT::Calculator::new is only called by method
GT::Tools::get_timeframe_data (via GT::Tools::find_calculator (or
in my version calculator) and it isn't suited to passing additional
extended attributes so this isn't gonna be the best solution -- the
change ripples everywhere ... that's probably why my data extension
hacks are so convoluted ...
Wath is the best solution to handle extended inforation?
ShareInfo to provide name substitution in trading system.
DB module extention to retrive information in database with with option file
personalisation
Modified calculator to calculate and provide it to all script
What think about that?
still i like having the additional data in the 'calculator' object,
if normally empty slots are created and then filled with new methods
added to GT::Calculator that's fine:
add typically empty slots to 'calculator' object
my $self = {
'code' => $code,
'tf' => {},
'classifications' => { industry => undef,
supersector => undef,
sector => undef,
subsector => undef,
definition => undef, # is this the company
description?
},
# other additional data
@_, # override or extend attributes
};
add new GT::Calculator methods to set the 'classifications' slots:
#---# this really isn't well thought out ... how to pass hash as arg ...
sub classifications {
my ($self, @classification) = @_;
while ( @classification } {
unless( $#classification >= 1 } {
my $msg = "invalid cbi classification data \"$_[0]\"";
warn $msg;
return undef;
}
unless ( m/industry|sector|definition/i ) {
my $msg = "bad cbi classification index \"$_[0] => $_[1]\"";
warn $msg;
shift;
next;
}
my $key = $_[0];
my $value = $_[1];
$self->{'classifications'}->{$key} = $value;
shift;
}
return $self->{'classifications'};
}
or a clone of a 'calculator' object could be created and its
initializer could then add the new attributes ...
(ref programming perl, wall, pg 320)
in what chapter? i have only french book and english html in oreily site web
anyway i think this *is* the way to approach the problem
(and i may being to explore it for the fundamental data defined
in my hacks of DB.pm, bean.pg, and Eval.pm)
however with respect to the cbi classification data the outstanding
questions that remain are still:
"what is the cost aspect of the cbi data"
"does it's 'terms of use' clause allow its use in an open-source project"
< snip >
NB: this exercise points out one major weakness of graphic.pl and the
use of gconf file(s) to define the chart content. many times you want
to 'vary' certain parameters based on some external condition, in this
instance the index code being used should probably be the one that the
chart code is in (or somehow associated with), without having to edit
the gconf over and over again to effect the change (or have many gconf
files all very similar ...
my solution to this (and other problems with graphic.pl) is chart.pl.
it has provisions to support user defined variables that get substitute
throughout the gconf file. it's available only when used with most of my
other changes in the ras hack tarball set ... but last time i checked
it doesn't yet have 'user defined variables' and there isn't any logic
mechanism that would allow a case like switch to set a user variable based
on the 'code' industry or sector membership. of course, as it now stands
beancounter doesn't have tuples for 'code' industry or sector.
Where can i read this miracle solution ;-)
i'll send you my 3 tarball set directly, but it really doesn't solve
any of these issues ... in fact it will probably just confuse things
more ...
They don't confuse. Thanks
I use this links to get historic prices and day prices for indice and
security:
http://www.boursorama.com/outils/telechargement/telechargement.phtml
looks to me like an account is needed to access the actual data?
Yes but a free account
But getting price by script with this link is very hard. Some javascript
code are send, executing in browser
to post a session code. it is probebly posible with *WWW::Mechanize
greetings
Eric Lemesre
de mon Nexus One
|
|
From: Robert A. S. <ra...@ac...> - 2011-02-17 17:51:45
|
Eric Lemesre wrote: > 2011/2/15 Robert A. Schmied <ra...@ac...> > >>Eric Lemesre wrote: >> >> >>>2011/2/3 Robert A. Schmied <ra...@ac...> >>> >>>>Eric Lemesre wrote: >>>> >>>> >>>>>Eric Lemesre >>>>> >>>>> >>>>>>ras wrote >>>>>> >>>>> >>< large snip > >> >> >>>Don't be affraid about that ... >>>I want to use some features with GT. >>>I want to make a signal with Major Indice, Sectorial indice for equities. >>> >>>Exemple : >>>Symbol = AC >>>Code ISIN = FR0000120404 >>>Long name = ACCOR >>>Market code = PAR >>>Code ICB1,ICB2,ICB3, ICB4 = 5000, 5700, 5750, 5753 >>>symbol in french market ICB1, ICB3 = FRCS, FRTL >>>Code ISIN for indice ICB1 ICB3 = QS0011017736, >>>QS0011017884 >>> >>> >> >>i'm not sure i understand completely ICB2 and ICB4 ( 5700, 5753 ) >>but QS0011017736 and QS0011017884 look ok: both are french? (CAC) indexes? >> > > > This link will speak better than me of classification. > http://www.icbenchmark.com/icb_structure.html oh -- the light on this side of the world is slowing getting brighter ... isn't this dow jones indexes and the ftse stuff proprietary, meaning has a cost of use associated with it? i wasn't able to find a way to download anything but the sample file ... including in GT (or an ancillary database) the methods needed to fetch/store this info sounds neat but because it isn't freely available the adoption rate may be rather low. on the plus side the format is very easy to use ... however, and i don't know how well it corresponds with the icb classifications yahoo provides something similar and it is freely available http://biz.yahoo.com/ic/ind_index.html but the format isn't easy to use, and will likely have to be web scraped, since there isn't a way i've found to download it in data form ... > I thought that this classification wase French's market specific. But in > courtyard of my searches on the Web I saw that actions americaines had this > classification too. > And 5700 Travel & Leisure (ICB1), 5750 Travel & Leisure (ICB2), 5753 Hotels > (ICB3) > > Have french index for this sector of French market but probebly US index > too. > > > >> $ yahooquote QS0011017884 >> FRTL.NX CAC TRAVEL & LEIS 1102.46 2/14/2011 ENX $ >> yahooquote QS0011017736 >> FRCS.NX CAC CONSUMER SERV 939.81 2/14/2011 ENX >>using the listed isin codes these seem to be from the euronext market >>place? >> >>it doesn't appear they trade on the paris market-site or yahoo just doesn't >>list them, or uses a different code >> >> $ yahooquote FRCS.PA FRTL.PA >> FRCS.PA FRCS.PA 0.00 N/A N/A FRTL.PA FRTL.PA 0.00 N/A >> N/A >> >> >> I Want to add some curve with this syntax for a given code : >> >>>--add="Curve(I::EMA 30 ShareInfo::INDICE_ICB1)" >>>ShareInfo::INDICE_ICB1 return FRCS or QS0011017736 for code AC >>> >>> well i don't understand the 'ShareInfo::INDICE_ICB1', but the prices >> >>indicator (I:Prices) (module GT/Indicator/Prices.pm) already supports a >>second code argument just for this purpose. see the pod for this module >>for more details on its use. word of warning: when you use the second code >>argument *do not forget* to include the prices array index value >> (HIGH, LOW, OPEN, CLOSE, VOLUME or DATE) >>otherwise the plot will not be what is wanted and there is no warning or >>notice that something is amiss >> { I:Prices ^NDX } >>should use CLOSE, the default, and the ^NDX code, but it does not, >>instead it ignores the special code and uses CLOSE of the default 'code'). >> > > > Yes I know that but i want to provide a way find for AC the code FRCS this 'code' string translation is outside the scope of what GT can (or maybe what GT should) do, but it falls within the scope of the stock prices database. i suppose it could be an extension of the flat file database GT provides -- refer to the way GT/DB/Text.pm and GT/DB.pm is able to map a 'code' to a company name. well, it cannot be done with stock beancounter, but you could adopt the FRCS.PA or the isin code instead of using the actual stock 'ticker' symbol with beancounter and i think things would then just work. with a new development stock prices database (or a modified beancounter) you could have one or more tables that provide the correspondence (the mapping) from a stock 'ticker' symbol to either the FRCS.PA reference or the isin code. a simple (relatively) join query would be used to perform the mapping. > Exemple: > {I::Prices FRCS} with this form > {I::Prices {ShareInfo::Equities ICB1} } and the walue for > {ShareInfo::Equities ICB1} is FRCS for AC > but an other symbol for an other security. > > I use gconf file to build graphic (see attch file) but i want to use the > same file for all equities. > with some think like that : > > --add=Curve(I:EMA 30 { I:Prices CLOSE {ShareInfo::Equities ICB1} }, darkblue ) > > when i use > ./Scripts/graphic.pl --file=./conf/graph_valeur.conf --out=./Report/%c.png > AC > > {ShareInfo::Equities ICB1} = FRCS > > and with VIE (VEOLIA ENVIRONNEMENT;FR0000124141) > > {ShareInfo::Equities ICB1} = FRUT > > Indice ICB1 for Veolia in french market > > ShareInfo or Share::Equities is a new module like Indicator than i try to > write for provide a global substitution > variable with equities relation. i'm still not sure i understand -- maybe a couple of examples will help clarify --- please provide the answers ... q for a 'code' value of ALU what does {ShareInfo::Equities ICB1} yield? q for a 'code' value of ALU.PA what does {ShareInfo::Equities ICB1} yield? if they are different then it has to be something resident in ICB1 (whatever that is) that is yielding this difference. i guess i'm asking what the significance of ICB1 is and if you envision there could be other codes such as ICB2, etc. if this is true why not give them names that denote their value attribute such as 'Sector', 'Industry', etc. > ShareInfo or Share::Equities is a new module like Indicator than i try to well, that's not how GT sys-sig-indic descriptions are defined and implemented, but now i understand what you are trying to do. so i'm gonna start thinking out loud -- it could be a bit messy, confusing and rambling ... for the most part GTs object orientation is 'data objects'. Indicators such as I:EMA 10 already know about (or has implicit access to) the price data via the 'calculator' object, which is the basis for all GT sys-sig-indic processing. so to retain similarity with the rest of GT you might want to create a secondary 'code' based data object that operates on 'icb' data or as i describe later maybe a modified or cloned 'calculator' that has the additional icb data. depending on the complexity [of the icb data store] this might be as simple as the loadtxt method in GT::Prices, it is also likely to require additional functionality supplied by a new GT::DB::ICB module. > Exemple: > {I::Prices FRCS} with this form > {I::Prices {ShareInfo::Equities ICB1} } and the walue for > {ShareInfo::Equities ICB1} is FRCS for AC > but an other symbol for an other security. if the above is the extent of the function that {ShareInfo::Equities ICB1} has then about the only 'method' you need is $icb_class = code_icb( $code ); it might return an array (or a hash) with the following elements: industry, supersector, sector, subsector, definition or you could define method code_icb_class, define a default classification (say 'industry') and thereby define a method like $icb_class = code_icb_class( $code, $classification ); where $classification could be enumerated values (like the prices value elements) or strings that match well know regex values ... in either case the data object $icb_class is now 'available' to any other GT method that 'knows about it'. this 'knows about it' problem is where most of the changes to the rest of gt occurs. i think that should be minimized to the greatest extent practical ... refer to my hack of GT (in the attached tarballs mentioned below). specifically these modules to see what i've done to add simple data values (company fundamentals) to GT via GT::DB and GT::DB::bean. note that without my beancounter hack these data will not be available for use, but you can see the approach i've used to implement them in GT. these data use can be found in ../GT/Indicators/FloatQTY.pm and ../GT/Graphics/DataSource/Splits.pm ... note: i'm not entirely satisfied with this overall approach (but don't know why (other than it's an initial version so it just cannot be the best solution)) so if your experience suggests an alternate scheme feel free to suggest it. but my thinking is generally: i) minimize changes from rippling through the bulk of the GT code base. ii) as bad (or good) as the base gt design is retain that methodology. iii) individual indicators (or signals or systems or anything else) shouldn't have unique ability to access additional data; instead the additional data should be made available in a general way so any object that wants to use it can without having to know anything about how to access it. iv) if the cbi data isn't freely available, i hope you can make these enhancements completely optional. if you want to have an 'indicator' that given 'AC' returns 'FRCS' based on the icb data, then the module should have the package name 'GT::Indicator::<something>' <something> shouldn't contain ':' or '::' as that will denote another level of name-space hierarchy (unless that is what you want). more importantly, the module must be a GT::Indicators @ISA = qw(GT::Indicators); see ../GT/Indicators/FloatQTY.pm to see how i hacked in accessing the number of floating shares reported by yahoo ... this approach is *not* the way to go in my opinion -- it requires too much special capability in the indicator itself -- this specialization should somehow be generalized so the data is available to any indicator that wants it. there are three major issues that you need to solve, hopefully staying consistent (to extent possible) with prior gt design and implementation concepts: 1) implement new (or modified) database interface access and if necessary with appropriate database management methods. 2) create (or modify) a data object with methods that contain/use this new data appropriate 3) create (or modify) applications or application components in order to make use of this new data GT is probably too tightly integrated in some respects but once this intercoupling is understood, given enough time and effort GT can be extended without creating too much of a monster. ok -- i'm starting to lose sight of the forest for the trees (this is very typical when analyzing how GT operates and how to best implement and extension) so i'm going to re-focus and re-state the problem: "i want to provide a way find for AC the code FRCS" taken literally you suggest that a 'code' object can determine the cbi classification it has. this suggests that the cbi change is really an extension of the functionality in module GT::Calculator. note that a 'calculator' object in GT has the code string, all the price data and data time-frame, plus any indicators and signals. extending a 'calculator' object to include the additional data that the icb classification provides would allow any other object to make use of that data on request. the version of GT::Calculator that's in the tarballs includes an extension for just such additional information. as i recall it's been removed from the trunk head version for some reason -- it may have been the dependency on XML::LibXML or something else -- an archive search may explain the reasoning ... the modules involved include: GT/Calculator.pm, GT/MetaInfo.pm and perl prerequisite XML::LibXML. note: i'm not advocating using xml encoding for the cbi database, just pointing out what hooks are available for exploitation either directly or by extending them for the sector classification problem. another approach might be creating a classification data object with methods in GT::Tools, but that isn't the way i'd go ... as it stands right now, i'm liking best the extension of the 'calculator' object to include all the sector classification data as well as all the hackish stuff i've been monkeying with ... (refer to tarball version of ../GT/DB.pm and ../GT/DB/bean.pm and the way i make the extended data available via GT::Eval::get_ext_value. see example indicators ../GT/Indicators/EVWMA.pm and ../GT/Indicators/FloatQTY.pm) maybe there is a way to 'extend' a 'calculator' object without a lot of change to GT/Calculator.pm and without requiring an indicator (or any other object have to 'get' the data from a database. from an sys-sig-indic object perspective the data should either be available via the calculator methods like: my $prices = $calc->prices; my $classifications = $calc->cbi_classification; possibly by altering the GT::Calculator::new method self hash: to my $self = { 'code' => $code, 'tf' => {}, @_, # override or extend attributes }; from my $self = { 'code' => $code, 'tf' => {} }; crap -- unfortunately GT::Calculator::new is only called by method GT::Tools::get_timeframe_data (via GT::Tools::find_calculator (or in my version calculator) and it isn't suited to passing additional extended attributes so this isn't gonna be the best solution -- the change ripples everywhere ... that's probably why my data extension hacks are so convoluted ... still i like having the additional data in the 'calculator' object, if normally empty slots are created and then filled with new methods added to GT::Calculator that's fine: add typically empty slots to 'calculator' object my $self = { 'code' => $code, 'tf' => {}, 'classifications' => { industry => undef, supersector => undef, sector => undef, subsector => undef, definition => undef, # is this the company description? }, # other additional data @_, # override or extend attributes }; add new GT::Calculator methods to set the 'classifications' slots: #---# this really isn't well thought out ... how to pass hash as arg ... sub classifications { my ($self, @classification) = @_; while ( @classification } { unless( $#classification >= 1 } { my $msg = "invalid cbi classification data \"$_[0]\""; warn $msg; return undef; } unless ( m/industry|sector|definition/i ) { my $msg = "bad cbi classification index \"$_[0] => $_[1]\""; warn $msg; shift; next; } my $key = $_[0]; my $value = $_[1]; $self->{'classifications'}->{$key} = $value; shift; } return $self->{'classifications'}; } or a clone of a 'calculator' object could be created and its initializer could then add the new attributes ... (ref programming perl, wall, pg 320) anyway i think this *is* the way to approach the problem (and i may being to explore it for the fundamental data defined in my hacks of DB.pm, bean.pg, and Eval.pm) however with respect to the cbi classification data the outstanding questions that remain are still: "what is the cost aspect of the cbi data" "does it's 'terms of use' clause allow its use in an open-source project" < snip > >>NB: this exercise points out one major weakness of graphic.pl and the >>use of gconf file(s) to define the chart content. many times you want >>to 'vary' certain parameters based on some external condition, in this >>instance the index code being used should probably be the one that the >>chart code is in (or somehow associated with), without having to edit >>the gconf over and over again to effect the change (or have many gconf >>files all very similar ... >> >>my solution to this (and other problems with graphic.pl) is chart.pl. >>it has provisions to support user defined variables that get substitute >>throughout the gconf file. it's available only when used with most of my >>other changes in the ras hack tarball set ... but last time i checked >>it doesn't yet have 'user defined variables' and there isn't any logic >>mechanism that would allow a case like switch to set a user variable based >>on the 'code' industry or sector membership. of course, as it now stands >>beancounter doesn't have tuples for 'code' industry or sector. >> >> > > Where can i read this miracle solution ;-) i'll send you my 3 tarball set directly, but it really doesn't solve any of these issues ... in fact it will probably just confuse things more ... <snip> > > > I use this links to get historic prices and day prices for indice and > security: > http://www.boursorama.com/outils/telechargement/telechargement.phtml looks to me like an account is needed to access the actual data? > > But getting price by script with this link is very hard. Some javascript > code are send, executing in browser > to post a session code. it is probebly posible with *WWW::Mechanize < snip > aloha ras |
|
From: Robert A. S. <ra...@ac...> - 2011-02-15 19:34:13
|
Eric Lemesre wrote:
> 2011/2/3 Robert A. Schmied <ra...@ac...>
>>Eric Lemesre wrote:
>>>Eric Lemesre
>>>>ras wrote
< large snip >
>
> Don't be affraid about that ...
> I want to use some features with GT.
> I want to make a signal with Major Indice, Sectorial indice for equities.
>
> Exemple :
> Symbol = AC
> Code ISIN = FR0000120404
> Long name = ACCOR
> Market code = PAR
> Code ICB1,ICB2,ICB3, ICB4 = 5000, 5700, 5750, 5753
> symbol in french market ICB1, ICB3 = FRCS, FRTL
> Code ISIN for indice ICB1 ICB3 = QS0011017736, QS0011017884
>
i'm not sure i understand completely ICB2 and ICB4 ( 5700, 5753 )
but QS0011017736 and QS0011017884 look ok: both are french? (CAC) indexes?
$ yahooquote QS0011017884
FRTL.NX CAC TRAVEL & LEIS 1102.46 2/14/2011 ENX
$ yahooquote QS0011017736
FRCS.NX CAC CONSUMER SERV 939.81 2/14/2011 ENX
using the listed isin codes these seem to be from the euronext market place?
it doesn't appear they trade on the paris market-site or yahoo just doesn't
list them, or uses a different code
$ yahooquote FRCS.PA FRTL.PA
FRCS.PA FRCS.PA 0.00 N/A N/A
FRTL.PA FRTL.PA 0.00 N/A N/A
> I Want to add some curve with this syntax for a given code :
> --add="Curve(I::EMA 30 ShareInfo::INDICE_ICB1)"
> ShareInfo::INDICE_ICB1 return FRCS or QS0011017736 for code AC
>
well i don't understand the 'ShareInfo::INDICE_ICB1', but the prices
indicator (I:Prices) (module GT/Indicator/Prices.pm) already supports a
second code argument just for this purpose. see the pod for this module
for more details on its use. word of warning: when you use the second code
argument *do not forget* to include the prices array index value
(HIGH, LOW, OPEN, CLOSE, VOLUME or DATE)
otherwise the plot will not be what is wanted and there is no warning or
notice that something is amiss
{ I:Prices ^NDX }
should use CLOSE, the default, and the ^NDX code, but it does not,
instead it ignores the special code and uses CLOSE of the default 'code').
my presumptions -- always a bad thing -- presuming but it's gotta be done:
i) plotting a prices chart using graphic.pl ACCOR (FR0000120404)
ii) add a 30 day ema curve of some other price data (could be an index
like QS0011017736 or FRCS.NX or anything else for that matter)
i've attached a graphic.pl configuration data file (and resulting image)
that creates this sort of plot. however, i'm using cypress semiconductor
and the nasdaq 100 index since i've already got them in my database.
you will need to change '^NDX' to 'QS0011017736' or 'FRCS.NX' for the
add curve sys-sig-indic directive in the gconf file and of course replace
CY with AC.PA or FR0000120404 on the command line.
refer to attached files: eric_lemesre.gconf and the chart it produces
CY_elx.png using the 'kind-a-sorta' graphic.pl from the main trunk head.
(i'm not really sure it my repo version of graphic.pl is identical to
the one currently on the head, and i'm sure the rest of my gt toolkit
had some differences from the head version, but the differences should
be not be visible in the chart). the command line i used to create the
image is included in the gconf file. (note: your chart will vary for
a number of reasons: different set of days, different price data, plus
different set of global defaults set via your $HOME/.gt/options file.
be sure to study the gconf file carefully, i've included a lot of
important 'how-to' and 'watch-out-for' in commentary therein.
NB: this exercise points out one major weakness of graphic.pl and the
use of gconf file(s) to define the chart content. many times you want
to 'vary' certain parameters based on some external condition, in this
instance the index code being used should probably be the one that the
chart code is in (or somehow associated with), without having to edit
the gconf over and over again to effect the change (or have many gconf
files all very similar ...
my solution to this (and other problems with graphic.pl) is chart.pl.
it has provisions to support user defined variables that get substitute
throughout the gconf file. it's available only when used with most of my
other changes in the ras hack tarball set ... but last time i checked
it doesn't yet have 'user defined variables' and there isn't any logic
mechanism that would allow a case like switch to set a user variable based
on the 'code' industry or sector membership. of course, as it now stands
beancounter doesn't have tuples for 'code' industry or sector.
< large snip >
>
> French queties in yahoo quote is not a good way.
> For exemple ticker ALL in french market is Allianz and it is not with Yahoo
> Quote.
>
> I learn about CUIP and ISIN and ISIN code is international Code.
> For US market it is build with CUSIP and in first place US and in last place
> a number for control.
>
> A ISIN code is specific of Share not for Share in a special market.
> Raphael put somme function to check isin.
>
> And we can retrive CUSIP (US market) or SEDOL (GB market) with isin code.
>
>
revisiting my (prior) comments on getting prices data via finance.yahoo.com
for beancounter via the finance::yahooquote module. note that beancounter
also is (can be) installed into the perl finance:: directory hierarchy, but i
tend not to do it that way -- just stubborn i guess.
yahooquote is an application test script that comes with finance::yahooquote.
get_historical.sh is an application test script that comes with finance::yahooquote.
$ yahooquote FR0000120404
AC.PA ACCOR 34.74 2/14/2011 Paris
$ yahooquote AC.PA
AC.PA ACCOR 34.74 2/14/2011 Paris
these two yield identical results -- note i've made no changes to any
configuration file that might be used -- so my point is i'm probably
using a northamerican yahoo server ... but i'm still able to get the
price data from the paris market.
i'm not sure what FRCS.PA is but it looks to be an index
$ yahooquote FRCS.PA
FRCS.PA FRCS.PA 0.00 N/A N/A
-- one of the 'features' of various markets i've noticed of late in the
usa is that most indexes (e.g. sp500, nasdaq 100, dow jones, etc is they
seldom report the volume for today, but might (usually) do report it tomorrow.
as a consequence i have to do a one-day backpop to update the missing volume
index values. based on tests just now for FRCS.PA and for ^DJI (dow jones
industrials, and ^GSPC (goldman sacks sp500 index) data for indexes is not
available (via yahoo) before the market close.
today (monday 14feb2011
$ ../Finance-YahooQuote-0.22/examples/get_historical.sh FRCS.PA
or
$ ../Finance-YahooQuote-0.22/examples/get_historical.sh <anything>
will fail because the script fails to set yesterday to the previous market
yesterday ... the script might work tuesday through saturday ...
well it's tuesday and
$ ../Finance-YahooQuote-0.22/examples/get_historical.sh T
works, but
$ ../Finance-YahooQuote-0.22/examples/get_historical.sh FRCS.PA
and
$ ../Finance-YahooQuote-0.22/examples/get_historical.sh QS0011017736
fail
and
$ ../Finance-YahooQuote-0.22/examples/get_historical.sh AC.PA
works
but
$ ../Finance-YahooQuote-0.22/examples/get_historical.sh FR0000120404
fails
so it looks like Finance-YahooQuote might need some improvement/upgrade.
there are many other perl based stock price fetching modules that might be
better (or worse) or just different than Finance-YahooQuote. any should
be fairly easy to employ with whatever database you develop or employ.
|
|
From: Eric L. <eri...@gm...> - 2011-02-15 17:32:11
|
Hi and (i forgot mailling list) I am agree with you. Gt is a toolkit for technical analysis. And provide a unique way for database maintenance is an utopy. But i want to provide some module to manage share information : ShareInfo ShareInfo::Equities ShareInfo::Warant Etc ... Actualy learn about perl object and GT code. If you are some advices ... Eric Lemesre de mon Nexus One Le 15 févr. 2011 06:59, "Robert A. Schmied" <ra...@ac...> a écrit : > Eric Lemesre wrote: >> The difficulty is ISIN (Internattional Securities Identification Number) >> uniquely identifies a security. But not the exchange (if any) on which it >> Trades. The trading location is identify by MIC (Market Identification >> Code), a three-letter exchange code. >> >> And because it is too simple ;-) a price broker could have a diffrent ticker >> symbol than other one. >> Yahoo, bloomberg, euronext, reuter have her proper tickers. >> >> For more information : >> Http://en.wikipedia.org/wiki/International_Securities_Identification_Number >> Or the same in french >> fr.wikipedia.org/wiki/ISO_6166 > > this is good info > > finance.yahoo.com can sometimes be coerced into supplying specific market > data using the 'market place' letter extensions: > > $ yahooquote AC.PA > AC.PA ACCOR 34.74 2/14/2011 Paris > $ yahooquote FR0000120404 > AC.PA ACCOR 34.74 2/14/2011 Paris > $ yahooquote ALU.PA > ALU.PA ALCATEL-LUCENT 3.459 2/14/2011 Paris > > but getting either the symbol or the isin is still going to be problematic. > never-the-less it should be only a one time type action that once set > will change very little (things like merger and acquisition and exchange > rule violations, etc). > > and if you get price data feeds from a specific stock broker (or exchange) > the interface will likely be some sort of proprietary source that gt could > never be expected to support ... > >> >> At this time i can get over the net long name and symbol about 4500 >> securities in NSYE but no one with CUSIP or ISIN. >> >> I think ISIN is a good id for ShareInfo. > > (i'm still not sure i understand the complete scope of the purpose > and meaning of 'ShareInfo') -- i'm about to send a message in > reply to the deferred items i noted in this thread previously, review > that message too -- i give example of plotting an index along with > a specific primary stock code) > > the isin code bits (what little there is) in gt is in ../GT/Tools.pm. > but i don't find any use of it in the gt code base: > > % ggrep -iEr 'isin_' *.pl ../GT | ggrep -E '\.pl:|\.pm:' > > so you should expect it to be fairly well untested and possibly even > non-working code. > > > > eric i think the overall complexity of managing price and other security > information is the principle reason raphael and the other originators of > gt elected to *not* build the database into gt itself but instead provided > a wide range of alternatives that could be used to access the data from > the users preferred source whatever that might be. > > applying the dennis richie / ken thompson (unix) philosophy of > 'do only one thing but do it well' > to gt i would argue that gt should primarily do technical analysis > and depend/rely on one or more external utilities to maintain the data > gt needs ... > > the setup and maintenance of this securities prices database is one of > the most difficult parts of getting gt setup and ready to do it's thing. > if beancounter can be made to work with your market place and with the > sources it will search then it is a fairly good solution; it stores the > historical data, will fetch new data daily and provides database management > like backpopulate and the like ... > > that isn't to say i'm *not* interested in improving what gt can do, but > i think the effort to get more and different prices data might best be > applied to some external utility (like a major new version of beancounter > for example) or at least be a very independent part of gt. > > ras > >> >> Eric Lemesre >> de mon Nexus One >> Le 13 févr. 2011 22:10, "Robert A. Schmied" <ra...@ac...> a écrit : >> >>>Eric Lemesre wrote: >>> >>>>2011/2/3 Robert A. Schmied <ra...@ac...> >>>> >>>>>aloha eric >>>>> >>>>>i'm going to post this reply to the -devel mailing list since it has >>>>>lots of subject matter that might be of interest to others ... >>>>> >>>>>Eric Lemesre wrote: >>>>> >>>>> >>>>> >>>>>>Eric Lemesre >>>>>>de mon Nexus One >>>>>>Le 30 janv. 2011 03:33, "Robert A. Schmied" <ra...@ac...> a écrit : >>>>>> >>>>>>aloha eric >>>>>> >>>>>> >>>>>>>looking at the genericdbi code it seemed painful that default sql >>>>>>>query(ies) >>>>>>>are not provided, but i think that was intentional, since there isn't >> >> any >> >>>>>>>good way to know the underlying database schema. providing defaults for >>>>>>>beancounter are impractical, since there is a custom module for bc. >>>>>>> >>>>>> >>>>>> >>>>>>Ok for genericdbi default sql query is not a good idea. >>>>>> >>>>>> >>>>>>in my own version i have added much more *how-to* text in the pod, >>>>>> >>>>>> >>>>>>>just so i don't have to relearn everything when i'm doing support >>>>>>>activities ... >>>>>>> >>>>>>> >>>>>> >>>>>>It is possible to look this information? >>>>>> >>>>> >>>>>i've attached my version of module GT::DB::genericdbi, use it as you see >>>>>fit. >>>>>it includes your (eric lemesre) global $code regex change. plus a >> >> somewhat >> >>>>>modified >>>>>version of joao costas' time frame mapping. if anyone is currently using >>>>>the costa >>>>>time frame mapping and wants to evaluate this implementation i'd >> >> appreciate >> >>>>>the feed-back. >>>>> >>>> >>>>I don't understand why you don't put your version in SVN. >>>>If you preffer with a spacial branch like RAS branch. >>>>Any body can test your work ... and later we can merge your branch with >>>>Trunk >>>> >>> >>>i'm thinking on how to distribute my many gt 'ras hacks' via the svn >>>and or the soureforge 'files' download feature. issues include the >>>confusion/complexity of having yet another gt fork that has some >>>(not a lot) of installation differences between other versions. >>>if you are interested and want to evaluate this i will provide the 3 >>>distribution tarballs plus generic installation guidance instructions >>>upon request. >>> >>> >>>> >>>>>In wiki? >>>>> >>>>> >>>>>>I want to make somme little correction in the wiki. How can do this. (In >>>>>>graphic.pl). >>>>>> >>>>> >>>>>the new gt wiki website at http://geniustrader.org/wiki requires you to >>>>>'register' >>>>>a user id before being granted write privileges. you start the >> >> registration >> >>>>>process >>>>>with the 'login' button on the right hand side of page just below the >> >> 'link >> >>>>>box'. >>>>>select the register link on the login page to request a new login >>>>>id/password. >>>>> >>>>>if i remember correctly the wiki is using the dokuwiki formatting. there >> >> is >> >>>>>a >>>>>sandbox page for you to learn in ... >>>>> >>>>>Thanks I have a login in bugtracker and now i an one in Wiki. >>>> >>>>I put in graphic man page and backtest man page a docuwiki formating. >>>> >>> >>>excellent, all your changes look to be improvements -- thanks >>> >>> >>>> >>>>>>i think the gt database api really needs to be re-designed and >>>>>> >>>>>> >>>>>>>reimplemented >>>>>>>but i also think it should either support the current operation (as >>>>>>>broken >>>>>>>and odd as it is) or else be implemented as an optional replacement >> >> that >> >>>>>>>must >>>>>>>be explicitly enabled. this is because i don't want to change the basic >>>>>>>gt user >>>>>>>api and by doing so possibly break any customized user wrappers and >>>>>>>scripts >>>>>>>that the user has developed over the years ... >>>>>>> >>>>>>> >>>>>> >>>>>>How we can build a new api beside the older. And say for old function : >>>>>>deprecated. For long time old and new api can be live. >>>>>>I am not a perl guru :-) >>>>>> >>>>>> >>>>> >>>>>well, with perl (and most things unix) "there's more than one way to do >>>>>it". >>>>>if you are not an experienced object-oriented programmer and don't know >>>>>perl >>>>>then you really need to get a book or two on those subjects before trying >>>>>to >>>>>hack on gt. i recommend 'perl programming' wall, et al; o'reilly press. >>>>>there >>>>>is also a 'free' perl book, 'modern perl' by chromatic which is very good >>>>>too >>>>>(but being a gray-beard i don't think i'll ever loose my preference for a >>>>>physical >>>>>book). don't seem to see a url for it, but a google search should turn >> >> one >> >>>>>up. >>>>> >>>>>but an entirely new gt database design could be introduced with one or >> >> more >> >>>>>new GT::DB modules and 'enabled' in any number of ways including >>>>>a) a gt configuration key-value >>>>>b) shell environment variable(s) >>>>>c) gt application script command line option(s) >>>>>d) gt heuristic code that >>>>>1) detects the availability of the new database >>>>>2) detects prior use of the new database >>>>>makes presumption user wants to use it >>>>> >>>>>i'm sure other smarter programmers can envision any number of other >> >> better >> >>>>>ways >>>>>to accomplish this ... >>>>> >>>>> >>>>>as far as 'deprecating' the older interfaces, sure, but that would only >>>>>happen >>>>>way into the future, and may only imply the designated 'deprecated' >>>>>interface >>>>>is no longer being maintained, but is still available for use ... >>>>> >>>>>eric -- please note that over the years since i've been using gt others >>>>>have wanted to replace/improve/fix the stock prices database, but no one >>>>>has ever gone so far as even submitting a design concept, much less any >>>>>code. >>>>>so don't be too disappointed with my lack of enthusiasm, it is based on >>>>>past experience. >>>>> >>>> >>>>Don't be affraid about that ... >>>>I want to use some features with GT. >>>>I want to make a signal with Major Indice, Sectorial indice for equities. >>>> >>>>Exemple : >>>>Symbol = AC >>>>Code ISIN = FR0000120404 >>>>Long name = ACCOR >>>>Market code = PAR >>>>Code ICB1,ICB2,ICB3, ICB4 = 5000, 5700, 5750, 5753 >>>>symbol in french market ICB1, ICB3 = FRCS, FRTL >>>>Code ISIN for indice ICB1 ICB3 = QS0011017736, QS0011017884 >>>> >>>>I Want to add some curve with this syntax for a given code : >>>>--add="Curve(I::EMA 30 ShareInfo::INDICE_ICB1)" >>>>ShareInfo::INDICE_ICB1 return FRCS or QS0011017736 for code AC >>>> >>> >>>i'm going to postpone commenting on the above until i study it a bit more >>> >>> >>>> >>>> >>>>>>as a long time user of gt with a beancounter database i've never >>>>>> >>>>>> >>>>>>>entertained a serious look at this effort other than to apply >> >> maintenance >> >>>>>>>fixes. >>>>>>> >>>>>>>GT::DB::CSV would be a good starting point for a gt based stocks >>>>>>>database, >>>>>>>but i think it needs to be extended to also provide for these features: >>>>>>>* company fundamental data storage >>>>>>>(addinfo table needs additional columns to identify the nature of the >>>>>>>data value) >>>>>>>* user stock holdings and or user stock account transactions (these >> >> are >> >>>>>>>actual securities held or history positions and independent from the >>>>>>>gt portfolio stuff) >>>>>>>* a management application script >>>>>>>* a periodic data fetch application script >>>>>>>* a well tested (and testable) interface with widely known stock data >>>>>>>sources ... >>>>>>>* documentation, both user and programmer >>>>>>> >>>>>> >>>>>> >>>>>>YES : good job! i purpose to start with addinfo. >>>>>> >>>>> >>>>>regarding the storing of company fundamental data -- earnings and sales >>>>>data >>>>>(and most other fundamental data) is slowly varying based on the specific >>>>>companies' reporting periods. here in the usa the periods are usually 3 >>>>>month >>>>>time spans that can vary from quarter to quarter and from year to year, >> >> so >> >>>>>it >>>>>isn't a trivial effort to both store this (data warehousing) for >> >> retrieval >> >>>>>and to know when it is time to start looking for a new data point to >> >> store. >> >>>>>brute force might just store the same data every day, but that seems >>>>>less than ideal, a big waste of space, and makes it difficult to use this >>>>>data form when trying to do comparisons between reporting periods, etc. >>>>> >>>>>for those interested in this topic i am toying with enhancing the >>>>>beancounter >>>>>database schema to support such company fundamental data gathering and >>>>>warehousing. >>>>>with adequate user interest i believe we could convince dirk eddelbuettel >>>>>(mr. beancounter) to somehow support such table schema extensions if it >> >> can >> >>>>>be shown to be well conceived and implemented. let me know if you have >>>>>similar interests. >>>>> >>>> >>>>I go to learn about beancounter. >>>>But I think that beancounter methode must be one of methode for GT. >>>> >>>> >>>>humm -- i'll have to think on that a bit more ... from my perspective >> >> there >> >>>>>are many other things that i'd like to see improved or enhanced in gt but >>>>>i'm happy with the beancounter database interface. is there a particular >>>>>reason you are unable to use beancounter? it's perl so if gt works, so >>>>>should bc. frankly building into gt all the capability of beancounter and >>>>>yahooquote isn't high on my list of gt todo since those modules already >>>>>exist and work. but if you want to create a new wiki page that lists new >>>>>enhancement efforts, solicit help, and post progress, etc then that's a >>>>>fine and good use for the wiki. >>>>> >>>> >>>> >>>>French queties in yahoo quote is not a good way. >>>>For exemple ticker ALL in french market is Allianz and it is not with >> >> Yahoo >> >>>>Quote. >>>> >>>>I learn about CUIP and ISIN and ISIN code is international Code. >>>>For US market it is build with CUSIP and in first place US and in last >> >> place >> >>>>a number for control. >>>> >>>>A ISIN code is specific of Share not for Share in a special market. >>>>Raphael put somme function to check isin. >>>> >>>>And we can retrive CUSIP (US market) or SEDOL (GB market) with isin code. >>>> >>> >>>i'm entirely outside my experience base here so i'm not sure how to >> >> approach >> >>>this problem, but here's what i think i know -- if anyone has a solution >> >> for >> >>>this problem and wants to help please post your approach to the list or if >>>you prefer you can contact eric ( or me ) directly. >>> >>>it seems finance.yahoo.com can be tweaked by prefixing the country >> >> 'locale' >> >>>code to the url -- for example: >>> >>>http://fr.finance.yahoo.com >>>http://de.finance.yahoo.com >>>http://uk.finance.yahoo.com >>> >>>but that looks like it only 'languagizes' the site page. >>> >>>so i'm able to use either of >>>http://fr.finance.yahoo.com/q?s=ALV.F >>>or >>>http://uk.finance.yahoo.com/q?s=ALV.F >>> >>>further it seems that finance.yahoo.com uses a 'market' extension >>>on a 'ticker' that can be used to good purpose, but it still might >>>not solve the underlying issue. >>> >>>it also looks to me that Allianz has the 'code' of 840400. >>>it also appears that it is a german comany? because the isin >>>is DE0008404005. >>> >>>i don't understand the markets in the following list for ALV ( >> >> http://fr.finance.yahoo.com/lookup?s=DE0008404005) >> >>>ALV.DE Allianz SE DE0008404005 106,50 Titre GER >>>ALV.F ALLIANZ N DE0008404005 106,20 Titre FRA >>>ALV.BE ALLIANZ N DE0008404005 105,25 Titre BER >>>ALV.MI Allianz SE DE0008404005 105,10 Titre MIL >>>ALV.DU ALLIANZ N DE0008404005 105,35 Titre DUS >>>ALV.HM ALLIANZ N DE0008404005 106,50 Titre HAM >>>ALV.SG ALLIANZ N DE0008404005 106,34 Titre STU >>>ALV.TI ALLIANZ N DE0008404005 105,17 Titre TLO >>>ALV.MU ALLIANZ N DE0008404005 106,40 Titre MUN >>>ALV.HA ALLIANZ N DE0008404005 105,05 Titre HAN >>>ALVF.EX ALLIANZ N DE0008404005 98,07 Titre EUX >>>ALV.SW ALLIANZ N DE0008404005 115,00 Titre EBS >>> >>>but i'm guessing there is not a single french market listed. >>> >>>but but using the 'complete' isin code that yahoo lists for a >>>particular 'security' it appears that yahoo (and by extension >>>beancounter and gt can be made to work). >>> >>>using a (primarily) french company like total ( isin FR0000120271 ) >>>or alcatel-lucent ( isin FR0000130007 ) lists the .PA (paris?) >> >> designation: >> >>>( http://fr.finance.yahoo.com/lookup?s=TOTAL ) >>>FP.PA Total SA FR0000120271 43,45 Titre PAR >>>ALU.PA Alcatel-Lucent FR0000130007 3,39 Titre PAR >>> >>>i don't know how any of this might be made to work with beancounter >>>and finance::yahooquote i suspect you will only need to set the >>>beancounter 'symbol' to the full isin value. >>> >>>for example: >>> >>>$ yahooquote FR0000130007 DE0008404005 FR0000120271 >>>ALU.PA ALCATEL-LUCENT 3.385 2/11/2011 Paris >>>ALV.DE ALLIANZ N 106.50 2/11/2011 XETRA >>>FP.PA TOTAL 43.445 2/11/2011 Paris >>> >>>if any of this will work with the combination of gt and beancounter and >>>yahooquote was not investigated further. >>> >>> >>> >>>> >>>>>however, rather than make changes to the GT::DB::CSV module i'd recommend >>>>>you start with a new module that has GT::DB::CSV at its roots (meaning >> >> copy >> >>>>>and rename the GT::DB::CSV module). this would do to two important >> >> things: >> >>>>>* it wouldn't break anyones current use of CSV. >>>>>and more importantly, * it would give you the ability to give the >>>>>package a name that >>>>>implies more of it's purpose/use than CSV. >>>>> >>>>>the questions you asked in 'Add_info design' note: >>>>> >>>>> >>>>> >>>>>>- the way to retrive info is DB::[modul] 's specific. With an other >> >> words >> >>>>>>:Getting value info from info name is the reponsbility of modul. >>>>>> >>>>> >>>>>--- this is why some sort of a data fetch application script is needed >>>>>that can be easily used via the cron (crontab) facility. >>>>>in addition, in my experience with beancounter, such data fetching isn't >>>>>always 100% perfect there needs to be an additional data management >>>>>script used to correct missing/bad data. >>>>> >>>> >>>>I would like to clarify my thought. >>>>There are two functionalities in DB:: Module: >>>>1 recovery of information which are existent and in a particular format. >>>>2 feeding since another source of information. >>> >>> >>>i'm going to postpone commenting on the above until i study it a bit more >>> >>> >>> >>>>To be able to use information additional on actions it is necessary that >>>>these is encoded in one way in GT. And so possible irremovable. >>>>For instance if they like to recover the indice ICB1 of an action with >> >> the >> >>>>name {ShareInfo INDICE_ICB1} it is necessary that INDICE_ICB1 always >> >> makes >> >>>>reference has this same information. Perhaps if in a database this >>>>information carries the name INDICE_SECTOIREL_1. And in an other one with >>>>the name IDC_SE_1. >>>> >>>> >>>> >>>> >>>>>i would suggest you limit the changes to GT::DB.pm to methods that could >>>>>conceivably be extended to all other GT::DB:: modules just to keeps >> >> things >> >>>>>consistent across all database objects. in other words, database writing >>>>>methods would likely best reside in gt::db::el_db, since they would be >>>>>unique >>>>>to databases of that kind. >>>> >>> >> > |
|
From: Robert A. S. <ra...@ac...> - 2011-02-13 21:59:20
|
Eric Lemesre wrote: > 2011/2/3 Robert A. Schmied <ra...@ac...> > >>aloha eric >> >>i'm going to post this reply to the -devel mailing list since it has >>lots of subject matter that might be of interest to others ... >> >>Eric Lemesre wrote: >> >> >>>Eric Lemesre >>>de mon Nexus One >>>Le 30 janv. 2011 03:33, "Robert A. Schmied" <ra...@ac...> a écrit : >>> >>> aloha eric >>> >>>>looking at the genericdbi code it seemed painful that default sql >>>>query(ies) >>>>are not provided, but i think that was intentional, since there isn't any >>>>good way to know the underlying database schema. providing defaults for >>>>beancounter are impractical, since there is a custom module for bc. >>>> >>> >>> >>>Ok for genericdbi default sql query is not a good idea. >>> >>> >>> in my own version i have added much more *how-to* text in the pod, >>> >>>>just so i don't have to relearn everything when i'm doing support >>>>activities ... >>>> >>>> >>> >>>It is possible to look this information? >>> >> >>i've attached my version of module GT::DB::genericdbi, use it as you see >>fit. >>it includes your (eric lemesre) global $code regex change. plus a somewhat >>modified >>version of joao costas' time frame mapping. if anyone is currently using >>the costa >>time frame mapping and wants to evaluate this implementation i'd appreciate >>the feed-back. >> > > I don't understand why you don't put your version in SVN. > If you preffer with a spacial branch like RAS branch. > Any body can test your work ... and later we can merge your branch with > Trunk > i'm thinking on how to distribute my many gt 'ras hacks' via the svn and or the soureforge 'files' download feature. issues include the confusion/complexity of having yet another gt fork that has some (not a lot) of installation differences between other versions. if you are interested and want to evaluate this i will provide the 3 distribution tarballs plus generic installation guidance instructions upon request. > > >> In wiki? >> >>>I want to make somme little correction in the wiki. How can do this. (In >>>graphic.pl). >>> >> >>the new gt wiki website at http://geniustrader.org/wiki requires you to >>'register' >>a user id before being granted write privileges. you start the registration >>process >>with the 'login' button on the right hand side of page just below the 'link >>box'. >>select the register link on the login page to request a new login >>id/password. >> >>if i remember correctly the wiki is using the dokuwiki formatting. there is >>a >>sandbox page for you to learn in ... >> >>Thanks I have a login in bugtracker and now i an one in Wiki. > > I put in graphic man page and backtest man page a docuwiki formating. > excellent, all your changes look to be improvements -- thanks > > >>> i think the gt database api really needs to be re-designed and >>> >>>>reimplemented >>>>but i also think it should either support the current operation (as >>>>broken >>>>and odd as it is) or else be implemented as an optional replacement that >>>>must >>>>be explicitly enabled. this is because i don't want to change the basic >>>>gt user >>>>api and by doing so possibly break any customized user wrappers and >>>>scripts >>>>that the user has developed over the years ... >>>> >>>> >>> >>>How we can build a new api beside the older. And say for old function : >>>deprecated. For long time old and new api can be live. >>>I am not a perl guru :-) >>> >>> >> >>well, with perl (and most things unix) "there's more than one way to do >>it". >>if you are not an experienced object-oriented programmer and don't know >>perl >>then you really need to get a book or two on those subjects before trying >>to >>hack on gt. i recommend 'perl programming' wall, et al; o'reilly press. >>there >>is also a 'free' perl book, 'modern perl' by chromatic which is very good >>too >>(but being a gray-beard i don't think i'll ever loose my preference for a >>physical >>book). don't seem to see a url for it, but a google search should turn one >>up. >> >>but an entirely new gt database design could be introduced with one or more >>new GT::DB modules and 'enabled' in any number of ways including >>a) a gt configuration key-value >>b) shell environment variable(s) >>c) gt application script command line option(s) >>d) gt heuristic code that >> 1) detects the availability of the new database >> 2) detects prior use of the new database >> makes presumption user wants to use it >> >>i'm sure other smarter programmers can envision any number of other better >>ways >>to accomplish this ... >> >> >>as far as 'deprecating' the older interfaces, sure, but that would only >>happen >>way into the future, and may only imply the designated 'deprecated' >>interface >>is no longer being maintained, but is still available for use ... >> >>eric -- please note that over the years since i've been using gt others >>have wanted to replace/improve/fix the stock prices database, but no one >>has ever gone so far as even submitting a design concept, much less any >>code. >>so don't be too disappointed with my lack of enthusiasm, it is based on >>past experience. >> > > Don't be affraid about that ... > I want to use some features with GT. > I want to make a signal with Major Indice, Sectorial indice for equities. > > Exemple : > Symbol = AC > Code ISIN = FR0000120404 > Long name = ACCOR > Market code = PAR > Code ICB1,ICB2,ICB3, ICB4 = 5000, 5700, 5750, 5753 > symbol in french market ICB1, ICB3 = FRCS, FRTL > Code ISIN for indice ICB1 ICB3 = QS0011017736, QS0011017884 > > I Want to add some curve with this syntax for a given code : > --add="Curve(I::EMA 30 ShareInfo::INDICE_ICB1)" > ShareInfo::INDICE_ICB1 return FRCS or QS0011017736 for code AC > i'm going to postpone commenting on the above until i study it a bit more > > > >>> as a long time user of gt with a beancounter database i've never >>> >>>>entertained a serious look at this effort other than to apply maintenance >>>>fixes. >>>> >>>>GT::DB::CSV would be a good starting point for a gt based stocks >>>>database, >>>>but i think it needs to be extended to also provide for these features: >>>> * company fundamental data storage >>>> (addinfo table needs additional columns to identify the nature of the >>>>data value) >>>> * user stock holdings and or user stock account transactions (these are >>>> actual securities held or history positions and independent from the >>>> gt portfolio stuff) >>>> * a management application script >>>> * a periodic data fetch application script >>>> * a well tested (and testable) interface with widely known stock data >>>>sources ... >>>> * documentation, both user and programmer >>>> >>> >>> >>>YES : good job! i purpose to start with addinfo. >>> >> >>regarding the storing of company fundamental data -- earnings and sales >>data >>(and most other fundamental data) is slowly varying based on the specific >>companies' reporting periods. here in the usa the periods are usually 3 >>month >>time spans that can vary from quarter to quarter and from year to year, so >>it >>isn't a trivial effort to both store this (data warehousing) for retrieval >>and to know when it is time to start looking for a new data point to store. >>brute force might just store the same data every day, but that seems >>less than ideal, a big waste of space, and makes it difficult to use this >>data form when trying to do comparisons between reporting periods, etc. >> >>for those interested in this topic i am toying with enhancing the >>beancounter >>database schema to support such company fundamental data gathering and >>warehousing. >>with adequate user interest i believe we could convince dirk eddelbuettel >>(mr. beancounter) to somehow support such table schema extensions if it can >>be shown to be well conceived and implemented. let me know if you have >>similar interests. >> > > I go to learn about beancounter. > But I think that beancounter methode must be one of methode for GT. > > > humm -- i'll have to think on that a bit more ... from my perspective there > >>are many other things that i'd like to see improved or enhanced in gt but >>i'm happy with the beancounter database interface. is there a particular >>reason you are unable to use beancounter? it's perl so if gt works, so >>should bc. frankly building into gt all the capability of beancounter and >>yahooquote isn't high on my list of gt todo since those modules already >>exist and work. but if you want to create a new wiki page that lists new >>enhancement efforts, solicit help, and post progress, etc then that's a >>fine and good use for the wiki. >> > > > French queties in yahoo quote is not a good way. > For exemple ticker ALL in french market is Allianz and it is not with Yahoo > Quote. > > I learn about CUIP and ISIN and ISIN code is international Code. > For US market it is build with CUSIP and in first place US and in last place > a number for control. > > A ISIN code is specific of Share not for Share in a special market. > Raphael put somme function to check isin. > > And we can retrive CUSIP (US market) or SEDOL (GB market) with isin code. > i'm entirely outside my experience base here so i'm not sure how to approach this problem, but here's what i think i know -- if anyone has a solution for this problem and wants to help please post your approach to the list or if you prefer you can contact eric ( or me ) directly. it seems finance.yahoo.com can be tweaked by prefixing the country 'locale' code to the url -- for example: http://fr.finance.yahoo.com http://de.finance.yahoo.com http://uk.finance.yahoo.com but that looks like it only 'languagizes' the site page. so i'm able to use either of http://fr.finance.yahoo.com/q?s=ALV.F or http://uk.finance.yahoo.com/q?s=ALV.F further it seems that finance.yahoo.com uses a 'market' extension on a 'ticker' that can be used to good purpose, but it still might not solve the underlying issue. it also looks to me that Allianz has the 'code' of 840400. it also appears that it is a german comany? because the isin is DE0008404005. i don't understand the markets in the following list for ALV (http://fr.finance.yahoo.com/lookup?s=DE0008404005) ALV.DE Allianz SE DE0008404005 106,50 Titre GER ALV.F ALLIANZ N DE0008404005 106,20 Titre FRA ALV.BE ALLIANZ N DE0008404005 105,25 Titre BER ALV.MI Allianz SE DE0008404005 105,10 Titre MIL ALV.DU ALLIANZ N DE0008404005 105,35 Titre DUS ALV.HM ALLIANZ N DE0008404005 106,50 Titre HAM ALV.SG ALLIANZ N DE0008404005 106,34 Titre STU ALV.TI ALLIANZ N DE0008404005 105,17 Titre TLO ALV.MU ALLIANZ N DE0008404005 106,40 Titre MUN ALV.HA ALLIANZ N DE0008404005 105,05 Titre HAN ALVF.EX ALLIANZ N DE0008404005 98,07 Titre EUX ALV.SW ALLIANZ N DE0008404005 115,00 Titre EBS but i'm guessing there is not a single french market listed. but but using the 'complete' isin code that yahoo lists for a particular 'security' it appears that yahoo (and by extension beancounter and gt can be made to work). using a (primarily) french company like total ( isin FR0000120271 ) or alcatel-lucent ( isin FR0000130007 ) lists the .PA (paris?) designation: ( http://fr.finance.yahoo.com/lookup?s=TOTAL ) FP.PA Total SA FR0000120271 43,45 Titre PAR ALU.PA Alcatel-Lucent FR0000130007 3,39 Titre PAR i don't know how any of this might be made to work with beancounter and finance::yahooquote i suspect you will only need to set the beancounter 'symbol' to the full isin value. for example: $ yahooquote FR0000130007 DE0008404005 FR0000120271 ALU.PA ALCATEL-LUCENT 3.385 2/11/2011 Paris ALV.DE ALLIANZ N 106.50 2/11/2011 XETRA FP.PA TOTAL 43.445 2/11/2011 Paris if any of this will work with the combination of gt and beancounter and yahooquote was not investigated further. > > >>however, rather than make changes to the GT::DB::CSV module i'd recommend >>you start with a new module that has GT::DB::CSV at its roots (meaning copy >>and rename the GT::DB::CSV module). this would do to two important things: >> * it wouldn't break anyones current use of CSV. >>and more importantly, * it would give you the ability to give the >>package a name that >> implies more of it's purpose/use than CSV. >> >>the questions you asked in 'Add_info design' note: >> >> >>>- the way to retrive info is DB::[modul] 's specific. With an other words >>> :Getting value info from info name is the reponsbility of modul. >>> >> >>--- this is why some sort of a data fetch application script is needed >> that can be easily used via the cron (crontab) facility. >> in addition, in my experience with beancounter, such data fetching isn't >> always 100% perfect there needs to be an additional data management >> script used to correct missing/bad data. >> > > I would like to clarify my thought. > There are two functionalities in DB:: Module: > 1 recovery of information which are existent and in a particular format. > 2 feeding since another source of information. i'm going to postpone commenting on the above until i study it a bit more > > To be able to use information additional on actions it is necessary that > these is encoded in one way in GT. And so possible irremovable. > For instance if they like to recover the indice ICB1 of an action with the > name {ShareInfo INDICE_ICB1} it is necessary that INDICE_ICB1 always makes > reference has this same information. Perhaps if in a database this > information carries the name INDICE_SECTOIREL_1. And in an other one with > the name IDC_SE_1. > > > >>i would suggest you limit the changes to GT::DB.pm to methods that could >>conceivably be extended to all other GT::DB:: modules just to keeps things >>consistent across all database objects. in other words, database writing >>methods would likely best reside in gt::db::el_db, since they would be >>unique >>to databases of that kind. > >> > |
|
From: Eric L. <eri...@gm...> - 2011-02-13 15:08:39
|
2011/2/3 Robert A. Schmied <ra...@ac...> > aloha eric > > i'm going to post this reply to the -devel mailing list since it has > lots of subject matter that might be of interest to others ... > > Eric Lemesre wrote: > >> Eric Lemesre >> de mon Nexus One >> Le 30 janv. 2011 03:33, "Robert A. Schmied" <ra...@ac...> a écrit : >> >> aloha eric >>> >>> looking at the genericdbi code it seemed painful that default sql >>> query(ies) >>> are not provided, but i think that was intentional, since there isn't any >>> good way to know the underlying database schema. providing defaults for >>> beancounter are impractical, since there is a custom module for bc. >>> >> >> >> Ok for genericdbi default sql query is not a good idea. >> >> >> in my own version i have added much more *how-to* text in the pod, >>> just so i don't have to relearn everything when i'm doing support >>> activities ... >>> >>> >> >> It is possible to look this information? >> > > i've attached my version of module GT::DB::genericdbi, use it as you see > fit. > it includes your (eric lemesre) global $code regex change. plus a somewhat > modified > version of joao costas' time frame mapping. if anyone is currently using > the costa > time frame mapping and wants to evaluate this implementation i'd appreciate > the feed-back. > I don't understand why you don't put your version in SVN. If you preffer with a spacial branch like RAS branch. Any body can test your work ... and later we can merge your branch with Trunk > In wiki? >> I want to make somme little correction in the wiki. How can do this. (In >> graphic.pl). >> > > the new gt wiki website at http://geniustrader.org/wiki requires you to > 'register' > a user id before being granted write privileges. you start the registration > process > with the 'login' button on the right hand side of page just below the 'link > box'. > select the register link on the login page to request a new login > id/password. > > if i remember correctly the wiki is using the dokuwiki formatting. there is > a > sandbox page for you to learn in ... > > Thanks I have a login in bugtracker and now i an one in Wiki. I put in graphic man page and backtest man page a docuwiki formating. > >> i think the gt database api really needs to be re-designed and >>> reimplemented >>> but i also think it should either support the current operation (as >>> broken >>> and odd as it is) or else be implemented as an optional replacement that >>> must >>> be explicitly enabled. this is because i don't want to change the basic >>> gt user >>> api and by doing so possibly break any customized user wrappers and >>> scripts >>> that the user has developed over the years ... >>> >>> >> >> How we can build a new api beside the older. And say for old function : >> deprecated. For long time old and new api can be live. >> I am not a perl guru :-) >> >> > well, with perl (and most things unix) "there's more than one way to do > it". > if you are not an experienced object-oriented programmer and don't know > perl > then you really need to get a book or two on those subjects before trying > to > hack on gt. i recommend 'perl programming' wall, et al; o'reilly press. > there > is also a 'free' perl book, 'modern perl' by chromatic which is very good > too > (but being a gray-beard i don't think i'll ever loose my preference for a > physical > book). don't seem to see a url for it, but a google search should turn one > up. > > but an entirely new gt database design could be introduced with one or more > new GT::DB modules and 'enabled' in any number of ways including > a) a gt configuration key-value > b) shell environment variable(s) > c) gt application script command line option(s) > d) gt heuristic code that > 1) detects the availability of the new database > 2) detects prior use of the new database > makes presumption user wants to use it > > i'm sure other smarter programmers can envision any number of other better > ways > to accomplish this ... > > > as far as 'deprecating' the older interfaces, sure, but that would only > happen > way into the future, and may only imply the designated 'deprecated' > interface > is no longer being maintained, but is still available for use ... > > eric -- please note that over the years since i've been using gt others > have wanted to replace/improve/fix the stock prices database, but no one > has ever gone so far as even submitting a design concept, much less any > code. > so don't be too disappointed with my lack of enthusiasm, it is based on > past experience. > Don't be affraid about that ... I want to use some features with GT. I want to make a signal with Major Indice, Sectorial indice for equities. Exemple : Symbol = AC Code ISIN = FR0000120404 Long name = ACCOR Market code = PAR Code ICB1,ICB2,ICB3, ICB4 = 5000, 5700, 5750, 5753 symbol in french market ICB1, ICB3 = FRCS, FRTL Code ISIN for indice ICB1 ICB3 = QS0011017736, QS0011017884 I Want to add some curve with this syntax for a given code : --add="Curve(I::EMA 30 ShareInfo::INDICE_ICB1)" ShareInfo::INDICE_ICB1 return FRCS or QS0011017736 for code AC >> as a long time user of gt with a beancounter database i've never >>> entertained a serious look at this effort other than to apply maintenance >>> fixes. >>> >>> GT::DB::CSV would be a good starting point for a gt based stocks >>> database, >>> but i think it needs to be extended to also provide for these features: >>> * company fundamental data storage >>> (addinfo table needs additional columns to identify the nature of the >>> data value) >>> * user stock holdings and or user stock account transactions (these are >>> actual securities held or history positions and independent from the >>> gt portfolio stuff) >>> * a management application script >>> * a periodic data fetch application script >>> * a well tested (and testable) interface with widely known stock data >>> sources ... >>> * documentation, both user and programmer >>> >> >> >> YES : good job! i purpose to start with addinfo. >> > > regarding the storing of company fundamental data -- earnings and sales > data > (and most other fundamental data) is slowly varying based on the specific > companies' reporting periods. here in the usa the periods are usually 3 > month > time spans that can vary from quarter to quarter and from year to year, so > it > isn't a trivial effort to both store this (data warehousing) for retrieval > and to know when it is time to start looking for a new data point to store. > brute force might just store the same data every day, but that seems > less than ideal, a big waste of space, and makes it difficult to use this > data form when trying to do comparisons between reporting periods, etc. > > for those interested in this topic i am toying with enhancing the > beancounter > database schema to support such company fundamental data gathering and > warehousing. > with adequate user interest i believe we could convince dirk eddelbuettel > (mr. beancounter) to somehow support such table schema extensions if it can > be shown to be well conceived and implemented. let me know if you have > similar interests. > I go to learn about beancounter. But I think that beancounter methode must be one of methode for GT. humm -- i'll have to think on that a bit more ... from my perspective there > are many other things that i'd like to see improved or enhanced in gt but > i'm happy with the beancounter database interface. is there a particular > reason you are unable to use beancounter? it's perl so if gt works, so > should bc. frankly building into gt all the capability of beancounter and > yahooquote isn't high on my list of gt todo since those modules already > exist and work. but if you want to create a new wiki page that lists new > enhancement efforts, solicit help, and post progress, etc then that's a > fine and good use for the wiki. > French queties in yahoo quote is not a good way. For exemple ticker ALL in french market is Allianz and it is not with Yahoo Quote. I learn about CUIP and ISIN and ISIN code is international Code. For US market it is build with CUSIP and in first place US and in last place a number for control. A ISIN code is specific of Share not for Share in a special market. Raphael put somme function to check isin. And we can retrive CUSIP (US market) or SEDOL (GB market) with isin code. > > however, rather than make changes to the GT::DB::CSV module i'd recommend > you start with a new module that has GT::DB::CSV at its roots (meaning copy > and rename the GT::DB::CSV module). this would do to two important things: > * it wouldn't break anyones current use of CSV. > and more importantly, * it would give you the ability to give the > package a name that > implies more of it's purpose/use than CSV. > > the questions you asked in 'Add_info design' note: > >> - the way to retrive info is DB::[modul] 's specific. With an other words >> :Getting value info from info name is the reponsbility of modul. >> > --- this is why some sort of a data fetch application script is needed > that can be easily used via the cron (crontab) facility. > in addition, in my experience with beancounter, such data fetching isn't > always 100% perfect there needs to be an additional data management > script used to correct missing/bad data. > I would like to clarify my thought. There are two functionalities in DB:: Module: 1 recovery of information which are existent and in a particular format. 2 feeding since another source of information. To be able to use information additional on actions it is necessary that these is encoded in one way in GT. And so possible irremovable. For instance if they like to recover the indice ICB1 of an action with the name {ShareInfo INDICE_ICB1} it is necessary that INDICE_ICB1 always makes reference has this same information. Perhaps if in a database this information carries the name INDICE_SECTOIREL_1. And in an other one with the name IDC_SE_1. > i would suggest you limit the changes to GT::DB.pm to methods that could > conceivably be extended to all other GT::DB:: modules just to keeps things > consistent across all database objects. in other words, database writing > methods would likely best reside in gt::db::el_db, since they would be > unique > to databases of that kind. > |
|
From: Robert A. S. <ra...@ac...> - 2011-02-03 17:56:35
|
aloha eric i'm going to post this reply to the -devel mailing list since it has lots of subject matter that might be of interest to others ... Eric Lemesre wrote: > Eric Lemesre > de mon Nexus One > Le 30 janv. 2011 03:33, "Robert A. Schmied" <ra...@ac...> a écrit : > >> aloha eric >> >> looking at the genericdbi code it seemed painful that default sql query(ies) >> are not provided, but i think that was intentional, since there isn't any >> good way to know the underlying database schema. providing defaults for >> beancounter are impractical, since there is a custom module for bc. > > > Ok for genericdbi default sql query is not a good idea. > > >> in my own version i have added much more *how-to* text in the pod, >> just so i don't have to relearn everything when i'm doing support activities ... >> > > > It is possible to look this information? i've attached my version of module GT::DB::genericdbi, use it as you see fit. it includes your (eric lemesre) global $code regex change. plus a somewhat modified version of joao costas' time frame mapping. if anyone is currently using the costa time frame mapping and wants to evaluate this implementation i'd appreciate the feed-back. > In wiki? > I want to make somme little correction in the wiki. How can do this. (In > graphic.pl). the new gt wiki website at http://geniustrader.org/wiki requires you to 'register' a user id before being granted write privileges. you start the registration process with the 'login' button on the right hand side of page just below the 'link box'. select the register link on the login page to request a new login id/password. if i remember correctly the wiki is using the dokuwiki formatting. there is a sandbox page for you to learn in ... > > >> i think the gt database api really needs to be re-designed and reimplemented >> but i also think it should either support the current operation (as broken >> and odd as it is) or else be implemented as an optional replacement that must >> be explicitly enabled. this is because i don't want to change the basic gt user >> api and by doing so possibly break any customized user wrappers and scripts >> that the user has developed over the years ... >> > > > How we can build a new api beside the older. And say for old function : > deprecated. For long time old and new api can be live. > I am not a perl guru :-) > well, with perl (and most things unix) "there's more than one way to do it". if you are not an experienced object-oriented programmer and don't know perl then you really need to get a book or two on those subjects before trying to hack on gt. i recommend 'perl programming' wall, et al; o'reilly press. there is also a 'free' perl book, 'modern perl' by chromatic which is very good too (but being a gray-beard i don't think i'll ever loose my preference for a physical book). don't seem to see a url for it, but a google search should turn one up. but an entirely new gt database design could be introduced with one or more new GT::DB modules and 'enabled' in any number of ways including a) a gt configuration key-value b) shell environment variable(s) c) gt application script command line option(s) d) gt heuristic code that 1) detects the availability of the new database 2) detects prior use of the new database makes presumption user wants to use it i'm sure other smarter programmers can envision any number of other better ways to accomplish this ... as far as 'deprecating' the older interfaces, sure, but that would only happen way into the future, and may only imply the designated 'deprecated' interface is no longer being maintained, but is still available for use ... eric -- please note that over the years since i've been using gt others have wanted to replace/improve/fix the stock prices database, but no one has ever gone so far as even submitting a design concept, much less any code. so don't be too disappointed with my lack of enthusiasm, it is based on past experience. > >> as a long time user of gt with a beancounter database i've never entertained >> a serious look at this effort other than to apply maintenance fixes. >> >> GT::DB::CSV would be a good starting point for a gt based stocks database, >> but i think it needs to be extended to also provide for these features: >> * company fundamental data storage >> (addinfo table needs additional columns to identify the nature of the data value) >> * user stock holdings and or user stock account transactions (these are >> actual securities held or history positions and independent from the >> gt portfolio stuff) >> * a management application script >> * a periodic data fetch application script >> * a well tested (and testable) interface with widely known stock data sources ... >> * documentation, both user and programmer > > > YES : good job! i purpose to start with addinfo. regarding the storing of company fundamental data -- earnings and sales data (and most other fundamental data) is slowly varying based on the specific companies' reporting periods. here in the usa the periods are usually 3 month time spans that can vary from quarter to quarter and from year to year, so it isn't a trivial effort to both store this (data warehousing) for retrieval and to know when it is time to start looking for a new data point to store. brute force might just store the same data every day, but that seems less than ideal, a big waste of space, and makes it difficult to use this data form when trying to do comparisons between reporting periods, etc. for those interested in this topic i am toying with enhancing the beancounter database schema to support such company fundamental data gathering and warehousing. with adequate user interest i believe we could convince dirk eddelbuettel (mr. beancounter) to somehow support such table schema extensions if it can be shown to be well conceived and implemented. let me know if you have similar interests. > > What do you think about put this point in todo file in repository? humm -- i'll have to think on that a bit more ... from my perspective there are many other things that i'd like to see improved or enhanced in gt but i'm happy with the beancounter database interface. is there a particular reason you are unable to use beancounter? it's perl so if gt works, so should bc. frankly building into gt all the capability of beancounter and yahooquote isn't high on my list of gt todo since those modules already exist and work. but if you want to create a new wiki page that lists new enhancement efforts, solicit help, and post progress, etc then that's a fine and good use for the wiki. however, rather than make changes to the GT::DB::CSV module i'd recommend you start with a new module that has GT::DB::CSV at its roots (meaning copy and rename the GT::DB::CSV module). this would do to two important things: * it wouldn't break anyones current use of CSV. and more importantly, * it would give you the ability to give the package a name that implies more of it's purpose/use than CSV. the questions you asked in 'Add_info design' note: > - the way to retrive info is DB::[modul] 's specific. With an other words > :Getting value info from info name is the reponsbility of modul. --- this is why some sort of a data fetch application script is needed that can be easily used via the cron (crontab) facility. in addition, in my experience with beancounter, such data fetching isn't always 100% perfect there needs to be an additional data management script used to correct missing/bad data. > - but the code to getting specific info name must be the DB resposability. > And code to get specific info with info name substitution can (or must) be > factorisable in DB.pm --- i not sure i understand the meaning of this. my view is fairly simplistic: a number (2-4) of independent new application scripts that taken together with the gt::db::el_db module implement a new stock prices database. this is similar to the use of finance::beancounter and finance::yahooquote and gt::db::bean. i would suggest you limit the changes to GT::DB.pm to methods that could conceivably be extended to all other GT::DB:: modules just to keeps things consistent across all database objects. in other words, database writing methods would likely best reside in gt::db::el_db, since they would be unique to databases of that kind. changing the repo GT/TODO file is a bit premature i think, but i could be induced to change that opinion if substantial progress and/or the gt using community indicates it is a good idea ... aloha ras > > Eric > |
|
From: Eric L. <eri...@gm...> - 2011-02-03 07:16:12
|
Hi, Some question about addinfo mecanisme : - the way to retrive info is DB::[modul] 's specific. With an other words :Getting value info from info name is the reponsbility of modul. - but the code to getting specific info name must be the DB resposability. And code to get specific info with info name substitution can (or must) be factorisable in DB.pm I finalyse the code (DB.pm and DB:genericdbi.pm) and join it for discusion. Wath do you think a out that? Eric Lemesre de mon Nexus One |
|
From: Robert A. S. <ra...@ac...> - 2011-01-27 21:11:19
|
Eric Lemesre wrote:
> Hi
>
> If the query DB::genericdbi::prices_sql ave 2 $code only the first is
> substituate.
>
> With this litle path it is solve.
>
>
>
>
> ------------------------------------------------------------------------
>
> # This patch file was generated by NetBeans IDE
> # It uses platform neutral UTF-8 encoding and \n newlines.
> --- Remotely Modified (Based On HEAD)
> +++ Locally Modified (Based On LOCAL)
> @@ -142,10 +142,11 @@
>
> my $sql = GT::Conf::get("DB::genericdbi::prices_sql::$timeframe", GT::Conf::get('DB::genericdbi::prices_sql'));
> die("Invalid configuration. You must specify a valid prices sql statment for your database in the options file") if (!defined($sql));
> - $sql =~ s/\$code/$code/;
> + $sql =~ s/\$code/$code/g;
> +
> my $tf_map_value = GT::Conf::get("DB::genericdbi::tf_map::$timeframe",$timeframe);
> - $sql =~ s/\$timeframe/$tf_map_value/;
> - $sql =~ s/\$limit/$limit/;
> + $sql =~ s/\$timeframe/$tf_map_value/g;
> + $sql =~ s/\$limit/$limit/g;
>
> my $sth = $self->{'_dbh'}->prepare($sql)
> || die $self->{'_dbh'}->errstr;
>
<snip>
aloha eric
can you provide more detail on the database structure and or a sql query
statement that would require more than a single $code reference? (as well
as queries with multiple $timeframe and $limit references?)
ras
|
|
From: Eric L. <eri...@gm...> - 2011-01-27 20:43:40
|
Hi If the query DB::genericdbi::prices_sql ave 2 $code only the first is substituate. With this litle path it is solve. -- Eric Lemesre |
|
From: Robert A. S. <ra...@ac...> - 2011-01-02 20:18:07
|
Gianni76 wrote: > Dear Robert and all, > thank you for your tests and suggestions. I have done really a lot more > in the last few days and have come to these conclusions to my original > quest: gianni -- i think this would be a good guide to add to the new web page on how to install and use gt with windows. if you could please add some version data or other info where indicated below that would be beneficial for others ... > > - The best version of GeniusTrader to start with in Windows (for > timeframes=1min) is at present the CPAN Finance::GeniusTrader. (I > installed v.0.50) please indicate the url you got this version from (there is the one in the sourceforge gt repository and the one at cpan itself. i believe they are different repositories). > This version is the most compatible with the different command and > options for graphics and testing. It is the only one that has not broken > up or gave me strange errors with same cases. > > For larger timeframes I would suggest the nice Chia-liang Kao 'cpan-pu' > version, which contains some speed-ups and general improvements. please indicate the url where this is located. it doesn't appear to be in the sourceforge gt repository. > > to install them on windows, just dezip/detar the package in a directory > 8for example called gt05), > go into that directory and write > > perl Makefile.PL > nmake test > nmake install > > (if you have a problem/error due to a missing nmake, go and download it > here: > http://download.microsoft.com/download/vc15/Patch/1.52/W95/EN-US/Nmake15.exe > and place it in your perl/bin directory with the name nmake.exe) > other topics: > - I still don't see what is/could be the problem connected with absolute > times. Robert, you asked me what is the best way to deal with local > times of different stocks. > To me time is simply a label and as such should always remain in local > hours, e.g. when I deal with Italian stock I get them at my local time > in Italy (db populated from 9 to 17.30 in the main session + after hours > from 18 - 20.30). When I deal with US stock, the time is from 15 to > 22.30 etc. (again what is recorded in the stock logs is my local italian > time and not the usa or gmt time). so you are saying that you either get ticker feeds with the trading floor time conversion to local time already performed by some upstream process or you handle that time conversion locally before storing the data. either way the conversion to local time has to be done. the problem is when you share that database with others and then compare results of others using that same data. if all parties assume their local time zone and their standard market hours and there isn't a specific time-zone reference in the database then result will be hard to compare because your results between 0900 to 1730 will vary tremendously with mine between 0900 to 1600 when i apply my local to nyse offset (which should be expecting 0600 to 1300). the large question is: how do trading markets time-stamp trades? -- my guess is some form of day, month, year, hour, minute, second and possibly millisecond and a time zone designation or gmt offset. for gt specifically: if we assume database is local time should that local time be somehow noted in the database itself? a single header line like '# gmt offset +1:00' would do. or should we assume the database includes a particular trading floor time-stamp on each data entry? in either case changes need to be made to GT/DB/Text.pm and other database modules to accommodate the time zone attribute. > > - issues still not solved: > * Date::Manip (even if this is installed in my Perl distribution), is > not working properly with GT calls under Windows, so I had to comment > out the #check_dates($timeframe, $start, $end) in graphic.pl to make > things work. i do not recall the history of this subroutine, but do see that the one i use differs slightly from the one in my older copy of the trunk svn. > > * I could not get any version to accept multiline commands > (e.g. something like: > --add=BuySellArrows( Systems::Generic {Signals::Generic::CrossOverUp > {I:EMA 5 {I:Prices CLOSE}} {I:EMA 20 {I:Prices CLOSE}}} > {Signals::Generic::CrossOverDown {I:EMA 5 {I:Prices CLOSE}} {I:EMA 20 > {I:Prices CLOSE}}} , 10) > 8all in a single line) works, > while: > --add="BuySellArrows(Systems::Generic {Signals::Generic::CrossOverUp \ > {I:EMA 5 {I:Prices CLOSE}} {I:EMA 20 {I:Prices > CLOSE}}} \ > {Signals::Generic::CrossOverDown {I:EMA 5 {I:Prices > CLOSE}}\ > {I:EMA 20 {I:Prices CLOSE}}}, 10)" > does not and reports always the same error: > "BuySellArrows(Systems::Generic {Signals::Generic::CrossOverUp \ is not > a valid > object description at graphic.pl line 823. this is likely a problem with graphic.pl or the continuation line support subroutine -- the entire argument for BuySellArrows must be on a single line. but BuySellArrows doesn't support the trailing argument 10. that argument is most likely for the VotingLine display. to change BuySellArrows object attributes (colors, size, location) you have to use configuration key-values. the alternative (to the very lone line) is to define a system object alias say bsa_system, something like this (untested, unchecked and off the top of the head) Aliases::Systems::bsa_system { \ Systems::Generic \ { Signals::Generic::CrossOverUp \ {I:EMA 5 {I:Prices CLOSE}} {I:EMA 20 {I:Prices CLOSE}}} \ { Signals::Generic::CrossOverDown \ {I:EMA 5 {I:Prices CLOSE}} {I:EMA 20 {I:Prices CLOSE}}} and use it like this --add=BuySellArrows( @bsa_system, 10) the positional variables might also be used ... Aliases::Systems::bsa_system { \ Systems::Generic \ { Signals::Generic::CrossOverUp \ {I:EMA #1 {I:Prices CLOSE}} {I:EMA #2 {I:Prices CLOSE}}} \ { Signals::Generic::CrossOverDown \ {I:EMA #3 {I:Prices CLOSE}} {I:EMA #4 {I:Prices CLOSE}}} and use them like this --add=BuySellArrows( @SY:bsa_system 5 20 7 15, 10) aloha ras > > I tested also all the instructions suggested in the manual: > http://www.geniustrader.org/wiki/geniustrader:gtgraphs > and again they do not work on multiple lines. > > * strange behaviour with backtests (will report separately). > > Thanks again to all who responded and will respond with their Windows > and timeframe 1min experiences > > Gianni > > < big snip > |
|
From: Erik C. <ec...@ec...> - 2011-01-02 20:02:45
|
Hi Gianni !
Two comments on your post:
- Just be aware that the CPAN 0.50 doesn't integrate patches after somewhere late 2009. I'm also using this version ( well, I created it after all ;) ). The intention was to bring GeniusTrader to a broader community which by your example seems to have worked at least for 1 person ;)
- About Date::Manip. Probably you installed version 6. of Date::Manip. The interface is incompatible between version 5 and 6. So did you try one of these settings mentioned in the doc of Date::Manip ?
By setting the DATE_MANIP environment variable to 'DM5' before
running the perl script, the version 5 interface will be used.
Date::Manip::Backend VARIABLE
Alternately, you can set the Date::Manip::Backend variable to be
'DM5' before loading the module. Typically, this will be done in
the following way:
BEGIN {
$Date::Manip::Backend = 'DM5';
}
use Date::Manip;
Best
--
Erik Colson
|
|
From: Gianni76 <gia...@em...> - 2011-01-02 08:54:57
|
Hi all,
while still debugging backtest.pl I discovered the importance of the
Brokers section, which I had not considered.
The results below are still too buggy and needs checking (please someone
with a 'stable and verified' version of GT!), but in the meantime I have
written a small Brokers module, FixedCosts.pm, which might be of use for
some (and was surprised not to see immediately).
It is simply a module that calculates a fixed cost per trade (as it is
used by many brokers nowadays).
The fixed cost can be passed as a parameter, but the default is 5
euros/usd/whatever currency you use per trade.
Fell free to use it!
Gianni
On 01/01/2011 19.58, Gianni76 wrote:
> Dear all,
> While still trying to understand GeniusTrader inner workings, I have
> written a basic system which should trigger a long (buy) flag on the
> cross SMA 5 over SMA 10 and a short (sell) flag on the cross SMA 5
> down SMA 10.
> The system is always on the market and goes either long or short....
> Extremly simple just to verify if the version I have installed can be
> trusted!
>
> I seem not to have things working properly with backtest.pl
>
> I have shown this on a graph and it seems ok:
>
> perl graphic.pl --timeframe=1min --add="BuySellArrows(Systems::Generic
> {Signals::Generic::CrossOverUp {I:EMA 5 {I:Prices CLOSE}} {I:EMA 20
> {I:Prices CLOSE}}} {Signals::Generic::CrossOverDown {I:EMA 5 {I:Prices
> CLOSE}} {I:EMA 20 {I:Prices CLOSE}}}, 10)" --add="Curve( I:EMA 5,
> [140, 70, 20])" --add="Curve( I:EMA 10, [0, 0, 255])" fiat1mr2
> >grabak6d.png
>
> (displayed only the last few samples...in the attached grabak6d.png
> plotting it all with -start and -end takes really a long long time).
>
> I would like your help in trying to debug a problem with the backtest.pl.
> I tested that simple system with the fiatmr2 (1min) data (attached in
> the zip)...
>
> The call is:
> perl backtest.pl --timeframe=1min --html --graph="g3.png" "SY:Generic
> {S:Generic:CrossOverUp {I:SMA 5 {I:Prices CLOSE}} {I:SMA 10
> {I:Prices CLOSE}}} {S:Generic:CrossOverDown {I:SMA 5 {I:Prices CLOSE}}
> {I:SMA 10 {I:Prices CLOSE}}}| TF:OneTrade| CS:OppositeSignal" fiat1mr2
> > bak7.html
>
> I attach the resulting g3.png and bak7.html.
>
> Questions:
> a) is the equity (green) line I see real? Can anyone reproduce it and
> confirm?
> It looks strange to have such a bad behaviour from such a simple
> moving average system...
> (I tried also other systems and all the equities are rubbish...).
>
> b) Some of the 'numbers' that should appear on the table are strange
> characters, like erformance : -100.1 ( -1.$%) in the performance, or
> Expectancy : -1.#J etc.
> What is this due to?
>
> c) Does anyone have any 'trusted' simply long/short system that I can
> test with 'backtest.pl'? I have tested so many different variations of
> GT that I am puzzled if I did something wrong in the settings in this
> current version...
>
> d) in the real report I get strange results.
> For example the first row is:
> 0 fiat1mr2 Short 1022 2010-08-02 09:14:00 9.7800
> 2010-08-02 09:25:00 9.7700 -0.70% 0.00763888888888889
>
> i.e. enter short at 9.78 and exit at 9.77. This to me is a gain of
> +0.1%. Why is the row red (i.e. presming a loss) and indicating a
> return of -0.70%?
>
> Second row:
> 1 fiat1mr2 Long 1021 2010-08-02 09:25:00 9.7700
> 2010-08-02 09:35:00 9.7850 -0.65% 0.00694444444444444
>
> enter long at 9.77 and exit at 9.785. Again this should be a gain
> (green and not red!).
> Instead the return stays at -0.65%
>
> What is going on?
>
> g.
|
|
From: Gianni76 <gia...@em...> - 2011-01-01 18:01:44
|
Dear Robert and all, thank you for your tests and suggestions. I have done really a lot more in the last few days and have come to these conclusions to my original quest: - The best version of GeniusTrader to start with in Windows (for timeframes=1min) is at present the CPAN Finance::GeniusTrader. (I installed v.0.50) This version is the most compatible with the different command and options for graphics and testing. It is the only one that has not broken up or gave me strange errors with same cases. For larger timeframes I would suggest the nice Chia-liang Kao 'cpan-pu' version, which contains some speed-ups and general improvements. to install them on windows, just dezip/detar the package in a directory 8for example called gt05), go into that directory and write perl Makefile.PL nmake test nmake install (if you have a problem/error due to a missing nmake, go and download it here: http://download.microsoft.com/download/vc15/Patch/1.52/W95/EN-US/Nmake15.exe and place it in your perl/bin directory with the name nmake.exe) - I still don't see what is/could be the problem connected with absolute times. Robert, you asked me what is the best way to deal with local times of different stocks. To me time is simply a label and as such should always remain in local hours, e.g. when I deal with Italian stock I get them at my local time in Italy (db populated from 9 to 17.30 in the main session + after hours from 18 - 20.30). When I deal with US stock, the time is from 15 to 22.30 etc. (again what is recorded in the stock logs is my local italian time and not the usa or gmt time). - issues still not solved: * Date::Manip (even if this is installed in my Perl distribution), is not working properly with GT calls under Windows, so I had to comment out the #check_dates($timeframe, $start, $end) in graphic.pl to make things work. * I could not get any version to accept multiline commands (e.g. something like: --add=BuySellArrows( Systems::Generic {Signals::Generic::CrossOverUp {I:EMA 5 {I:Prices CLOSE}} {I:EMA 20 {I:Prices CLOSE}}} {Signals::Generic::CrossOverDown {I:EMA 5 {I:Prices CLOSE}} {I:EMA 20 {I:Prices CLOSE}}} , 10) 8all in a single line) works, while: --add="BuySellArrows(Systems::Generic {Signals::Generic::CrossOverUp \ {I:EMA 5 {I:Prices CLOSE}} {I:EMA 20 {I:Prices CLOSE}}} \ {Signals::Generic::CrossOverDown {I:EMA 5 {I:Prices CLOSE}}\ {I:EMA 20 {I:Prices CLOSE}}}, 10)" does not and reports always the same error: "BuySellArrows(Systems::Generic {Signals::Generic::CrossOverUp \ is not a valid object description at graphic.pl line 823. I tested also all the instructions suggested in the manual: http://www.geniustrader.org/wiki/geniustrader:gtgraphs and again they do not work on multiple lines. * strange behaviour with backtests (will report separately). Thanks again to all who responded and will respond with their Windows and timeframe 1min experiences Gianni On 26/12/2010 5.40, Robert A. Schmied wrote: > Gianni76 wrote: >> > i am backing away from the statement below: >>> after doing a lot of checking and thinking and more checking >>> the bottom line, i'm afraid, is that gt is currently unsuited >>> for your expressed need to trigger buys or sells on an intraday >>> basis: as far as i can tell the intraday stuff was added as an >>> add-on to the basic design and it was never accounted for in >>> the context of a trading system. what this means is that the >>> trading system signals are processed at the next days open. > see the reason why at the very bottom ... > > this reply is chronological based on analysis i've done serially > to reach the results reported in this summary. see the details of > how i arrived here below. > > but in summary: > * gt trading-systems will operate on intraday timeframes > * not all gt script apps work correctly with intraday timeframes > * time-zone consideration might be needed to correctly handle > multi-timezone prices data streams > * gianni -- you might be in an ideal position to respond to this > question: > how to international financial businesses handle time-stamps > when across time-zones? > * display_signal.pl might the be best available script for you > to work with, but the output format probably isn't ideal for > your purposes. > > > i've rolled all the miscellaneous files into a tarball > (humm, maybe a zipfile is better for the windozers ;-) out there) > gianni_analysis.zip to simplify attaching and compressing ... > it doesn't have the aug 1m database but the sed command i used > to create it is in this email or in one of the files in the zf. > > lastly and more trivially i think your primary problem was with > the system you defined -- the one below is the correction -- more > details are in the file /tmp/gianni.scan -- grep for 'ahh! i think i > see the problem' > > --add=VotingLine( SY:G \ > { S:G:And \ > {S:G:Increase {I:Prices CLOSE} } \ > {S:G:CrossOverDown {I:SMA 5} {I:SMA 20} } \ > {S:G:Decrease {I:ADX} } \ > {S:G:Below {I:Prices} {I:EMA 30} } \ > {S:G:Below {I:Prices} {I:EMA 150} } \ > } \ > { S:G:And \ > {S:G:Decrease {I:Prices CLOSE} } \ > {S:G:CrossOverUp {I:SMA 5} {I:SMA 20} } \ > {S:G:Increase {I:ADX} } \ > {S:G:Above {I:Prices} {I:EMA 30} } \ > {S:G:Above {I:Prices} {I:EMA 150} } \ > } \ > , 10) > > and i ran into trouble getting all the days 1min bars onto a single plot. > i tried many variations of date and time string without get the image > (/tmp/FIAT_13aug10_fix.png) to change any > % graphic.pl --file /tmp/frank_scan1_fixed.gconf \ > -timeframe 1min --start '13aug2010 09:00:00' --end '13aug2010 > 16:00:00' \ > --out /tmp/FIAT_13aug10_fix.png FIAT1M_AUG2010 > > then looking harder i noticed the price data and the bar plots don't > appear to be matching up. what is happening is still unknown at this > point. > > end summary -- i really want to get this posted so others can review and > comment or expand on it. > > > > aloha > > merry christmas > > ras > > >> >> >> I don't know GT well enough, but for what concerns all other trading >> programs I know of, they use the concept of 'period' or 'candle' very >> generically and not in absolute terms. >> This means that if you feed them 30 lines of 1min or 30 lines of 1 >> day nothing will change in the logic behind the calculations... >> They will process things link EMA (30) on the last 30 data available >> (and if it is 30 samples taken at 1min intervals or 30 samples taken >> at 1day intervals or 30 samples taken at 1 week intervals nothing >> changes at all!!).... > > i guess a way to empirically determine if the next trading period can > be in the sub-day realm would be to set up a simple system and run it > on backtest.pl. the alternate would be to see if buysellarrows or even > a votingline plot would indicate intraday buy-sell signals, but keep in > mind the way a gt trading-system functions -- the initial 'systems' > signals > are only opportunities to open a position, the managers, the filters and > the orderfactory determine if (and probably when) the position will > actually > be taken, finally once a new position is taken the closestragy(ies) > define > the signals that ultimately close or otherwise adjust the position. > > now armed with lots of real intraday data i will start to ponder how one > might be able to evaluate if intraday trading can work with gt. > > a simple, but complete trading system might look something like this: > > note this is off the top of my head, so it may be incomplete or simply > wrong > > SY:G \ > { S:G:CrossOverUp {I:SMA 30} {I:SMA 100} } \ > { S:G:CrossOverDown {I:SMA 30} {I:SMA 100} } \ > | OF:MarketPrice \ > | TF:OneTrade \ > | TF:LongOnly \ > | MM:Basic \ > | CS:OppositeSignal \ > > >> So if you trigger a buy (just to make a simple example) on the cross >> EMA(5) >EMA(30) they will check the EMA value of the last 5 samples, >> the ema value of the last 30 samples and make the numeric comparison, >> without ever worry about the absolute time (which is just a label on >> a graph or maybe a temporal filter for a trade/no trade precondition, >> but not much more...). >> This is what I thought GT was doing as well. >> >> And if the logic is like this, there is no problem in getting my >> BUY/SELL signals intraday. >> It means that each signal will come at the OPEN of the next candle >> (which, if a feed 1min data, will be at the open of the next min), as >> happens with all programs triggering buy/sell signals.... (I am not >> sure why you talk about opening of the next day... GT should simply >> process last xx data depending on the requested functions and >> regardless of absolute time!!!). >> >> Who added the intraday patches? >> he must have an answer to this question about the logic in GT... > > well, that would be 'a lot of people, over a long period of time', > they just sort of evolved and became part of the code body. > >> >> >>> >>> note that the signals themselves might be indicated at the appropriate >>> intraday time, but the trading system controller (don't know if it is >>> OrderFactory, SystemManager, PortfolioManager, or something else) >>> would need to pass the signal immediately and not wait for the >>> next days open to see if the designated trade can be made or not. >> >> >> See above, my thinking is about a logic divided in 'periods' or >> 'candles'. > > right -- i think of them as bars (like much of the technical analysis > literature calls them, and i think most of the easylanguage codes too). > for the most part in gt they are the current timeframe. > >> The logic controller has to process the last x data (say the last 30 >> 1min candles if we want the EMA30) and pass out the result at the >> open of the following candle. >> This means that in absolute terms the processing is done in batches >> corresponding to the timeframe period. >> So if I have a 1min timeframe the answer should come at the open of >> the next period/candle (which means the max delay is 1min). >> I think that any logic trigger needs to be based on the selected >> timeframe and not on the basis of 'absolute time' (i.e. next day) as >> you mention. >> (this means that if you set a timeframe 1min, the answer should be >> delayed 1min max; but also that if you select a timeframe of a week, >> the processing should be done at the open of the next candle, which >> means the following week and not the following day....). >> >> Unless I totally misunderstood GT, the only rational conclusion is >> that it has to work on relative time-frames intervals, rather than >> absolute 1-day periods. >> But I would ask confirmation from those who wrote and studied the >> logic behind it.... >> > > gt trading systems involve a lot more logic than the simple presentation > you outline -- so if we put trading systems aside that leaves > indicators and > signals and those can do what you want. however, the only applications > that > use them are scan.pl and the display_signal.pl script. you might find > these > inadequate (or at least poorly suited) for your purpose, but you can > likely > design one or more scripts that do exactly what you want to do. > > > display_signal.pl can be configured to report only when a signal changes: > --change ( or -c ) > show on output only those dates that signal changed > > >>> in summary all the problems pointed out with respect to the intraday >>> timeframe data are confirmed in various different forms. the gt apps >>> all need to consider date and time fields when operating on sub-eod >>> timeframes. there also needs to be a way to set or specify how to >>> treat the time fields in the database: >>> i) do we assume local timezone applies? if not are times assumed >>> to be gmt(utc)? >>> ii) regardless can an offset be applied, and if so how is it >>> controlled and varied >>> iii) there has to be a 3rd ... >> >> >> Can anyone explain here the concept of a timezone in GT? > > the incorporation of Date::Manip likely introduced, or at least > highlighted the problems associated with price data streams especially > the time-stamp part. end-of-day and larger bars (timeframes) are > presumed to have time-stamp component of 00:00:00 if memory serves > (a better choice might have been 23:59:59). but note there isn't > an explicit time zone and presumably Date::Manip has some heuristic > that sets it appropriately. > > recognizing more aspects of the problem led me to try this command > on both my 'close to v_690 toolkit' and my very different toolkit: > > % display_indicator.pl -timeframe 1min --start '2010-09-03' --end > '2010-09-04' I:Prices fiat1m_3sep10 OPEN > > in each instance the data starts and ends with the correct bars. > > but there is still an issue when command is run without specific > time-stamp values > > % display_indicator.pl -timeframe 1min I:Prices fiat1m_3sep10 OPEN > |head -4 > Calculating indicator Prices[OPEN] ... > Prices[OPEN] [2010-09-03 15:21:00] = 10.0400 > Prices[OPEN] [2010-09-03 15:22:00] = 10.0400 > Prices[OPEN] [2010-09-03 15:23:00] = 10.0400 > > and my hack version > % display_indicator.pl -timeframe 1min I:Prices fiat1m_3sep10 OPEN > |head -4 > Indicator I:Prices has 1 value ... all values selected > I:Prices/1 <=> Prices[OPEN] > > timeframe 1min, time periods 372 .. 572 > Calculating indicator ... > Prices[OPEN] [2010-09-03 15:20:00] = 10.0400 > Prices[OPEN] [2010-09-03 15:21:00] = 10.0400 > Prices[OPEN] [2010-09-03 15:22:00] = 10.0400 > > for gt to be usable world-wide with intra-day time-stamped data > the time-stamp must either include the time-zone or the database > needs to be converted to gmt (universal coordinate time) when > stored or there needs to be a way to infor gt what the correct > time-zone value is for the data being used. > > in either case there will be the usual issues of day rollover > that need to be handled correctly for the data to retain it's > integrity. > > > so gianni -- based on your projects description i presume you are > in italy, that's likely gmt or maybe an hour earlier, so is your > fiat data your local time? > > i guess the large question is -- how to international financial > businesses handle time-stamps? however it is done in the financial > industry should be good enough for gt. > > >> >> Just to get back to simple steps to what I want to achieve as an >> absolute minimum (i.e. triggering of signals based on the knowledge >> of the last xx data...), at the end is "in simple terms" just a >> comparison of two (or more) mathematical functions. >> >> if (mathfunc 1> mathfunc 2) then triggerlong; >> if (mathfunc3> mathfunc4) then triggershort; > > you can do these operations with signals and indicators. > >> >> where mathfunc1,2,3,4 can be derived with simple use of the GT >> Indicators (without even using the scripts at all...). >> So any time issue is solved at root as the indicators are functions >> based on input samples, i.e. based on your own sampling time, which >> is the timeframe (and not depending on absolute times of end of day).... >> >> And in this case it would be quite easy to write a simple logic >> wrapper around the GT libraries. This wrapper takes xx data, >> calculates the long and short logic and passes out the related >> signals... > > > exactly! use the tool kit as the basis of your new application(s), > and where necessary add, correct and enhance the tool kit itself. > > please when making a change to an existing method or function keep the > api the same so the change doesn't ripple through the rest of the code. > if that isn't possible add a new method/function instead. also, try to > limit adding new prerequisites, when unavoidable try to wrap them in > a conditional so unless the new feature or capability is enabled the > user doesn't need to upgrade unless she is using the new feature. > > >> >> Of course the backtesting is a different matter as in that case the >> logic needs to execute the function check many times over sliding >> time-window where a time sample must correspond to a data sample (so >> if sampling is 1min then the processing has to be made minute after >> minute for all the period duration). >> >> I will try this simpler approach before getting down again in the >> nicer and more complex GT scripts... >> But would welcome any suggestions fro other users (or developers) of >> intraday data.... >> >> Thanks >> Gianni >> > > > messin' around with scan.pl and your 'systems' description: > # made a monthly fiat database of 1min data (sed -n > '/2010-08-[0-3][0-9]/p' /tmp/fiat1mr.txt > /tmp/fiat1m_aug2010.txt) > # made a multiple signal .scan file (/tmp/gianni.scan) > # made a market file (/tmp/gianni_market) with one line 'FIAT1M_AUG2010' > > command line > scan.pl --timeframe 1min /tmp/gianni_market 3aug2010 /tmp/gianni.scan > > > > noted problems -- a month of 1min data is still a huge amount, so i tried > to view the price action using graphic.pl with a 1 hour time frame > (hoping > gt would upshift the 1min data into 1 hour chunks -- it didn't. since it > works that way for an end-of-day database and week, month, year > timeframes > it really ought to do that for other smaller timeframes as well ... > > with these files and this command line i'm getting no errors, but no > signals > and unfortunately no signals, since scan.pl only works on a given > 'date' i'm > not sure it will actually work on that 'date' for all every timeframe and > without knowing when a signal should be true it is hard to determine what > dates to try. > > so it's time to switch to display_signal.pl ... bad (well more of a big > limitation) thing is the display_*.pl apps don't read a file containing a > the sys-sig-indic description, so you have to somehow get it onto the > command > line with all the correct quoting and/or special char escapes. > > i generally resort to entering the command in an editor window and > cut+paste > it to a terminal just to keep my sanity, you may find a different method > > but here's the file i developed (/tmp/gianni_ds_cmds) for use with the > csh, > but it would work cut+paste wise just fine with bash as well > > > based on this effort i've found a few intraday 'go long' signals: > [2010-08-02 09:02:00] = yes > [2010-08-02 09:04:00] = yes > [2010-08-02 09:07:00] = yes > [2010-08-02 09:11:00] = yes > [2010-08-02 09:15:00] = yes > [2010-08-02 09:19:00] = yes > [2010-08-02 10:03:00] = yes > [2010-08-09 14:23:00] = yes > [2010-08-11 14:51:00] = yes > [2010-08-11 15:58:00] = yes > [2010-08-11 16:04:00] = yes > [2010-08-12 14:12:00] = yes > [2010-08-13 11:26:00] = yes > [2010-08-13 12:37:00] = yes > [2010-08-13 14:14:00] = yes > [2010-08-16 12:12:00] = yes > [2010-08-16 14:44:00] = yes > [2010-08-19 10:10:00] = yes > [2010-08-19 15:00:00] = yes > [2010-08-19 15:32:00] = yes > [2010-08-19 15:51:00] = yes > [2010-08-19 16:54:00] = yes > [2010-08-20 10:08:00] = yes > [2010-08-20 15:50:00] = yes > [2010-08-23 18:03:00] = yes > [2010-08-24 15:18:00] = yes > [2010-08-25 15:45:00] = yes > > > i'm going to discount all for 2 aug and start evaluating with scan.pl > for each of these dates: 2010-08-09, 2010-08-11, 2010-08-12, 2010-08-13, > 2010-08-16, 2010-08-19, 2010-08-20, 2010-08-23, 2010-08-24 and 2010-08-25 > > > > something like: for d in 09 11 12 13 16 19 20 23 24 25; do > echo "working 2010-08-${d}" > scan.pl --timeframe 1min --start '2aug2010 09:00:00' --end '27aug2010 > 17:24:00' /tmp/gianni_market 2010-08-${d} /tmp/gianni.scan > echo "done" > done > > unfortunately something seems amiss -- using scan.pl no signals are > reported > -- it is likely scan.pl doesn't have the intraday smarts needed > > == during my review before sending it occured to me that scan.pl > probably > == wants/expects the <date> field to be the same as the --end value > == --- something to look at anyway. > > > > so far display_signal.pl seems to be the best existing tool for the task > you want done ... > > > > > > the next big hurdle is to see how backtest.pl operates with this > dataset and > these signals ... > > > ./backtest.pl <options> { "<full_system_name>" | individual tradesys > components } <code> > <options> > --start '2aug2010 09:00:00' > --end '27aug2010 17:24:00' > --graph="/tmp/bt_fiat_sys.png" > --dt > --store="/tmp/gianni_pf.xml" > --timeframe=1min > { "<full_system_name>" | individual tradesys components } > for now lets keep it simple and define individual tradesys components > --system ... > --money-management ... > --trade-filter ... > --order-factory ... > --close-strategy ... > <code> FIAT1M_AUG2010 > > > so again with a command cut+paste file (see file /tmp/gianni_bt_cmds) > > > > well well -- with the 'similar to v_690 toolkit' i'm getting > trades with this trading system ... > > ## Analysis of SY:Generic {S:G:And {S:G:Increase {I:Prices CLOSE}} > {S:G:CrossOverDown {I:SMA 5 {I:Prices CLOSE}} {I:SMA 20 {I:Prices > CLOSE}}} {S:G:Decrease {I:ADX 14 {I:Prices HIGH} {I:Prices LOW} > {I:Prices CLOSE}}} {S:G:Below {I:Prices } {I:EMA 30 {I:Prices CLOSE}}} > {S:G:Below {I:Prices } {I:EMA 130 {I:Prices CLOSE}}}} {S:G:And > {S:G:Decrease {I:Prices CLOSE}} {S:G:CrossOverUp {I:SMA 5 {I:Prices > CLOSE}} {I:SMA 20 {I:Prices CLOSE}}} {S:G:Increase {I:ADX 14 {I:Prices > HIGH} {I:Prices LOW} {I:Prices CLOSE}}} {S:G:Above {I:Prices } {I:EMA > 30 {I:Prices CLOSE}}} {S:G:Above {I:Prices } {I:EMA 150 {I:Prices > CLOSE}}}}|OF:MarketPrice |TF:OneTrade |TF:LongOnly |CS:OppositeSignal > |MM:Basic > History of the portfolio : > -------------------------- > Long position (0) on FIAT1M_AUG2010 > 2010-08-02 Buy 1023 at 9.7800 > 2010-08-02 Sell 1023 at 9.7750 > Long position (1) on FIAT1M_AUG2010 > 2010-08-02 Buy 1014 at 9.7750 > 2010-08-02 Sell 1014 at 9.8150 > Long position (2) on FIAT1M_AUG2010 > 2010-08-02 Buy 1006 at 9.8150 > 2010-08-02 Sell 1006 at 9.8000 > Long position (3) on FIAT1M_AUG2010 > 2010-08-02 Buy 1000 at 9.7850 > 2010-08-02 Sell 1000 at 9.7700 > Long position (4) on FIAT1M_AUG2010 > 2010-08-02 Buy 992 at 9.7650 > 2010-08-05 Sell 992 at 10.3100 > Long position (5) on FIAT1M_AUG2010 > 2010-08-11 Buy 1041 at 9.7450 > 2010-08-17 Sell 1041 at 9.6350 > Long position (6) on FIAT1M_AUG2010 > 2010-08-19 Buy 1016 at 9.7900 > 2010-08-26 Sell 1016 at 9.2200 > ## Global analysis (full portfolio always invested) > Analysis of the portfolio (2010-08-02 09:00:00 / 2010-08-26 20:27:00) : > ----------------------------------------------------- > Performance : -7.0% (-58.6%) Buy & Hold : -5.5% (-50.0%) () => > by year > MaxDrawDown : 8.4% B&H MaxDrawDown : 14.8% > Best performance : 1.5% Worst performance : -7.0% > Net gain : -698.47 Gross gain : -147.63 > > Trades statistics : > Number of trades : 7 Trades/Year : 104.45 > Number of gains : 1 Number of losses : 6 Win. ratio : > 14.3% > Max consec. win : 1 Max consec. loss : 4 Expectancy : > -0.01 > Average gain : 4.76% Average loss : -1.96% Avg. perf : > -1.03% > Biggest gain : 4.76% Biggest loss : -6.58% Profit fac : > 2.42 > Sum of gains : 461.15 Sum of losses : -1159.62 Risk of ruin : > 100.0 > > the graphic trades file (/tmp/bt_fiat_sys_svn.png) > > (well the v_690 backtest graphics are for crap -- the one from my version > marks the long and short (green and red) and the holding periods inside > |> ... <| marks, plus it plots price bars so you can get a visual > indication > of what the trading system and closestrategies are doing ... > > > > > > my toolkit and backtest version isn't using the Date::Manip date > processing so i need to tweak the date strings to comply with the > defacto 'YYYY-MM-DD\ hh:mm:ss' standard (maybe the timestamp is valid) > yes ! it appears so my report differs slightly: > ## > ## Analysis of code FIAT1M_AUG2010 using System Spec > > SY:Generic {S:G:And {S:G:Increase {I:Prices CLOSE }} > {S:G:CrossOverDown {I:SMA 5 {I:Prices CLOSE }} {I:SMA 20 {I:Prices > CLOSE }}} > {S:G:Decrease {I:ADX 14 {I:Prices HIGH } {I:Prices LOW } {I:Prices > CLOSE }}} > {S:G:Below {I:Prices } {I:EMA 30 {I:Prices CLOSE }}} {S:G:Below > {I:Prices } > {I:EMA 130 {I:Prices CLOSE }}}} {S:G:And {S:G:Decrease {I:Prices CLOSE }} > {S:G:CrossOverUp {I:SMA 5 {I:Prices CLOSE }} {I:SMA 20 {I:Prices CLOSE > }}} > {S:G:Increase {I:ADX 14 {I:Prices HIGH } {I:Prices LOW } {I:Prices > CLOSE }}} > {S:G:Above {I:Prices } {I:EMA 30 {I:Prices CLOSE }}} {S:G:Above > {I:Prices } > {I:EMA 150 {I:Prices CLOSE }}}} | OF:MarketPrice | TF:OneTrade | > TF:LongOnly | CS:OppositeSignal | MM:Basic > > History of the portfolio : > -------------------------- > Long position (0) on FIAT1M_AUG2010 > 2010-08-02 Buy 1023 at 9.7800 > 2010-08-02 Sell 1023 at 9.7750 > Long position (1) on FIAT1M_AUG2010 > 2010-08-02 Buy 1014 at 9.7750 > 2010-08-02 Sell 1014 at 9.8150 > Long position (2) on FIAT1M_AUG2010 > 2010-08-02 Buy 1006 at 9.8150 > 2010-08-02 Sell 1006 at 9.8000 > Long position (3) on FIAT1M_AUG2010 > 2010-08-02 Buy 1000 at 9.7850 > 2010-08-02 Sell 1000 at 9.7700 > Long position (4) on FIAT1M_AUG2010 > 2010-08-02 Buy 992 at 9.7650 > 2010-08-03 Sell 992 at 10.1100 > Long position (5) on FIAT1M_AUG2010 > 2010-08-11 Buy 1021 at 9.7450 > 2010-08-16 Sell 1021 at 9.5350 > Long position (6) on FIAT1M_AUG2010 > 2010-08-19 Buy 987 at 9.7800 > 2010-08-19 Sell 987 at 9.8200 > Long position (7) on FIAT1M_AUG2010 > 2010-08-19 Buy 982 at 9.7900 > 2010-08-20 Sell 982 at 9.3950 > Long position (8) on FIAT1M_AUG2010 > 2010-08-24 Buy 999 at 9.1800 > 2010-08-25 Sell 999 at 9.0950 > Long position (9) on FIAT1M_AUG2010 > 2010-08-27 Buy 986 at 9.1500 > 2010-08-27 Sell 986 at 9.3400 > > ## Global analysis (full portfolio always invested) > Analysis of the portfolio (2010-08-02 09:00:00 / 2010-08-27 17:24:00) > ----------------------------------------------------- > Performance : -8.7% (-66.7%) Buy & Hold : 95.7% (338124) () => > by year > MaxDrawDown : 9.9% B&H MaxDrawDown : 14.8% > Best performance : 0.0% Worst performance : -9.9% > Net gain : -868.63 Gross gain : -112.80 > > Trades statistics > Number of trades : 10 Trades/Year : 144.08 > Number of gains : 2 Number of losses : 8 Win. ratio : > 20.0% > Max consec. win : 1 Max consec. loss : 4 Expectancy : > -0.01 > Average gain : 2.02% Average loss : -1.62% Avg. perf : > -0.90% > Biggest gain : 2.73% Biggest loss : -4.79% Profit fac : > 1.24 > Sum of gains : 383.02 Sum of losses : -1251.65 Risk of ruin : > 100.0 > > portfolio performance graph at "/tmp/bt_fiat_sys_rh.png" > > > > > so in summary: > a) i'm incorrect in thinking that gt will only make trades > at the next days open, i've been able to show otherwise. > b) there are problems with some gt apps when using > intraday data streams, scan.pl being one of them > and graphic.pl maybe also ... > c) dunno' but there's always a third. > > |
54 messages has been excluded from this view by a project administrator.
