Select Page

# PVAL +/- 1 unit of time

Optuma Forums Optuma Scripting PVAL +/- 1 unit of time

Viewing 15 posts - 1 through 15 (of 24 total)
• Author
Posts
• #55915
Andrew
• Topics: 20
• Replies: 43
• Posts: 63

Hi guys – I’m looking to translate some processes that I use in excel into scripts for use in Optuma using a show bar.

If for example P1Raw=PVAL(PLANET=[Venus], GEO=HelioCentric, VALUE=Longitude);

how would I compare this P1Raw ephemeris value for today to the P1Raw ephemeris value of yesterday or for that matter the P1Raw ephemeris value for tomorrow in a script  ?

eg. If VE Longitude yesterday was 357.05 and today it is 358.64 then P1Raw=358.64

how might I subtract yesterday’s P1Raw(yesterday) value of 357.05 to say for example obtain a calculated value of 1.59 ?

What I need to do is more complicated, including rounding and absolute values but the above should offer a leg up.

Cheers

Andrew

#55919
Matthew
• Topics: 4
• Replies: 274
• Posts: 278

Hi Andrew,

The process of accessing previous values is the same for most functions in Optuma.  You can see the two most common ways to do it via the following forum post:

Calculating RSI over previous n bars

RSI is the example used there but it will work for PVAL as well.

###### 1 user thanked author for this post.
#55921
Trevor R
• Topics: 79
• Replies: 252
• Posts: 331

Hi Andrew,

Is this what you are looking for:

Here I’ve created 3 scripts to show the values using the CHART ELEMENT tool (which I understand displays the last value for a script)  for the p1Raw (last Bar), p1Raw[1] (the 2nd last Bar) and P1Difference, ie p1Raw – p1Raw[1].  The [1] is using the script OFFSET function to refer to the preceding Bar, (negative numbers refer to succeeding Bars). The scrip is:

BUT, and this is a BIG BUT, the longitude values being reported by the CHART ELEMENTs are significantly different from those shown by my Custom Tool “Planetary Longitude Label” which agrees with the Swiss Ehpmeris listing for the last 2 Bars. I hope the great guys at Optuma see this post and can explain the reason for the discrepancy in the display results.

Cheers

Trevor

The Auld Tyma at

#56025
Andrew
• Topics: 20
• Replies: 43
• Posts: 63

G’day Trevor

Appreciate your reply and I too look forward to a response to the question you raise.

I’ve attached an example of one element of the process I’m seeking to replicate in the attached excel sheet, the .owb shows my attempt to replicate using scripting but the graph seems to revert to zero then restart and I’m not sure why? The line like the data set in ColC should increase infinitely if the scripting is correct?

Any thoughts, human error no doubt……

Cheers

Andrew

###### Attachments:
#56061
Matthew
• Topics: 4
• Replies: 274
• Posts: 278

Hi,

The Chart Element tool will always show the last value being returned by the script. With PVAL() it does not reference the bars on the chart, and so has the ability to project past the last bar to fill in the Blank space going into the future.

If you applied your PVAL script to a Show View and compared the last value at the end of the chart, to the chart element you would see they match.

You can see in the above example the PVAL() script for Venus is returning the last value as 74.05 in the Show View (past the last bar) and lines up with the value being returned by the Chart Element.

If you hover over the Show Views value for the 29-11-2019 you would see it matches the Ephemeris / Custom Label tool in your screen shot.

#56087
Trevor R
• Topics: 79
• Replies: 252
• Posts: 331

Hi Matthew,

Thanks for the explanation.

As the PVAL calculation goes beyond the last bar, how can the PVAL calculation be stopped at the last Bar?

Cheers

Trevor

#56089
Matthew
• Topics: 4
• Replies: 274
• Posts: 278

Hi,

Easiest way is to lock the PVAL() value to a Bar Date so that it can’t go past the last bar.

Script example:

Below is a screen shot of the PVAL() on a chart element with (Green) and without (Red) the BarDate variable…

• This reply was modified 8 months ago by Matthew.
#56093
Andrew
• Topics: 20
• Replies: 43
• Posts: 63

G’day Trevor

Appreciate your reply and I too look forward to a response to the question you raise.

I’ve attached an example of one element of the process I’m seeking to replicate in the attached excel sheet, the .owb shows my attempt to replicate using scripting but the graph seems to revert to zero then restart and I’m not sure why? The line like the data set in ColC should increase infinitely if the scripting is correct?

Any thoughts, human error no doubt……

Cheers

Andrew

Hi Matthew, grateful for your thoughts on this also if possible?

Thanks

Andrew

#56095
Trevor R
• Topics: 79
• Replies: 252
• Posts: 331

Hi Guys,

Thanks Matthew.

Andrew here is the way to get the planet longitude difference between between the last bar and the bar preceding it:

Which results in a chart that looks like this:

A copy of the workbook is attached.

Trevor

The Auld Tyma at

• This reply was modified 8 months ago by Trevor R.
###### Attachments:
#56111
Andrew
• Topics: 20
• Replies: 43
• Posts: 63

Evening Trevor

I’m still not where I’d expect to be, namely ColC values in the spreadsheet that I posted. In Helio, the values should be always increasing. Your script is returning a different result for me as shown below.

Will keep at it though !! and thanks as always.

Andrew

#56117
Trevor R
• Topics: 79
• Replies: 252
• Posts: 331

Hi Andrew,

I think I’m getting close to what you want:

The script producing the IP Infinite TRB is

I admit there are some unexplained minor longitude differences but they are minor and I think related to the PVAL longitude calculation and the Custom Tool calculation – the properties for each may be slightly different.

A copy of the workbook is attached.

Trevor

The Auld Tyma at

###### Attachments:
#56129
Andrew
• Topics: 20
• Replies: 43
• Posts: 63

You da man Trevor – this is looking promising for sure !!

Do you know what the easiest way would be to allocate the start date in scripting using the initial positioning of a mouse click rather than a defined date? Just thinking ahead with the end process I have in mind ?

Cheers & many thanks

Andrew

#56135
Matthew
• Topics: 4
• Replies: 274
• Posts: 278

Hi Andrew,

The Points() function can be used to set a specific date for a script tool.

You can see several examples of it being used on the following article:

https://help.optuma.com/kb/faq.php?id=952

#56143
Andrew
• Topics: 20
• Replies: 43
• Posts: 63

Great, thanks Matthew.

For anyone following along, the script in its current form looks like this now:

I note that the script gets set by the initial placement of the mouse, if I view the tool in a separate window the start is indicated by a blue dot

Intuitively, I would expect to be able to move the position of that blue dot (start point) and for the line to recalculate to any new location like with many Optuma tools. Is this possible in scripting, if so what question should I be asking in the help files to locate the most useful help article?

Ta, Andrew

#56149
Matthew
• Topics: 4
• Replies: 274
• Posts: 278

Hi Andrew,

Currently the Points() function doesn’t support dynamic updating when moved.  You need to move the point, then save / close / re-open for the line to update, or delete and re-apply the line at the new date.

###### 1 user thanked author for this post.
Viewing 15 posts - 1 through 15 (of 24 total)
• You must be logged in to reply to this topic.