|
PureBytes Links
Trading Reference Links
|
Hi Terry!
First, thank you very much for the suggestion list.
>1] I have already mentioned the option of having the company name as well
>as/instead of the ticker symbol in the ticker selection window, but it
>ocurred to me that it might be possible to put the company name on the
>chart title bar(s) instead of in the stock selector window. The chart
>title bars already show the ticker symbol on them, so it may be possible
>to display the company name there as well, rather than putting it in the
>selector window. This would be just as helpful to people like me, who have
>a hard time remembering just which stock XYZ refers to, particularly when
>you have close to 3000 tickers in your database like me, and a poor memory
>like me :-(
OK, no problem, I will add the setting to the prefs which will enable you to
select the way of displaying
stocks in the selection window.
>2] The toolbar is the only window which does not have a resize gadget on
>it, and on my screen (800x600 on a 15" monitor) there is about a
>centimeter or so of wasted space between the toolbar and the price chart.
>It would be nice to be able to widen the toolbar to eliminate the wasted
>space, or even better, have another row of tools fitted into the space!!
OK, There will be a sizing gadget for the toolbar.
>3] It is already possible to click on a particular day in the stock price
>window to bring up a vertical line along that day's data, but would it be
>possible to extend that vertical line down through any other charts which
>are open on the workspace at the time, so that we can get a better direct
>comparison with all the data on all the charts at the same time? My
>50-year old eyes are not perfect, and I feel pretty stupid sitting here
>with a plastic ruler held up to the screen to compare the data on
>different charts :-)
Yes, I know that problem. Many users asked for that, and I just have to
implement it.
It would be an easy one if all the chart windows had the same width.
"Unfortunatelly" you can resize each chart window
so co-ordinates calculation must be done separately for each of them. This
will slow down the thing a little bit,
but I may make this feature switchable.
>
>4] You have already mentioned the possibility of implementing Gann and
>Fibonacci lines in the next version, but would it be possible to have the
>option of implementing a time line set by the user as well? I have been
>told that our (Australian) main index, the All Ordinaries Index, normally
>turns on multiples of 90 calendar days, so it would be good to have the
>option of setting time lines each 90 days, for example, to warn me of this
>possible turning point. I am sure that this would be a valuable option for
>other people as well. Incidentally, this 90-day turning cycle compares
>pretty well with the Fibonacci timelines, which use a timeline at 89 days.
The things connected with timelines will probably wait for the version after
3.0.
But probably you won't wait too long.
>5] More speed!!! Even on my system, an 030/50 with FPU and 40 mb of fast
> [.....]
Two main factors that determine data loading time are:
a) raw disk read speed
b) time spent on memory allocations
AmigaDOS file system is quite slow in both handling large amounts of files
(>100 in single dir)
and the files with large sizes (>1MB).
You can attest it by copying all your data files from one directory to
another using AmigaDOS COPY command.
You will see that simple copying (without any processing) takes a lot of
time (comparable to the time needed for AmiBroker to
load them)
When loading the data, AmiBroker reads the datafile using single Read()
operation per file (the buffer size
is set to the file length) using FULL AmigaDOS data bandwidth. There is NO
WAY to speed it up (from the AB side) since it is
completely OS dependent. You can improve the thing using SCSI drive or other
file system (AFS for example).
Second factor (time spent on memory allocations) is responsible for about
15-30% of the whole loading time (it depends on
processor speed). AmiBroker handles its data through system-supported
double-linked lists so it needs to allocate memory
for every list node (which represents single quotation) - this means: quite
often. This part is quite optimized but there is
a space for small further optimizations but do not expect something
revolutionary.
Currently AmiBroker loads the whole database into memory to enable you to
work fast later. The other approach is to load
only single stock's data at a time (this is the way the Metastock works).
Doing so , however, will extremely degrade program
response time, since with every stock change it will be forced to load data
(and eventually save previously changed data).
Speaking about saving - you are right AmiBroker saves all database even if
only one stock's data is changed and this
is not optimal. It was done in such a way just because you most often update
all your stocks with current day quotations
so in this case AmiBroker must save everything anyway.
Moreover it would not give you any speed increase if AmiBroker tried to
append only changed data to existing file beacuse
AmigaDOS handles this operation slowly.
If I have some more time I will implement some more intelligent solution
(which is already in my mind) that will overcome
most of the problems mentioned here.
>Tomasz, your work IS appreciated, even if we do not tell you often
>enough!!
Thank you. I appreciate your feedback.
All user suggestions are always considered seriously and help making
AmiBroker even better.
Best regards,
Tomasz Janeczko
____________________________________________________________
List Site: http://www.findmail.com/list/amibroker/
To unsubscribe, send to amibroker-unsubscribe@xxxx
FREE group e-mail lists at http://www.findmail.com
|