2,996,395 events, 1,477,573 push events, 2,383,428 commit messages, 179,223,641 characters
Fix RLP serialisation of seq[Transaction] used in eth protocol
-
This generalise the special cases for serialising RLP
seq[Transaction]insideBlockBodyandEthBlock, to do it for allseq[Transaction]no matter what objects they are part of.openArray[Transaction]is also included, as this was found to be necessary to match some places. -
There are some bug fixes as well to the original RLP parser for
Transaction. Specifically:a. It always reads the first byte to get the transaction type instead of parsing an RLP
int. The reason is that wrong/adversarial input gives a sensible error (i.e. invalid type code) when it's read as a byte, and when it's read as anintthose inputs give crazy messages ("too large to fit in memory" etc) that make it look like we have coding errors processing input.b. If a typed transaction is detected in
seq[Transaction], the old code unwraps the RLP (blob) wrapper than passes the contents toread(Transaction), which means a blob-wrapped legacy transaction would be accepted. This is incorrect and the new code always passes it to the typed transaction decoder, which would reject that.
This has a large effect on eth/65 syncing with peers.
In eth/63, messages Transactions passes an openArray[Transaction].
In eth/65, so does PooledTransactions.
The RLP parsers for both of these message types have been broken since the introduction of typed transactions (EIP-2718), as used in Berlin/London forks.
There is a special case for seq[Transaction] inside EthBlock and
BlockBody, but not for the list of transactions passed in those messages.
Due to this, whenever a peer sent us a Transactions message, we had an RLP
decoding error processing it, and disconnected the peer thinking it was the
peer's error.
These messages are sent often by good peers, so whenever we connected to a really good peer, we'd end up disconnecting from it within a few tens of seconds due to this.
This didn't get noticed before updating to eth/65, because with old protocols
we tend to only connect to old peers, which may be out of date themselves and
have no transactions anyway. Also, we didn't really investigate occasional
disconnects before, we assumed they're just part of P2P life.
The root cause is the RLP serialisation of individual Transaction objects is
meant to be be subtly different from the RLP serialisation of arrays/sequences
of Transaction objects that are sent in network messages. RFC-2976 covers
this but it's quite subtle:
-
Individual transactions are encoded and stored as either
RLP([fields..])for legacy transactions, orType || RLP([fields..]). Both of these encodings are byte sequences. The part afterTypedoesn't have to be RLP in theory, but all types so far use RLP. EIP-2718 covers this. -
In arrays (sequences), transactions are encoded as either
RLP([fields..])for legacy transactions, orRLP(Type || RLP([fields..]))for all typed transactions to date. Spot the extraRLP(..)blob encoding, to make it valid RLP inside a larger RLP. EIP-2976 covers this, "Typed Transactions over Gossip", although it's not very clear about the blob encoding.
In eth/65 protocol this is essential for the correct encoding/decoding of
Transactions, NewBlock, and PooledTransactions messages. We need a type
match on both openArray[Transaction] and seq[Transaction] to catch all cases.
In practice the extra RLP(..) applies to all arrays/sequences of transactions
that are to be RLP-encoded as a list. In principle, it should even be all
aggregates (objects etc.), but it's enough for us to enable it for all
arrays/sequences, as this is what's used in the protocol and EIP-2976.
Signed-off-by: Jamie Lokier jamie@shareable.org
Fix RLP serialisation of seq[Transaction] used in eth protocol
-
Generalises the special cases for serialising RLP
seq[Transaction]. Previously it only used the special case insideBlockBodyandEthBlock. Now it uses it for allseq[Transaction]regardless of what objects they are parts of, or no object at all.openArray[Transaction]is also included, as this was found to be necessary to match in some places. -
Bug fix parsing
Transaction: Always read the first byte to get the transaction type instead of parsing an RLPint. This way invalid or adversarial input gives a correct error (i.e. invalid type code).When it was read with
rlp.read(int), those inputs gave many crazy messages (e.g. "too large to fit in memory"). In the specification it's a byte. (Technically the input is not RLP and we shouldn't be using the RLP parser anyway to parse standalone transaction objects). -
Bug fix parsing
Transaction: If a typed transaction is detected inseq[Transaction], the previous code removed the RLP (blob) wrapper, then passed the contents toread(Transaction). That meant a blob-wrapped legacy transaction would be accepted. This is incorrect. The new code passes the contents to the typed transaction decoder, which correctly rejects a wrapped legacy transaction as having invalid type.
Change 1 has a large, practical effect on eth/65 syncing with peers.
Serialisation of eth message types Transactions and PooledTransactions
have been broken since the introduction of typed transactions (EIP-2718), as
used in Berlin/London forks. (The special case for seq[Transaction] inside
BlockBody only fixed message type BlockBodies.)
Due to this, whenever a peer sent us a Transactions message, we had an RLP
decoding error processing it, and disconnected the peer thinking it was the
peer's error.
These messages are sent often by good peers, so whenever we connected to a really good peer, we'd end up disconnecting from it within a few tens of seconds due to this.
This didn't get noticed before updating to eth/65, because with old protocols
we tend to only connect to old peers, which may be out of date themselves and
have no typed transactions. Also, we didn't really investigate occasional
disconnects before, we assumed they're just part of P2P life.
The root cause is the RLP serialisation of individual Transaction is meant to
be subtly different from arrays/sequences of Transaction objects in network
messages. RFC-2976 covers this but it's quite subtle:
-
Individual transactions are encoded and stored as either
RLP([fields..])for legacy transactions, orType || RLP([fields..]). Both of these encodings are byte sequences. The part afterTypedoesn't have to be RLP in theory, but all types so far use RLP. EIP-2718 covers this. -
In arrays (sequences), transactions are encoded as either
RLP([fields..])for legacy transactions, orRLP(Type || RLP([fields..]))for all typed transactions to date. Spot the extraRLP(..)blob encoding, to make it valid RLP inside a larger RLP. EIP-2976 covers this, "Typed Transactions over Gossip", although it's not very clear about the blob encoding.
In practice the extra RLP(..) applies to all arrays/sequences of transactions
that are to be RLP-encoded as a list. In principle, it should be all
aggregates (object fields etc.), but it's enough for us to enable it for all
arrays/sequences, as this is what's used in the protocol and EIP-2976.
Signed-off-by: Jamie Lokier jamie@shareable.org
Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source? Source?
The seahorse is so Mind-numbingly stupid I cannot even fathom how this creature not only has existed at one point in time but has continued to exist into modern day. It is genuinely baffling that this has happened. The fact that this thing is still alive and not even doing that poorly genuinely causes me physical pain.
I lay in bed at night and have hot flashes thinking about why seahorses aren't extinct. The only reason seahorses aren't the most mal-adapted creature to ever exist is because they can camouflage well. If they didn't have camouflage I think they'd be up there for the worst adapted creature to ever evolve to exist. EVER.
However, all of this said, they're still alive and they're not doing that poorly. So while it doesn't make sense, they're still doing it, right? Like, they're better than the things that have already gone extinct.
Accept invite is really ugly and not user friendly and it kinda sucks actually but refactoring can wait for the morning, for tonight I'm a tired bired and I did quite a lot today.
Wow. We got this even with LoD Fix/Edit form!!
@alliomeria gosh. I made it i think? OF course the UI can get some better things and we need to add a LOT of options to avoid "overwriting" all your lovely Manually LoD. But gosh. This is so good!!
Introduces the first force, gravitational attraction.
I .. ah... refactored a bit, to extract a Vector class out of the geometry's Vertex class, since it might be useful to consider the abstract form of a planar Vertex (Vertex2), and along the way, ah.. kinda removed Vertex2. (There were some XY/XYZ intermediaries for a very short time, and one "oops, gonna nuke all my changes and try again!" moment (.. or 2... shh!), but got the Vector out, added the magnitude and unit methods, which are very useful for force calculations, so .. a win, overall, I think.
Next up is a simple demo, something similar to what The Coding Train has in their "2: Forces" playlist on YouTube: https://www.youtube.com/playlist?list=PLRqwX-V7Uu6ZRrqLcQ5BkBKmBLiGD8n4O
Aaand I should probably get a few winks of sleep, before doing that demo work.. but looking forward to it tomorrow night!
Beautiful Array
For some fixed n, an array nums is beautiful if it is a permutation of the integers 1, 2, ..., n, such that:
For every i < j, there is no k with i < k < j such that nums[k] * 2 = nums[i] + nums[j].
Given n, return any beautiful array nums. (It is guaranteed that one exists.)
Example 1:
Input: n = 4 Output: [2,1,4,3]
Example 2:
Input: n = 5 Output: [3,1,2,5,4]
Note:
1 <= n <= 1000
Seriously, this question should be categorized as hard to those who have no experience of ACM, such like me. however, there still is a way to come across the solution without mathematical intuition and reasoning skills, which needs a pen and a paper, of coz, and a little bit observation.
First, it is not hard to figure out that, odd + even = odd != 2 * x so devide the array from 1 to N into two parts (take N=10 as example), 1 3 5 7 9 | 2 4 6 8 10 then the question becomes how to make the left or the right be "beautiful array". look at the right part that includes even numbers, here the pen and paper are in need. say we have 2 ,4, where should we put 6? apprently not the right most position, while the left most slot is ok, so we get 6, 2, 4. likewisely, we get 6, 2, 4, 8, and it is beautiful too. Given this, it seems that we can rebuild the left part spirally, but can it work always? Unfortunately, the answer is no. 10, 6, 2, 4, 8 is not beautiful. here comes the KEY -- if we splitted the spiral array into two parts and rebuild each part spirally again, we got two beautiful arrays, 10 2 6 | 4 8, AND, any number in the sub left plus any number in the sub right is a double of odd, while all numbers in this array are even. but are we to the end? 18 10 2 6 14 is not beautiful once more. so split and rebuild, 18 2 10 | 6 14, (left x + right y) / 2 is not in the array itself. it can be easily verified that all the above steps are also feasible on original odd subarrays. having gone so far, it is not difficult to think of devide and conquer and recursion, and TRY.
Theory
Take extra note of : A[k] * 2 = A[i] + A[j] Notice how A[k] * 2 is always even! So now we just have to make sure that A[i] + A[j] is always odd, and we can do that by making left odd and right even. Effectivley its a divide and conquer algorithm where we split the array into two halves, a left half which is odd, and a right half which is even. Eventually we have to put back both the halves together and we multiply the odd portion by 2 * i - 1 and the even portion with 2 * i. We have to do this step to return the larger array from our "current" beautiful array - why? - TBH I don't even know :/ But do watch this youtube video I have linked.
Credit
https://www.youtube.com/watch?v=O-1ucu8ErEo
Never again can we be something
You ruined it forever. I just sealed the deal getting mine in. I told you, not to do what you did anyways. You just have to seek revenge out. Escalate it everytime. Make it worse each time. I tried to walk away from you many times. And you said it would be different, but it never was any different. It was worse. You are the one who went and got dope. Not me. You kept feeding me dope. And i hated that. I knew youd blame me for your shit. Your a stupid bitch like that. But what goes around comes around. You will find a happiness so awesome and good, and it will be taken from you even faster. All because of what you did to me. Karma will fuck your life off. But youll be stuck here to live through it. Everyone and everything you love will be ripped apart from you. You will live and die all alone. 1st-Lee
Commenting for this piece of shit god-awful module
mm/page_alloc: use ac->high_zoneidx for classzone_idx
Patch series "integrate classzone_idx and high_zoneidx", v5.
This patchset is followup of the problem reported and discussed two years ago [1, 2]. The problem this patchset solves is related to the classzone_idx on the NUMA system. It causes a problem when the lowmem reserve protection exists for some zones on a node that do not exist on other nodes.
This problem was reported two years ago, and, at that time, the solution got general agreements 2. But it was not upstreamed.
This patch (of 2):
Currently, we use classzone_idx to calculate lowmem reserve proetection for an allocation request. This classzone_idx causes a problem on NUMA systems when the lowmem reserve protection exists for some zones on a node that do not exist on other nodes.
Before further explanation, I should first clarify how to compute the classzone_idx and the high_zoneidx.
-
ac->high_zoneidx is computed via the arcane gfp_zone(gfp_mask) and represents the index of the highest zone the allocation can use
-
classzone_idx was supposed to be the index of the highest zone on the local node that the allocation can use, that is actually available in the system
Think about following example. Node 0 has 4 populated zone, DMA/DMA32/NORMAL/MOVABLE. Node 1 has 1 populated zone, NORMAL. Some zones, such as MOVABLE, doesn't exist on node 1 and this makes following difference.
Assume that there is an allocation request whose gfp_zone(gfp_mask) is the zone, MOVABLE. Then, it's high_zoneidx is 3. If this allocation is initiated on node 0, it's classzone_idx is 3 since actually available/usable zone on local (node 0) is MOVABLE. If this allocation is initiated on node 1, it's classzone_idx is 2 since actually available/usable zone on local (node 1) is NORMAL.
You can see that classzone_idx of the allocation request are different according to their starting node, even if their high_zoneidx is the same.
Think more about these two allocation requests. If they are processed on local, there is no problem. However, if allocation is initiated on node 1 are processed on remote, in this example, at the NORMAL zone on node 0, due to memory shortage, problem occurs. Their different classzone_idx leads to different lowmem reserve and then different min watermark. See the following example.
root@ubuntu:/sys/devices/system/memory# cat /proc/zoneinfo Node 0, zone DMA per-node stats ... pages free 3965 min 5 low 8 high 11 spanned 4095 present 3998 managed 3977 protection: (0, 2961, 4928, 5440) ... Node 0, zone DMA32 pages free 757955 min 1129 low 1887 high 2645 spanned 1044480 present 782303 managed 758116 protection: (0, 0, 1967, 2479) ... Node 0, zone Normal pages free 459806 min 750 low 1253 high 1756 spanned 524288 present 524288 managed 503620 protection: (0, 0, 0, 4096) ... Node 0, zone Movable pages free 130759 min 195 low 326 high 457 spanned 1966079 present 131072 managed 131072 protection: (0, 0, 0, 0) ... Node 1, zone DMA pages free 0 min 0 low 0 high 0 spanned 0 present 0 managed 0 protection: (0, 0, 1006, 1006) Node 1, zone DMA32 pages free 0 min 0 low 0 high 0 spanned 0 present 0 managed 0 protection: (0, 0, 1006, 1006) Node 1, zone Normal per-node stats ... pages free 233277 min 383 low 640 high 897 spanned 262144 present 262144 managed 257744 protection: (0, 0, 0, 0) ... Node 1, zone Movable pages free 0 min 0 low 0 high 0 spanned 262144 present 0 managed 0 protection: (0, 0, 0, 0)
-
static min watermark for the NORMAL zone on node 0 is 750.
-
lowmem reserve for the request with classzone idx 3 at the NORMAL on node 0 is 4096.
-
lowmem reserve for the request with classzone idx 2 at the NORMAL on node 0 is 0.
So, overall min watermark is: allocation initiated on node 0 (classzone_idx 3): 750 + 4096 = 4846 allocation initiated on node 1 (classzone_idx 2): 750 + 0 = 750
Allocation initiated on node 1 will have some precedence than allocation initiated on node 0 because min watermark of the former allocation is lower than the other. So, allocation initiated on node 1 could succeed on node 0 when allocation initiated on node 0 could not, and, this could cause too many numa_miss allocation. Then, performance could be downgraded.
Recently, there was a regression report about this problem on CMA patches since CMA memory are placed in ZONE_MOVABLE by those patches. I checked that problem is disappeared with this fix that uses high_zoneidx for classzone_idx.
http://lkml.kernel.org/r/20180102063528.GG30397@yexl-desktop
Using high_zoneidx for classzone_idx is more consistent way than previous approach because system's memory layout doesn't affect anything to it. With this patch, both classzone_idx on above example will be 3 so will have the same min watermark.
allocation initiated on node 0: 750 + 4096 = 4846 allocation initiated on node 1: 750 + 4096 = 4846
One could wonder if there is a side effect that allocation initiated on node 1 will use higher bar when allocation is handled on local since classzone_idx could be higher than before. It will not happen because the zone without managed page doesn't contributes lowmem_reserve at all.
Reported-by: Ye Xiaolong xiaolong.ye@intel.com Signed-off-by: Joonsoo Kim iamjoonsoo.kim@lge.com Signed-off-by: Andrew Morton akpm@linux-foundation.org Tested-by: Ye Xiaolong xiaolong.ye@intel.com Reviewed-by: Baoquan He bhe@redhat.com Acked-by: Vlastimil Babka vbabka@suse.cz Acked-by: David Rientjes rientjes@google.com Cc: Johannes Weiner hannes@cmpxchg.org Cc: Michal Hocko mhocko@kernel.org Cc: Minchan Kim minchan@kernel.org Cc: Mel Gorman mgorman@techsingularity.net Link: http://lkml.kernel.org/r/1587095923-7515-1-git-send-email-iamjoonsoo.kim@lge.com Link: http://lkml.kernel.org/r/1587095923-7515-2-git-send-email-iamjoonsoo.kim@lge.com Signed-off-by: Linus Torvalds torvalds@linux-foundation.org Signed-off-by: celtare21 celtare21@gmail.com
Fix instant mining of blocks not being recognised, tweak anti-cheat (#4938)
- Tried to fix a small issue...
Ended up rewriting a bunch of god awful, opaque code with no source and no sense. Who names a function GetPlayerRelativeBlockHardness??? It's gone now. We're safe again.
-
Testing anti-cheat.
-
Tidy up debug logging.
-
Remove empty member declaration.
-
Rewrite GetDigSpeed slightly for better readability.
-
GetMiningProgressPerTick now returns 1 when instantly mined. Fixed hasily written typo.
-
Comment style and typo fixes.
Update en_us.json
These are changes to the naming of certain blocks and items. If any of these changes don't suit your criteria, please advise me and I'll change or revert it back to original. Alternatively, you can simply close this if you don't like none of the proposed changes.
- "Sand Layer" has been renamed to "Strange Sand Layer";
- "Large Limestone Bricks" have been renamed to "Limestone Bricks". Due to most bricks in vanilla Minecraft being large in shape and none of them having "large" on their name, it's inconsistent for it being named in this way;
- "Ceramic Tile Blocks" have been renamed to "Ceramic Tiles", and "Ceramic Tile" has been renamed to "Ceramic Tile Pave". The reason is due to "Ceramic Tile" being a secondary crafting recipe resultant from the use of "Ceramic Tile Blocks" on a crafting grid. To simplify this, it's kinda like calling wool "Carpet Blocks" or planks "Pressure Plate Blocks";
- Alabaster and Porphyry blocks no longer have "Brick" on their name. They are now labeled: "Polished Alabaster/Porphyry", "Carved Alabaster/Porphyry", "Alabaster/Porphyry Tiles" and "Alabaster/Porphyry Pillar". This also applies to stairs, slabs and wall variants;
- "Emmer Wheat" is now named "Emmer Crop";
- Both types of shrubs now have different names from each other. The one wich has the "weed" ID is now called "Dry Weed";
- Atum ores now have "Atum" on their name to differentiate them from Overworld ores. This change doesn't affects ores exclusive to Atum;
- All instances of the word "Gold" have been replaced with "Golden";
- Mummy and Wanderer helmets and chestplates have been renamed to "Hood" and "Shirt", respectively;
- Desert Armor sets now are properly named, no longer having the name of the material they are made of between parentheses;
- Male and female Atum villagers strings now have the word "Atum", to better differentiate them from Overworld villagers.
Update en_us.json
These are changes to the naming of certain blocks and items. If any of these changes don't suit your criteria, please advise me and I'll change or revert it back to original. Alternatively, you can simply close this if you don't like none of the proposed changes.
- Fixed several instances of grammar errors, mainly the order that some words were in certain strings;
- "Sand Layer" has been renamed to "Strange Sand Layer";
- "Large Limestone Bricks" have been renamed to "Limestone Bricks". Due to most bricks in vanilla Minecraft being large in shape and none of them having "large" on their name, it's inconsistent for them being named in this way;
- "Ceramic Tile Blocks" have been renamed to "Ceramic Tiles", and "Ceramic Tile" has been renamed to "Ceramic Tile Pave". The reason is due to "Ceramic Tile" being a secondary crafting recipe resultant from the use of "Ceramic Tile Blocks" on a crafting grid. To simplify this, it's kinda like calling wool "Carpet Blocks" or planks "Pressure Plate Blocks", so because of that I've changed this;
- Alabaster and Porphyry blocks no longer have "Brick" on their name. They are now labeled: "Polished Alabaster/Porphyry", "Carved Alabaster/Porphyry", "Alabaster/Porphyry Tiles" and "Alabaster/Porphyry Pillar". This also applies to stairs, slabs and wall variants;
- "Emmer Wheat" now is named "Emmer Crop";
- Both types of shrubs now have different names from each other. The one wich has the "weed" ID is now called "Dry Weed";
- Atum ores now have "Atum" on their name to differentiate them from Overworld ores. This change doesn't affects ores exclusive to Atum;
- All instances of the word "Gold" have been replaced with "Golden", for consistency with vanilla Minecraft naming of most gold-related items;
- Mummy and Wanderer helmets and chestplates have been renamed to "Hood" and "Shirt", respectively;
- Desert Armor sets are now properly named, no longer having the name of the material they are made of between parentheses;
- Male and female Atum villagers strings now have the word "Atum", to better differentiate them from Overworld villagers.
Complete Refactor / Update to 1.16.5 The main part of this work has been updating this mod to be applicable to 1.16.5. I have changed so much progressing through that I cannot honestly remember everything but I will try to list what I can.
Main thing to note: WIP RECIPES and NO TESTING
- Still need to update the recipe files contents
- To match new naming conventions and;
- Replacing references to Ore Dict with Tags (Ore Dict removed between 1.12 -> 1.16 and replaced with Tags)
- No live testing has been performed at the time of this commit
Rough Change Log:
- Renamed from Spartan Fire to Spartan Fire Reborn, wasn't sure if Kovak was still active when I originally started this so renamed it in preparation for independant upload, happy for it to be changed back.
- Updated gradle to build with 1.16.5 and newest versions of IaF and SW
- Updated namings to be all of one standard weapontype_basematerial_modifiermaterial aka battleaxe_dragonbone_fire including
- Within scripts
- model/texture file namings and paths within json
- recipe filenames
- The above naming convention was to bring it inline with IaF namings ie. dragonsteel_ice, dragonbone_fire, myrmexdesert_venom
- Updated spartanMatFromToolMat in-line with the material properties in Spartan
- Updated the main script to use the newest SpartanWeaponry-API which simplifies the create methods with parameters removed from the create's now being defined in the Material properties
- Some weapons have been renamed in SpartanWeaponry including but not limited to:
- throwing_axe to tomahawk
- mace to flanged_mace
- crossbow to heavy_crossbow
- hammer to battle_hammer
- Some general updating/removing items due to changes from MC/Forge 1.12 -> 1.16
- Changes to config disabled checks
- Removed ConditionFactory's, due to inexperience (and maybe partially impatience by this point) was unable to easily find a replacement within MC 1.16
updated config to try and make this shit not so buggy. fucking hell with the old kernel memory leaks man. and old android. fuck all of this.
chore(label): Fixes my fuckup (#192)
- chore: bumps to force a test of online runners
Signed-off-by: Jonathan Stevens jonathan@videndum.studio
- fix(convention-mastermind,label-mastermind,@videndum/release-mastermind): adds dryRun input field
TEST PLAN: Run actions test before merge
- fix(convention-mastermind,label-mastermind,@videndum/release-mastermind): fixes the no index issue
Well some dumb idiot set dist/index.js to be ignored in the .gitignore honestly it wasn't me.... TEST PLAN: Well, everything should now work so we can test
- feat(convention-mastermind,label-mastermind,@videndum/release-mastermind): fix compiler target
6.54
- added a clarification to read me that under automation numeric data received as pandas categoric data type will be treated as categoric for binarization instead of normalizations
- new temporary postproccess_dict entry temp_miscparameters_results added at initialization
- temp_miscparameters_results is for storing validaiton results recieved in various support functions that might not have access to miscparameters_results
- which is then consolidated with miscparameters_results and the temporary entry struck
- new validation result reported in miscparameters_results as treecategory_with_empty_processing_functions_valresult
- which is for the tree category without processing functions populated that we noted in 6.50
- validation result is populated with unique entry for each occurance recording the tree category without processing functions and the associated root category whose generations included the tree category
- populated with key as integer i incremented with each occurance as:
treecategory_with_empty_processing_functions_valresult =
{i : {'treecategory' : treecategory, 'rootcategory' : rootcategory}} - identified a superfluous copy operation within the transformation functions associated with populating returned column_dict data structure
- so globally struck this copy operation
- created a new support function for one hot encoding as _onehot_support
- this function returns a comparable order of columns as would pd.get_dummies
- the index retention convention is also comparable
- part of the reason for creating this function is so will be able to experiment with variations
- for potential use in different transformation function scenarios
- new trigometric family of transforms sint/cost/tant/arsn/arcs/artn
- built on top of numpy trigometric operations np.sin, np.cos, np.tan, np.arcsin, np.arccos, np.arctan
- inversion supported with partial information recovery
- defaults to defaultinfill of adjinfill (since these are for periodic sets a static imputation makes less sense)
- the inspiration for incorporporating trigometric functions came from looking at a calculator
- audited family trees for cases with omitted NArw_marker support, found a few entries whose omission I believe was accidental
- in the process identified by memory I think a case where I may not have provided sufficient citation at the time of rollout
- for clarity, our use of adjacent sin and cos transformations for periodic datetime data, as well as binarization as an alternative to onehot encoding
- were direclty inspired by github issue suggestions submitted by github user "solalatus"
- (I had noted his input in acknowledgements of one of papers, just thought might be worth reiterating)
- this user provided links to blog posts associated with both of these concepts which were rolled out in 2.47
- the datetime blog post was an article by Ian London titled "Encoding cyclical continuous features - 24-hour time"
- the binarization blog was one of a few articles, not sure which, I think it was a blog post by Rakesh Ravi titled "One-Hot Encoding is making your Tree-Based Ensembles worse, here’s why?"