Pharo-users
By thread
pharo-users@lists.pharo.org
By month
Messages by month
- ----- 2026 -----
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2025 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2024 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2023 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2022 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2021 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2020 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2019 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2018 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2017 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2016 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2015 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2014 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2013 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2012 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2011 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2010 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- 2 participants
- 50347 messages
Re: [Pharo-users] Thinking aloud about project at hand
by Tim Mackinnon
Wasnât there a recent financial app in Pharo that was made open source... there might be many ideas in it, and possibly a starting point.
Itâs in the success pages of pharo: Quuve, there are posts from Mariano about what tech they used too
Tim
> On 10 Apr 2020, at 09:13, "tesonep(a)gmail.com" <tesonep(a)gmail.com> wrote:
>
> Hi Tomaz,
>
> From the comments about the requirements you do I suggest:
>
> - For data storage, my recommendation goes depending on two factors:
> 1)Installation complexity, 2) volume of data. These are two variables
> that will be against one and the other. I will recommend to use
> MongoDB + Voyage, that goes very well. It grows excellent with the
> amount of data, it has really cool integration with Pharo and Voyage
> is an excellent mapping tool; also it is a mature solution and it has
> a lot of support for back-up schemes and solutions. Using MongoDB
> complicates the installation process, so if you have the idea of a
> easy installable application maybe SQLlite is a good alternative.
>
> - I think using Spec2 + GTK + Roassal3 + Polymath is a good idea.
> Check that Spec2 and Roassal3 are still under heavy development. They
> are getting much better, but of course, it will take some time to
> stabilize; but both of them are progressing very fast and they are
> already quite stable.
>
> - For developing DSL and interactive programming for non-programmers
> users, Pharo is ideal. It presents a lot of tools to easily develop
> DSL and the UI to make them work excellent. The idea of live
> manipulation of objects and inspection of all the instances can be
> easily added to a DSL.
>
> Thanks for your attention!
>
>> On Thu, Apr 9, 2020 at 9:13 PM Tomaž Turk <tomaz.turk(a)ef.uni-lj.si> wrote:
>>
>> Dear all,
>>
>> I'm thinking about implementing a software solution in Pharo (as one of the candidate environments), it's a project that I'm dealing with professionally. The goal is to develop a financial planning/simulation application on the country level, which is at present developed as a set of interrelated Excel spreadsheets. The requirement is that the solution should be more "manageable", resilient and straightforward than Excel permits, that it should present a workflow to the user - i.e. , that the tasks the user should do are suggested through the GUI.
>>
>> The majority of the data is in a form of a time series (for instance: GDP for a series of years). There are many variables in the model which shoud be calculated from other variables, year by year. There are also lagged variables (the value for the current year depends from the value of previous year), and running averages. There are also some variables which are not time series (parameters). As a part of GUI, there is a need to present the results as diagrams, too (scatterplots, line charts), otherwise tables are the output.
>>
>> I found Pharo to be a very elegant language and environment, with version 8.0 it became pretty stable, however I don't have any experiences in building software solutions of this type in Smalltalk. In other words, I'd like to be more confident in setting the architecture, both in the sense of the model content (variables interrelation) and the architecture of classes. Besides, for the calculated variables I'd like to have a relatively simple syntax to define them (like 'GDPpC <- GDP / Population').
>>
>> My thoughts and questions:
>> - for easier maintenance I'd like to separate the data from the code - so the question is what would be the best way to implement persistence (another Pharo image - with what?, some relational database, XML/JSON, flat files ...)
>> - I wonder what would be the best "architecture" of classes - so, we have a lot of aggregate variables like GDP and population, which can be grouped at least according to the stage in the planning workflow. There are also resulting (calculated) variables (e.g. GDP per capita). On the other hand, since this is a planning software, it's a kind of simulation, where we have a "data warehouse", experiments and results
>> - As a core packages I would use Spec2, Roassal, and PolyMath.
>>
>> I'm just thinking aloud, and would greatly appreciate any thoughts from experienced Pharoers :-)
>>
>> Best wishes,
>> Tomaz
>
>
>
> --
> Pablo Tesone.
> tesonep(a)gmail.com
>
April 10, 2020
Re: [Pharo-users] Thinking aloud about project at hand
by tesonep@gmail.com
Hi Tomaz,
>From the comments about the requirements you do I suggest:
- For data storage, my recommendation goes depending on two factors:
1)Installation complexity, 2) volume of data. These are two variables
that will be against one and the other. I will recommend to use
MongoDB + Voyage, that goes very well. It grows excellent with the
amount of data, it has really cool integration with Pharo and Voyage
is an excellent mapping tool; also it is a mature solution and it has
a lot of support for back-up schemes and solutions. Using MongoDB
complicates the installation process, so if you have the idea of a
easy installable application maybe SQLlite is a good alternative.
- I think using Spec2 + GTK + Roassal3 + Polymath is a good idea.
Check that Spec2 and Roassal3 are still under heavy development. They
are getting much better, but of course, it will take some time to
stabilize; but both of them are progressing very fast and they are
already quite stable.
- For developing DSL and interactive programming for non-programmers
users, Pharo is ideal. It presents a lot of tools to easily develop
DSL and the UI to make them work excellent. The idea of live
manipulation of objects and inspection of all the instances can be
easily added to a DSL.
Thanks for your attention!
On Thu, Apr 9, 2020 at 9:13 PM Tomaž Turk <tomaz.turk(a)ef.uni-lj.si> wrote:
>
> Dear all,
>
> I'm thinking about implementing a software solution in Pharo (as one of the candidate environments), it's a project that I'm dealing with professionally. The goal is to develop a financial planning/simulation application on the country level, which is at present developed as a set of interrelated Excel spreadsheets. The requirement is that the solution should be more "manageable", resilient and straightforward than Excel permits, that it should present a workflow to the user - i.e. , that the tasks the user should do are suggested through the GUI.
>
> The majority of the data is in a form of a time series (for instance: GDP for a series of years). There are many variables in the model which shoud be calculated from other variables, year by year. There are also lagged variables (the value for the current year depends from the value of previous year), and running averages. There are also some variables which are not time series (parameters). As a part of GUI, there is a need to present the results as diagrams, too (scatterplots, line charts), otherwise tables are the output.
>
> I found Pharo to be a very elegant language and environment, with version 8.0 it became pretty stable, however I don't have any experiences in building software solutions of this type in Smalltalk. In other words, I'd like to be more confident in setting the architecture, both in the sense of the model content (variables interrelation) and the architecture of classes. Besides, for the calculated variables I'd like to have a relatively simple syntax to define them (like 'GDPpC <- GDP / Population').
>
> My thoughts and questions:
> - for easier maintenance I'd like to separate the data from the code - so the question is what would be the best way to implement persistence (another Pharo image - with what?, some relational database, XML/JSON, flat files ...)
> - I wonder what would be the best "architecture" of classes - so, we have a lot of aggregate variables like GDP and population, which can be grouped at least according to the stage in the planning workflow. There are also resulting (calculated) variables (e.g. GDP per capita). On the other hand, since this is a planning software, it's a kind of simulation, where we have a "data warehouse", experiments and results
> - As a core packages I would use Spec2, Roassal, and PolyMath.
>
> I'm just thinking aloud, and would greatly appreciate any thoughts from experienced Pharoers :-)
>
> Best wishes,
> Tomaz
--
Pablo Tesone.
tesonep(a)gmail.com
April 10, 2020
Re: [Pharo-users] Moving/rolling average implementations ?
by Cédrick Béler
Superb, thank you Richard, very interesting answer :)
For the rounding issue, since I got bitten once, I most of the time use ScaleDecimal instead of floats for data anyway.
Cheers,
Cédrick
> Le 10 avr. 2020 à 05:04, Richard O'Keefe <raoknz(a)gmail.com> a écrit :
>
> Let's take the inheritance issue first.
> Yes, Collection has some subclasses where #average makes no sense,
> such as String. If any subclass of Collection should have #average, it is
> Array, as #(1 2 3 4) average makes perfect sense.
> BUT #($a $b $c $d) average makes exactly as much sense as 'abcd' average.
> So we have
> - subclasses where a method never makes sense (String)
> - subclasses where a method always makes sense (ByteArray)
> - subclasses where a method may or may not make sense (Array).
> Traits will not help at all with the third category.
> Historic Smalltalk practice has been to define methods like
> String>>average self shouldNotImplement.
> to "cancel" inappropriate methods to deal with the "never" subclasses,
> but that still does not help with the "maybe" ones.
>
> In my own code I try very hard to ensure that a method is available in
> a class if and only if the class can have instances where the method
> makes sense. That is, I try to make sure that #respondsTo: is "honest".
> It is not always practical.
>
> This is not a problem that is peculiar to Smalltalk. Java and C# and C++
> and you-name-it also have the "maybe" problem, where a method seems
> to be available for an object but thanks to its state it is not.
>
> As long as sending a message to an inappropriate object (whether due to
> its class or its state) results in *some* exception, do we really have a problem?
> 'abcd' average
> 'abcd' asArray average
> result in the same error.
>
> Now for the roundoff error issue.
>
> Oh dear, we really need to do a much better job educating programmers
> about floating point, we really do. In real number arithmetic,
> (a + b) - a = b
> is always true. In floating-point arithmetic it is not.
> This is easiest to see in cases like
> (1.0e20 + 1.0) - 1.0e20
> where Pharo answers 0.0 instead of 1.0.
> Less extreme cases still give you roundoff error.
>
> Much has been written about how to stably update mean, variance, &c.
> The simplest thing is to use Welford's algorithm for the weighted mean,
> using weight +1 to add the new element and -1 to remove the old.
>
> On Thu, 9 Apr 2020 at 19:33, Christian Haider <christian.haider(a)smalltalked-visuals.com <mailto:christian.haider@smalltalked-visuals.com>> wrote:
> I donât see how rounding errors could accumulate, if you keep the sum and not the average.
>
> The rounding errors should be neutral, because each element is added once and subtracted once.
>
> If + and â is symmetrical in this respect, rounding inaccuracies should balance out.
>
>
>
> Cheers,
>
> Christian
>
>
>
> Von: Pharo-users <pharo-users-bounces(a)lists.pharo.org <mailto:pharo-users-bounces@lists.pharo.org>> Im Auftrag von Richard O'Keefe
> Gesendet: Donnerstag, 9. April 2020 05:26
> An: Any question about pharo is welcome <pharo-users(a)lists.pharo.org <mailto:pharo-users@lists.pharo.org>>
> Betreff: Re: [Pharo-users] Moving/rolling average implementations ?
>
>
>
> I note that "self species ofSize: n" is not generally a good idea.
>
> Consider ByteArray, ShortIntegerArray, WordArray.
>
> Computing rolling means of these is perfectly sensible,
>
> but the results will not fit into an array of the same species.
>
> I'd stick with Array.
>
>
>
> The suggestion about subtracting an old element and adding a new
>
> one is great for integers, but for floating-point numbers risks
>
> accumulating errors.
>
>
>
> The
>
>
>
> On Wed, 8 Apr 2020 at 20:07, Cédrick Béler <cdrick65(a)gmail.com <mailto:cdrick65@gmail.com>> wrote:
>
> Hi,
>
>
>
> I wanted to do a moving/rolling average on raw data [1].
>
> I havenât find code for that (maybe this is done in polymath though).
>
>
>
> So I ended writing that (I thing this is SMA):
>
>
>
> SequenceableCollection>>movingAverage: anOrder
> "Answer the moving or rolling average for anOrder window"
>
>
>
> | retval size x y |
>
> anOrder <= 0 ifTrue: [ Error signal: 'the order must be positive'].
>
> size := self size - anOrder.
>
> size negative ifTrue: [ Error signal: 'the collection size is too small'].
>
> retval := self species ofSize: size + 1.
>
>
>
> x := 1.
>
> y := anOrder.
>
> [y <= self size ] whileTrue: [
>
> retval at: x put: (self copyFrom: x to: y) average
>
> x := x + 1. y := y + 1
>
> ].
>
> ^retval
>
>
>
> Not perfect but seems to works quite well (thatâs probably better to remove copyFrom: and use some kind of buffer instead).
>
>
>
> Any interest in that ? If any existing code too, Iâll be interested especially for other implementation (weighted, exponential) ?
>
>
>
> <image001.png>
>
>
>
> (#(118 113 105 105 103 99 98 101 100 107) movingAverage: 3) collect: [:v | v asScaledDecimal: 1 ] .
>
>
>
> "an Array(112.0s1 107.7s1 104.3s1 102.3s1 100.0s1 99.3s1 99.7s1 102.7s1)"
>
>
>
> Cheers,
>
> Cédrick
>
>
>
>
>
>
>
> [1] https://www.meilleursbrokers.com/techniques-de-trading/moyennes-mobiles.html <https://www.meilleursbrokers.com/techniques-de-trading/moyennes-mobiles.html> (in French but is understandable)
>
>
>
April 10, 2020
Re: [Pharo-users] Thinking aloud about project at hand
by Hilaire
Hi,
No doubt Pharo will fit the task. I developed a financial application
for mortgages debt consolidation where the sources of data were numerous.
With Pharo you will build a model with classes representing each part of
the domain of your data set. With Tests you will consolidate your model,
important when you change your model it will ensure your computations
are still valid. I use it a lot in mortgage, debt ratio and debt
consolidation calculus.
From your description, it seems your application will be mono-user. If
so any text file to keep the data will be ok: xml, json, csv. But sqlite
could be a very nice option too, I think this is what I will use.
I think you will enjoy using Pharo to write your app.
Hilaire
Le 09/04/2020 à 21:12, Tomaž Turk a écrit :
> I'm thinking about implementing a software solution in Pharo (as one
> of the candidate environments), it's a project that I'm dealing with
> professionally. The goal is to develop a financial planning/simulation
> application on the country level, which is at present developed as a
> set of interrelated Excel spreadsheets. The requirement is that the
> solution should be more "manageable", resilient and straightforward
> than Excel permits, that it should present a workflow to the user -
> i.e. , that the tasks the user should do are suggested through the GUI.
>
--
Dr. Geo
http://drgeo.eu
April 10, 2020
Re: [Pharo-users] Moving/rolling average implementations ?
by Richard O'Keefe
Let's take the inheritance issue first.
Yes, Collection has some subclasses where #average makes no sense,
such as String. If any subclass of Collection should have #average, it is
Array, as #(1 2 3 4) average makes perfect sense.
BUT #($a $b $c $d) average makes exactly as much sense as 'abcd' average.
So we have
- subclasses where a method never makes sense (String)
- subclasses where a method always makes sense (ByteArray)
- subclasses where a method may or may not make sense (Array).
Traits will not help at all with the third category.
Historic Smalltalk practice has been to define methods like
String>>average self shouldNotImplement.
to "cancel" inappropriate methods to deal with the "never" subclasses,
but that still does not help with the "maybe" ones.
In my own code I try very hard to ensure that a method is available in
a class if and only if the class can have instances where the method
makes sense. That is, I try to make sure that #respondsTo: is "honest".
It is not always practical.
This is not a problem that is peculiar to Smalltalk. Java and C# and C++
and you-name-it also have the "maybe" problem, where a method seems
to be available for an object but thanks to its state it is not.
As long as sending a message to an inappropriate object (whether due to
its class or its state) results in *some* exception, do we really have a
problem?
'abcd' average
'abcd' asArray average
result in the same error.
Now for the roundoff error issue.
Oh dear, we really need to do a much better job educating programmers
about floating point, we really do. In real number arithmetic,
(a + b) - a = b
is always true. In floating-point arithmetic it is not.
This is easiest to see in cases like
(1.0e20 + 1.0) - 1.0e20
where Pharo answers 0.0 instead of 1.0.
Less extreme cases still give you roundoff error.
Much has been written about how to stably update mean, variance, &c.
The simplest thing is to use Welford's algorithm for the weighted mean,
using weight +1 to add the new element and -1 to remove the old.
On Thu, 9 Apr 2020 at 19:33, Christian Haider <
christian.haider(a)smalltalked-visuals.com> wrote:
> I donât see how rounding errors could accumulate, if you keep the sum and
> not the average.
>
> The rounding errors should be neutral, because each element is added once
> and subtracted once.
>
> If + and â is symmetrical in this respect, rounding inaccuracies should
> balance out.
>
>
>
> Cheers,
>
> Christian
>
>
>
> *Von:* Pharo-users <pharo-users-bounces(a)lists.pharo.org> *Im Auftrag von *Richard
> O'Keefe
> *Gesendet:* Donnerstag, 9. April 2020 05:26
> *An:* Any question about pharo is welcome <pharo-users(a)lists.pharo.org>
> *Betreff:* Re: [Pharo-users] Moving/rolling average implementations ?
>
>
>
> I note that "self species ofSize: n" is not generally a good idea.
>
> Consider ByteArray, ShortIntegerArray, WordArray.
>
> Computing rolling means of these is perfectly sensible,
>
> but the results will not fit into an array of the same species.
>
> I'd stick with Array.
>
>
>
> The suggestion about subtracting an old element and adding a new
>
> one is great for integers, but for floating-point numbers risks
>
> accumulating errors.
>
>
>
> The
>
>
>
> On Wed, 8 Apr 2020 at 20:07, Cédrick Béler <cdrick65(a)gmail.com> wrote:
>
> Hi,
>
>
>
> I wanted to do a moving/rolling average on raw data [1].
>
> I havenât find code for that (maybe this is done in polymath though).
>
>
>
> So I ended writing that (I thing this is SMA):
>
>
>
> SequenceableCollection>>movingAverage: anOrder
> "Answer the moving or rolling average for anOrder window"
>
>
>
> | retval size x y |
>
> anOrder <= 0 ifTrue: [ Error signal: 'the order must be positive'].
>
> size := self size - anOrder.
>
> size negative ifTrue: [ Error signal: 'the collection size is too
> small'].
>
> retval := self species ofSize: size + 1.
>
>
>
> x := 1.
>
> y := anOrder.
>
> [y <= self size ] whileTrue: [
>
> retval at: x put: (self copyFrom: x to: y) average
>
> x := x + 1. y := y + 1
>
> ].
>
> ^retval
>
>
>
> Not perfect but seems to works quite well (thatâs probably better to
> remove copyFrom: and use some kind of buffer instead).
>
>
>
> Any interest in that ? If any existing code too, Iâll be interested
> especially for other implementation (weighted, exponential) ?
>
>
>
>
>
> (#(118 113 105 105 103 99 98 101 100 107) movingAverage: 3) collect: [:v |
> v asScaledDecimal: 1 ] .
>
>
>
> "an Array(112.0s1 107.7s1 104.3s1 102.3s1 100.0s1 99.3s1 99.7s1 102.7s1)"
>
>
>
> Cheers,
>
> Cédrick
>
>
>
>
>
>
>
> [1]
> https://www.meilleursbrokers.com/techniques-de-trading/moyennes-mobiles.html (in
> French but is understandable)
>
>
>
>
April 10, 2020
Thinking aloud about project at hand
by Tomaž Turk
Dear all,
I'm thinking about implementing a software solution in Pharo (as one of
the candidate environments), it's a project that I'm dealing with
professionally. The goal is to develop a financial planning/simulation
application on the country level, which is at present developed as a set
of interrelated Excel spreadsheets. The requirement is that the solution
should be more "manageable", resilient and straightforward than Excel
permits, that it should present a workflow to the user - i.e. , that the
tasks the user should do are suggested through the GUI.
The majority of the data is in a form of a time series (for instance:
GDP for a series of years). There are many variables in the model which
shoud be calculated from other variables, year by year. There are also
lagged variables (the value for the current year depends from the value
of previous year), and running averages. There are also some variables
which are not time series (parameters). As a part of GUI, there is a
need to present the results as diagrams, too (scatterplots, line
charts), otherwise tables are the output.
I found Pharo to be a very elegant language and environment, with
version 8.0 it became pretty stable, however I don't have any
experiences in building software solutions of this type in Smalltalk. In
other words, I'd like to be more confident in setting the architecture,
both in the sense of the model content (variables interrelation) and the
architecture of classes. Besides, for the calculated variables I'd like
to have a relatively simple syntax to define them (like 'GDPpC <- GDP /
Population').
My thoughts and questions:
- for easier maintenance I'd like to separate the data from the code -
so the question is what would be the best way to implement persistence
(another Pharo image - with what?, some relational database, XML/JSON,
flat files ...)
- I wonder what would be the best "architecture" of classes - so, we
have a lot of aggregate variables like GDP and population, which can be
grouped at least according to the stage in the planning workflow. There
are also resulting (calculated) variables (e.g. GDP per capita). On the
other hand, since this is a planning software, it's a kind of
simulation, where we have a "data warehouse", experiments and results
- As a core packages I would use Spec2, Roassal, and PolyMath.
I'm just thinking aloud, and would greatly appreciate any thoughts from
experienced Pharoers :-)
Best wishes,
Tomaz
April 9, 2020
Re: [Pharo-users] Moving/rolling average implementations ?
by Cédrick Béler
Hi Richard and Christian,
thanks for the comments/suggestions.
For the "self species ofSize⦠», I got inspiration from the image like with #overlappingPairsCollect:
As for float rounding errors, that interesting to consider indeed. Iâll try a buffer variant.
Some related questions for my OO culture ;-) :
#average is defined in Collection⦠That makes me wonder (especially in Collection hierarchy) that some methods are not applicable to some subclass. I think this is a common problem with inheritance ?
Whatâs the way to deal with that ? Traits ?
I found #shouldNotImplement that is used 106 times in one P8 image.
Is it a good/favored pattern to prevent usage of such methods ?
Cheers,
Cédrick
PS: would such method be a candidate for integration in base image ? If yes, I could try a PR.
April 9, 2020
Re: [Pharo-users] Automation of MS Office from Pharo
by Ben Coman
I'd be very interested to hear how this ends up.
Parsing Outlook mails from Pharo may prove useful in my day job.
cheers -ben
On Wed, 8 Apr 2020 at 18:02, PBKResearch <peter(a)pbkresearch.co.uk> wrote:
> Hello Pablo
>
> Success! I have rerun one of the troublesome cases, with no problem. I
> then re-ran the test on the latest 16 messages, collecting all the HTML
> outputs in an array, which took just over 5 secs total; quicker than I
> expected. The longest texts, from the most verbose newsletters, run from
> 267K to over 300K, so that is where they ran into the limit we found
> yesterday.
>
> I now know that I can pass the HTML to the XMLHTMLParser in memory,
> without saving to file first; this will be more convenient. Thanks for the
> prompt help.
>
> @Guillermo - All this is a proof of possibility, it will need to be
> combined with other bits I am working on to make the automated system I
> want. I shall let you know when it is worked out - but it won't be in the
> next few days!
>
> Thanks to all
>
> Peter Kenny
>
> -----Original Message-----
> From: Pharo-users <pharo-users-bounces(a)lists.pharo.org> On Behalf Of
> Guillermo Polito
> Sent: 08 April 2020 09:20
> To: Tomaž Turk <tomaz.turk(a)ef.uni-lj.si>; Any question about pharo is
> welcome <pharo-users(a)lists.pharo.org>
> Subject: Re: [Pharo-users] Automation of MS Office from Pharo
>
> Cool, thanks to the three :)
>
> @Peter, Iâd like if you tell us at the end if you had success at
> automating you mail workflow ^^
>
> > El 8 abr 2020, a las 10:15, Tomaž Turk <tomaz.turk(a)ef.uni-lj.si>
> escribió:
> >
> > Thanks Pablo for your quick response! I tested 32 and 64 bit images with
> >1.000.000 strings and it works just fine.
> >
> > Best wishes,
> > Tomaz
> >
> >
> > ------ Original Message ------
> > From: "tesonep(a)gmail.com" <tesonep(a)gmail.com>
> > To: "Any question about pharo is welcome" <pharo-users(a)lists.pharo.org>
> > Cc: "Tomaž Turk" <tomaz.turk(a)ef.uni-lj.si>
> > Sent: 8.4.2020 9:54:35
> > Subject: Re: [Pharo-users] Automation of MS Office from Pharo
> >
> >> Hi!!!
> >> This was a great report. I have submitted a fix in the master of
> Pharo-COM.
> >>
> >> Basically the problem was to free twice the BSTR in the Variant.
> >> It was being free in the access to the value and in the free of the
> struct.
> >> Why it works with other BSTR when they are smaller, I cannot know.
> >>
> >> I have added another smoke test using Word
> >>
> >> Can you try the fix?
> >>
> >> Thanks, both for helping me with the reports, they were great.
> >>
> >> On Wed, Apr 8, 2020 at 9:37 AM PBKResearch <peter(a)pbkresearch.co.uk>
> wrote:
> >>>
> >>> Tomaz, that was my understanding from the VBA piece you cited
> yesterday. So presumably it must be something in Pharo-Com which imposes
> the limits we have seen. I am OK at the moment, because all this work is
> just an exploration of possibilities; I can wait until you and Pablo have
> sorted it out. But from the results of your tests, a maximum of 16K in
> 64-bit systems must be a serious limitation, so something in Pharo-Com
> needs fixing.
> >>>
> >>>
> >>>
> >>> For my immediate work, I shall continue exporting the full text using
> MailItem.SaveAs; my further processing uses files I have exported manually
> in this way, so itâs not a problem.
> >>>
> >>>
> >>>
> >>> Thanks
> >>>
> >>>
> >>>
> >>> Peter Kenny
> >>>
> >>>
> >>>
> >>> From: Pharo-users <pharo-users-bounces(a)lists.pharo.org> On Behalf Of
> Tomaž Turk
> >>> Sent: 08 April 2020 07:58
> >>> To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org>
> >>> Subject: Re: [Pharo-users] Automation of MS Office from Pharo
> >>>
> >>>
> >>>
> >>> Thanks, Stephane, for the acknowledgement. Peter, as I understand, the
> limits in COM BSTR data type are defined by the header's length prefix
> (which is 4 bytes) and software implementatios - for instance, string data
> type in Visual Basic for Applications is described as "a variable-length
> string can contain up to approximately 2 billion (2^31) characters", which
> is in line with the BSTR header. I'm not sure if the OS architecture (32
> and 64 bit) influences these values.
> >>>
> >>>
> >>>
> >>> Best wishes,
> >>>
> >>> Tomaz
> >>>
> >>>
> >>>
> >>>
> >>
> >>
> >>
> >> --
> >> Pablo Tesone.
> >> tesonep(a)gmail.com
> >
> >
>
>
>
>
April 9, 2020
Re: [Pharo-users] Moving/rolling average implementations ?
by Christian Haider
I donât see how rounding errors could accumulate, if you keep the sum and not the average.
The rounding errors should be neutral, because each element is added once and subtracted once.
If + and â is symmetrical in this respect, rounding inaccuracies should balance out.
Cheers,
Christian
Von: Pharo-users <pharo-users-bounces(a)lists.pharo.org> Im Auftrag von Richard O'Keefe
Gesendet: Donnerstag, 9. April 2020 05:26
An: Any question about pharo is welcome <pharo-users(a)lists.pharo.org>
Betreff: Re: [Pharo-users] Moving/rolling average implementations ?
I note that "self species ofSize: n" is not generally a good idea.
Consider ByteArray, ShortIntegerArray, WordArray.
Computing rolling means of these is perfectly sensible,
but the results will not fit into an array of the same species.
I'd stick with Array.
The suggestion about subtracting an old element and adding a new
one is great for integers, but for floating-point numbers risks
accumulating errors.
The
On Wed, 8 Apr 2020 at 20:07, Cédrick Béler <cdrick65(a)gmail.com <mailto:cdrick65@gmail.com> > wrote:
Hi,
I wanted to do a moving/rolling average on raw data [1].
I havenât find code for that (maybe this is done in polymath though).
So I ended writing that (I thing this is SMA):
SequenceableCollection>>movingAverage: anOrder
"Answer the moving or rolling average for anOrder window"
| retval size x y |
anOrder <= 0 ifTrue: [ Error signal: 'the order must be positive'].
size := self size - anOrder.
size negative ifTrue: [ Error signal: 'the collection size is too small'].
retval := self species ofSize: size + 1.
x := 1.
y := anOrder.
[y <= self size ] whileTrue: [
retval at: x put: (self copyFrom: x to: y) average
x := x + 1. y := y + 1
].
^retval
Not perfect but seems to works quite well (thatâs probably better to remove copyFrom: and use some kind of buffer instead).
Any interest in that ? If any existing code too, Iâll be interested especially for other implementation (weighted, exponential) ?
(#(118 113 105 105 103 99 98 101 100 107) movingAverage: 3) collect: [:v | v asScaledDecimal: 1 ] .
"an Array(112.0s1 107.7s1 104.3s1 102.3s1 100.0s1 99.3s1 99.7s1 102.7s1)"
Cheers,
Cédrick
[1] https://www.meilleursbrokers.com/techniques-de-trading/moyennes-mobiles.html (in French but is understandable)
April 9, 2020
Re: [Pharo-users] Moving/rolling average implementations ?
by Richard O'Keefe
I note that "self species ofSize: n" is not generally a good idea.
Consider ByteArray, ShortIntegerArray, WordArray.
Computing rolling means of these is perfectly sensible,
but the results will not fit into an array of the same species.
I'd stick with Array.
The suggestion about subtracting an old element and adding a new
one is great for integers, but for floating-point numbers risks
accumulating errors.
The
On Wed, 8 Apr 2020 at 20:07, Cédrick Béler <cdrick65(a)gmail.com> wrote:
> Hi,
>
> I wanted to do a moving/rolling average on raw data [1].
> I havenât find code for that (maybe this is done in polymath though).
>
> So I ended writing that (I thing this is SMA):
>
> SequenceableCollection>>movingAverage: anOrder
> "Answer the moving or rolling average for anOrder window"
>
> | retval size x y |
> anOrder <= 0 ifTrue: [ Error signal: 'the order must be positive'].
> size := self size - anOrder.
> size negative ifTrue: [ Error signal: 'the collection size is too
> small'].
> retval := self species ofSize: size + 1.
>
> x := 1.
> y := anOrder.
> [y <= self size ] whileTrue: [
> retval at: x put: (self copyFrom: x to: y) average
> x := x + 1. y := y + 1
> ].
> ^retval
>
> Not perfect but seems to works quite well (thatâs probably better to
> remove copyFrom: and use some kind of buffer instead).
>
> Any interest in that ? If any existing code too, Iâll be interested
> especially for other implementation (weighted, exponential) ?
>
>
> (#(118 113 105 105 103 99 98 101 100 107) movingAverage: 3) collect: [:v |
> v asScaledDecimal: 1 ] .
>
> "an Array(112.0s1 107.7s1 104.3s1 102.3s1 100.0s1 99.3s1 99.7s1 102.7s1)"
>
> Cheers,
> Cédrick
>
>
>
> [1]
> https://www.meilleursbrokers.com/techniques-de-trading/moyennes-mobiles.html (in
> French but is understandable)
>
>
April 9, 2020