JerryI / wolfram-js-frontend

Dynamic Notebook Environment for Wolfram Language written in Javascript
https://jerryi.github.io/wljs-docs/
GNU General Public License v3.0
313 stars 15 forks source link

Too Long To Display but the list is only 4 objects #282

Closed Hachann closed 2 months ago

Hachann commented 2 months ago

Hello guys,

I have an Association of Length 4. I can display each of its elements, but when calling the Association or Values @ Association, I have a "Too Long to Display" message, but it's just an Association of 4 TimeSeries objects with 1000 data points or so :

image

This behaviour is not always encountered. For example, here, I can display an Association of 4 TimeSeries of more than 2 millions datapoints each :

image

JerryI commented 2 months ago

Hi @Hachann ! Hmm... Does it occur still if you drop 1 key from trBars? Like KeyDrop[trBars...

Hachann commented 2 months ago

Hi @Hachann ! Hmm... Does it occur still if you drop 1 key from trBars? Like KeyDrop[trBars...

image

JerryI commented 2 months ago

Screenshot 2024-09-09 at 15 01 56

Now I see. Below a threshold of ~1000 items (depends on the structure) inside a TimeSeries, the data is stored inside a cell (try to copy and paste it to a normal text editor outside WLJS). When You have multiple of those items, the cell gets really large inside and a post-processor decideы to cut it avoid editors lags

However, if you have exceeded already the limits within a single TimeSeries (labelled by Data on Kernel), there is no longer an actual data underneath, only a temporal reference, which costs nothing. Therefore you can have many more of such symbols inside an output of a single cell.

JerryI commented 2 months ago

I think we should lower this limit even more, since a single instance of TimeSeries with only 1000 entities already causes lags, when I try to type inside the same cell on my M1 Air.

Hachann commented 2 months ago

I see !

As for my use cases, working heavily with TimeSeries, displaying a TimeSeries object (or more) in an output in Mathematica lets me :

  1. check that I do get a TimeSeries as the result of a computation which should output a TimeSeries,
  2. quickly see if data points are all numeric (blue curve representation) or not (gray curve),
  3. quickly check TimeSeries properties like PathLength, Interpolation and TemporalRegularity, which I can see in Mathematica after clicking "+" button in the TimeSeries object.

The 2nd point is already a feature in WLJS, which is nice :)

So yeah, I don't think it's very useful to store values in the frontend, given my understanding of your input. One should use the operator form ["Values"] on the TimeSeries to visualize them, I believe.

Thank you !

JerryI commented 2 months ago

I see !

As for my use cases, working heavily with TimeSeries, displaying a TimeSeries object (or more) in an output in Mathematica lets me :

  1. check that I do get a TimeSeries as the result of a computation which should output a TimeSeries,
  2. quickly see if data points are all numeric (blue curve representation) or not (gray curve),
  3. quickly check TimeSeries properties like PathLength, Interpolation and TemporalRegularity, which I can see in Mathematica after clicking "+" button in the TimeSeries object.

The 2nd point is already a feature in WLJS, which is nice :)

So yeah, I don't think it's very useful to store values in the frontend, given my understanding of your input. One should use the operator form ["Values"] on the TimeSeries to visualize them, I believe.

Thank you !

  1. Is not an problem, the output of WLJS (unlike Mathematica) is 100% compatible with InputForm of any expression. Even if it says that it is stored on Kernel, you still have the same TimeSeries, but with the first argument being a reference. It will still work like a normal TimeSeries. If understand you point correctly...
  2. We implemented only a single symbol SummaryBox, which basically is used for TimeSeries and many many others. The rest is done (galdly) by the output form of TimeSeries :)
  3. This is true, we left this part of SummaryBox for the future. But it will be implemented at some point.

So yeah, I don't think it's very useful to store values in the frontend, given my understanding of your input. One should use the operator form ["Values"] on the TimeSeries to visualize them, I believe.

Don't worry, what you see on the preview is not an actual data piped into frontend, WL trims it quite a lot to minimize the load (probably uses bigger steps in the series) and renders separately from what you have in a cell.

As for my use cases, working heavily with TimeSeries, displaying a TimeSeries object (or more) in an output in Mathematica lets me

If you don't want to wait for us to fix it. You can locate a specific file

app_data_directory_/wljs-notebook/wljs_packages/wljs-editor/src/BoxesWorkarounds.wl

find a line with

BoxForm`ArrangeSummaryBox[head_, interpretation_, icon_, above_, hidden_, ___, OptionsPattern[] ] := With[{
  headString = If[!StringQ[head], ToString[head, InputForm], head],
  event = OptionValue["Event"],
  iconHash = Hash[icon]
},
....

a few lines later there will be a threshold value defined

  With[{interpretationString = ToString[interpretation, InputForm]},
    If[StringLength[interpretationString] > 25000,
      Module[{temporalStorage},

then just change 25000 to somewhat smaller, for instance 250. Then restart your Kernel (no an app). It will force WL to use references only for any summary items like TimeSeries.

Hope it will help you!

JerryI commented 2 months ago

Fixed in a new release of wljs-editor