Load not working properly with fluid.normalize~?

Bug Reports and Issues
1

As per usual, before creating a git issue, want to check to make sure it’s not user error.

Basically trying to implement what I suggested here with regards to “hacking” fluid.normalize~ based on creating a fake dict to load into it.

I notice that when I do this, the min and max values from the dict don’t appear to get loaded into the actual normalization:

Screenshot 2024-01-20 at 3.14.39 PM
Screenshot 2024-01-20 at 3.14.39 PM1003×708 58.7 KB


----------begin_max5_patcher----------
1209.3ocyY0saihCF85jmBKzJs2zAAFLF5Uyk6Cvd2pUUNfyDlALHvjocGMy
y9Z+YnIsEZfDfoRoIfw0GeN96Oa9w1MV6JdjWagtG8OnMa9w1MaflzMro89M
V4rGiyX0P2rhKxy4Bo0clmI4OJg1I1H4AdMGkTH9SIplyyQxBTSYBSxQ6X07
DTg.kjFKQohxlmGgrTAOtnQ.CCtswxJ0PIjLYZg3gd6QZB.awtu9IrW2XsuP
H2yh45G411lnIOUjwk0m2nti0o+GzQrisSGrLY7gTwWdnhGKMphenm5wH+.h
9Gr4G+.aGz+dBfhFYGBNmgffkCHX8W7ribYZLyR+vetcq9q6tQE22F82GRqQ
0GJZxRP63nO4XGQC8iHmtx5hBpWOBpyBJndDpVBCHg5e7B7L55G.A0SYBWwD
06KpxKKRO0iIIdtQKn3gi.yOLHgtzONZG1FEWw0t5GXweS4qqczmOWb2vkTT
gGivtXPU8933h6ZqhUlJQ7i7pmj5osUOZCcA0lfHvhiBZha.c0M310HkEhNF
ZfR9TI2L8r1wTZxySlyUkSg9XUpYhjW8.Wv1kwOed1q5zmLXb0nA.+869d.U
v8J3of+c0z9MV.YErjbdcsJro5yfxP+Rvy4EGKMo9Fp4BrMxDdAuF7bWy987
pegj7ZoZNg9bMKurFgGjw6UJixg48r.vWI88bLgW8Ct.+wyG+2m0jlXmkVKw
Jo.84DPGfficZxv9.f10qFDcsV.Dvs2MzeALATKcpAYXa42rnpSHyfIXvaoX
3b5mSHPp.OOXo2byLa.LurmNqr2w3wGhWL1qikw9B+s0OLsPajdsqwuSUmAt
F1XLnirIqUjsSQv8UelFMmbDLehIQcHcsCf+LMcwT8eSLU0jIpSnoXMfhtlH
1yLSGxVU4Wn.j3g5tXhbM.OYqWylkBvPXI+nvUjslrKn+.OUV5bk9nDSA3jf
0y30j8UwTrNC7fDEdX+EaFdsjkBVtT7Jth9xM4dwxKFfwSNDL1ocyqlRKv9q
25qZulkbQBRGjZp7bxEQ2tx1xSZzZaFKz0Kjo1c2ud2hLFft3qktgQiJky0T
zf9rDrOlx+de69kL4bGzHSY9z1SQAty0Mb3c0t.oIOkxaraliLUdRnlJ3LEC
P8+cTLvTIou0UVypGPOpy5QRvprjE+MTbQV88nDlj8f5er6pTw8H3V8UCpC5
QQsIOV0SCnH8G+I3hNjsl2XSEgyrjvjxplzoVQf+X1rhdnMouRESu7WmySwP
b9vPcxznN6woR8.yoWdUTG5BbJsu5UAA3na+k5QcQSUbGg6NrMzIjN6vKNuS
unOEUIbfr98tFLqHi6GYukGYHfVeXiWCrI8is6Zfc+P6baP6MBniL84l.JbT
TTOa7uQjd8hT+XENCbhNZN4cybxeDXQmANAUmeYVQvyBVjUDK7XvRuE6aGq.
+0iWAqmFRFs89shDdzHguU8azH4dy9viyyxcYhyONv8Vj7acdUW.7vYwOeTY
ZzGX3qVQMkrwJKOxqpa6N.ip1wuV.xP3cvsoBysvNFrp3GS65OTMoEqRUJoT
UGYSk4009Xac5V4EJAUnp00noJBpfDJDV+pcqKaeSyP8xa+41+GPvZ017
-----------end_max5_patcher-----------

I would think that the dict values for min and max to be used when normalizing, but it appears they are ignored completely.

In this specific case it doesn’t matter too much as I can just set the attribute versions in fluid.normalize~ to @min -1 and @max 1, but it does not bode well when normalizing to a different output range than the default 0. and 1..

I may also have cases where I’m wanting to adjust the output range dynamically based on what @activation I am using in fluid.mlpregressor~.

/////////////////////////////////////////////////////////

So is this a bug, or am I overlooking something in terms of “hacking” the loaded dict?

2

Hmm, weirder still, the dump output of fluid.normalize~ reports the correct values based on the input even though the attruis (and resultant processing) do not:

Screenshot 2024-01-20 at 3.20.12 PM
Screenshot 2024-01-20 at 3.20.12 PM1286×749 70.8 KB

Are the min / max columns of loaded/dumped dicts just ignored and overwritten by the state of the @attribute versions of min / max?

3

Aaaaand even more weirdness.

It seems like load isn’t internally declaring the state to have been fit or something like that. In fluid.standardize~ load-ing in a dict means that any processing happens just fine (on a dataset at least, I’ve not tried it on a buffer~ via transformpoint).

I did narrow down some steps where it behaves as it seems like it should:

Steps for weirdness:

  1. follow instructions as they are on in the patch

  2. manually change the min value via the attrui

  3. dump output doesn’t reflect any change

  4. transformpoint again - the correct values are output

  5. dump output reflects correct change

This leads me to believe that the dict is in fact being load-ed, but crucially not being defined as having been “fit”. And that for some reason load-ing values only partially triggers this, whereas manually editing via attrui and then fittransform-ing does it reflect correctly.

4

this does look like a bug. let me recompile and check it is actually loading the values

1 Like
5

can you feel the fan of my laptop (i9 I’m not cool with the Mx kids) freaking under the compiling? feeeeel the buuuuuurnnnnn

6

Ha! You found a real bug!!! it’s been there since the beginning of times!
Sorted in the next nightlies.

7

wait for them to recompile, give GitHub 30 minutes

8

actually, as usual, it is a lot more complicated than it seems… at the moment we have a strange behaviour of enabling the scale of the output (min and max) to be changed without refitting. To correct the current bug, I need to stop that behaviour. It is of no real cost, but it just means that the output range will be set at fitting time…

Let’s try that for now and see how it breaks the world in the nightly?

9

I’ve asked the code gods if my fix was valid even if it breaks something. in the meantime, can you roadtest this? Just replace in your package.

fluid.libmanipulation.mxo.zip (2.8 MB)

for the cpp-curious: fixing fluid.normalize json reloading issue by tremblap · Pull Request #262 · flucoma/flucoma-core · GitHub

10

This works! (complains about quarantine obviously, but the patch above shows the correct numbers now)

Shame, but it’s not like fitting is heavy/onerous with this object, and it means being able to load any saved normalization and it working properly.

1 Like